Vulnerability Context Flow

  • Tier: Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Status: Experiment

The availability of this feature is controlled by a feature flag. For more information, see the history.

Use the Vulnerability Context Flow to read your codebase and to generate context across the following security categories:

  • Authentication model
  • Authorization model
  • Sensitive data classification
  • Security boundary

After you turn on the flow, it runs automatically after a human push updates the default branch, at most once every 24 hours. Pushes from bots and service accounts, and branch creation, don’t trigger the flow. When the flow is triggered, it completes the following processes:

  1. Reads the project’s codebase to understand its architecture and security posture.
  2. Produces structured output for each of the security context categories.
  3. Stores the context so that downstream security features can use it.

The analysis runs in the background. You do not manually trigger this flow.

When this feature is turned on, your project’s source code is sent to large language models (LLMs) for analysis to generate security context. Review your organization’s data policies before you turn on this feature.

Prerequisites

Turn on the Vulnerability Context Flow

To use this feature, you must turn on the foundational flow for the root group and turn on the feature for the project:

Allow foundational flow for a group

You can allow all projects in a group to use the foundational flow. Individual projects must still enable the feature in their project settings.

To allow Vulnerability Context Flow for a group:

  1. In the left sidebar, select Search or go to and find your group.
  2. Select Settings > GitLab Duo.
  3. Under Allow foundational flows, select the Vulnerability Context Flow checkbox.
  4. Select Save changes

Turn on for a project

Prerequisites:

  • The Maintainer or Owner role for the project.
  • The Maintainer or Owner role for the project for the service account user whose name starts with Duo Vulnerability Context.

To allow Vulnerability Context Flow for a project:

  1. In the left sidebar, select Search or go to and find your project.
  2. Select Settings > General.
  3. Expand GitLab Duo.
  4. Turn on the Turn on Vulnerability Context Flow toggle.
  5. Select Save changes.
  6. In the left sidebar, select Manage > Members.
  7. Ensure the service account user whose name starts with Duo Vulnerability Context has the Maintainer or Owner role for the project.

Turn off the flow

When you turn off Vulnerability Context Flow for a project, existing context stays visible in the Risk section on vulnerability details pages. The flow stops updating the context. Turning off the flow does not delete existing context.

Security context the flow scans

The flow produces context in the following categories. Each category provides structured information that helps assess the impact of a vulnerability.

  • Authentication: Yes or No. Indicates whether the component requires authentication.
  • Authorization: Elevated or Standard. Indicates whether exploiting the component requires elevated privileges.
  • Sensitive data: Yes or No. Indicates whether the component handles sensitive data, such as personal information, credentials, tokens, payment data, or health data.
  • Security boundary: one or more of Network access, User input, Partner boundary, Trusted service, Internal only, or Isolated. Indicates which trust boundaries the component sits on, and therefore how exposed the vulnerable code is to untrusted callers.

These values appear in the Risk section on the vulnerability details page.

Supported scanners

The security context produced by the Vulnerability Context Flow is used by the following scanners and features:

Known issues

  • The flow analyzes source code only. Runtime telemetry, dynamic analysis results, and function-level reachability data are not used as input.
  • Context generation depends on the information available in the repository. Projects with minimal documentation or non-standard structures may produce less detailed context.
  • A 24-hour debounce starts when an eligible push is received. Pushes within that window do not trigger a new analysis. If a run fails, it isn’t retried until the 24-hour window expires.