A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://docs.gitlab.com/user/application_security/vulnerabilities/ below:

Vulnerability details | GitLab Docs

Each vulnerability in a project has a vulnerability page containing details of the vulnerability, including:

For vulnerabilities in the Common Vulnerabilities and Exposures (CVE) catalog, these details also include:

For further details on this additional data, see vulnerability risk assessment data.

If the scanner determined the vulnerability to be a false positive, an alert message is included at the top of the vulnerability’s page.

Vulnerability Explanation

History

GitLab Duo Vulnerability Explanation can help you with a vulnerability by using a large language model to:

Watch an overview

Prerequisites:

To explain the vulnerability:

  1. On the left sidebar, select Search or go to and find your project.

  2. Select Secure > Vulnerability report.

  3. Optional. To remove the default filters, select Clear ( clear ).

  4. Above the list of vulnerabilities, select the filter bar.

  5. In the dropdown list that appears, select Tool, then select all the values in the SAST category.

  6. Select outside the filter field. The vulnerability severity totals and list of matching vulnerabilities are updated.

  7. Select the SAST vulnerability you want explained.

  8. Do one of the following:

The response is shown on the right side of the page.

On GitLab.com this feature is available. By default, it is powered by the Anthropic claude-3-haiku model. We cannot guarantee that the large language model produces results that are correct. Use the explanation with caution.

The following data is shared with third-party AI APIs:

Vulnerability Resolution

History

Use GitLab Duo Vulnerability resolution to automatically create a merge request that resolves the vulnerability. By default, it is powered by the Anthropic claude-3.5-sonnet model.

We can’t guarantee that the large language model produces correct results. You should always review the proposed change before merging it. When reviewing, check that:

Watch an overview

Prerequisites:

Learn more about how to enable all GitLab Duo features.

To resolve the vulnerability:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Secure > Vulnerability report.
  3. Optional. To remove the default filters, select Clear ( clear ).
  4. Above the list of vulnerabilities, select the filter bar.
  5. In the dropdown list that appears, select Activity, then select Vulnerability Resolution available in the GitLab Duo (AI) category.
  6. Select outside the filter field. The vulnerability severity totals and list of matching vulnerabilities are updated.
  7. Select the SAST vulnerability you want resolved.
  8. In the upper-right corner, select Resolve with AI. If this project is a public project be aware that creating an MR will publicly expose the vulnerability and offered resolution. To create the MR privately, create a private fork, and repeat this process.
  9. Add an additional commit to the MR. This forces a new pipeline to run.
  10. After the pipeline is complete, on the pipeline security tab, confirm that the vulnerability no longer appears.
  11. On the vulnerability report, manually update the vulnerability.

A merge request containing the AI remediation suggestions is opened. Review the suggested changes, then process the merge request according to your standard workflow.

Provide feedback on this feature in issue 476553.

Supported vulnerabilities for Vulnerability Resolution

To ensure that suggested resolutions are high-quality, Vulnerability Resolution is available for a specific set of vulnerabilities. The system decides whether to offer Vulnerability Resolution based on the vulnerability’s Common Weakness Enumeration (CWE) identifier.

We selected the current set of vulnerabilities based on testing by automated systems and security experts. We are actively working to expand coverage to more types of vulnerabilities.

View the complete list of supported CWEs for Vulnerability Resolution Troubleshooting

Vulnerability Resolution sometimes cannot generate a suggested fix. Common causes include:

The following data is shared with third-party AI APIs:

Vulnerability Resolution in a merge request

History

Use GitLab Duo Vulnerability resolution to automatically create a merge request suggestion comment that resolves the vulnerability finding. By default, it is powered by the Anthropic claude-3.5-sonnet model.

To resolve the vulnerability finding:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Merge requests.
  3. Select a merge request.
  4. Select the supported findings to open the security finding dialog.
  5. In the lower-right corner, select Resolve with AI.

A comment containing the AI remediation suggestions is opened in the merge request. Review the suggested changes, then apply the merge request suggestion according to your standard workflow.

Provide feedback on this feature in issue 476553.

Troubleshooting

Vulnerability Resolution in a merge request sometimes cannot generate a suggested fix. Common causes include:

Vulnerability code flow

For specific types of vulnerabilities, GitLab Advanced SAST provides code flow information. A vulnerability’s code flow is the path the data takes from the user input (source) to the vulnerable line of code (sink), through all assignments, manipulation, and sanitization.

For details on how to view a vulnerability’s code flow, see Vulnerability code flow.

Vulnerability status values

A vulnerability’s status can be:

A vulnerability typically goes through the following lifecycle:

%%{init: { "fontFamily": "GitLab Sans" }}%%
stateDiagram
    accTitle: Vulnerability lifecycle
    accDescr: Typical lifecycle of a vulnerability

    direction LR
    Needs_triage: Needs triage

    [*] --> Needs_triage
    Needs_triage --> Confirmed
    Needs_triage --> Dismissed
    Dismissed --> [*]
    Confirmed --> Resolved
    Resolved --> Needs_triage: If reintroduced and detected again
    Resolved --> [*]
Vulnerability is no longer detected

History

A vulnerability may be no longer detected because of changes made deliberately to remediate it or as a side effect of other changes. When a security scan runs and a vulnerability is no longer detected in the default branch, the scanner adds No longer detected to the record’s activity log but the record’s status does not change. Instead you should check and confirm the vulnerability has been resolved and if so, manually change its status to Resolved. You can also use a vulnerability management policy to automatically change the status of vulnerabilities matching specific criteria to Resolved.

You can find a link to the commit that resolved the vulnerability at the top or bottom of the vulnerability page.

Vulnerability dismissal reasons

History

When you dismiss a vulnerability you must choose one of the following reasons:

Change the status of a vulnerability

History

Prerequisites:

To change a vulnerability’s status from its Vulnerability Page:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Secure > Vulnerability report.
  3. Select the vulnerability’s description.
  4. Select Change status.
  5. From the Status dropdown list, select a status or a dismissal reason when you want to change the vulnerability’s status to Dismissed.
  6. In the Comment text box, provide a comment with more details about the reasons for dismissal. When you apply the Dismissed status, a comment is required.

Details of the status change, including who made the change and when, are recorded in the vulnerability’s action log.

Create a GitLab issue for a vulnerability

You can create a GitLab issue to track any action taken to resolve or mitigate a vulnerability. To create a GitLab issue for a vulnerability:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Secure > Vulnerability report.
  3. Select the vulnerability’s description.
  4. Select Create issue.

The issue is created in the GitLab project with information from the vulnerability report.

To create a Jira issue, see Create a Jira issue for a vulnerability.

Linking a vulnerability to GitLab and Jira issues

You can link a vulnerability to one or more existing GitLab or Jira issues. Only one linking feature is available at the same time. Adding a link helps track the issue that resolves or mitigates a vulnerability.

Link a vulnerability to existing GitLab issues

Prerequisites:

To link a vulnerability to existing GitLab issues:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Secure > Vulnerability report.
  3. Select the vulnerability’s description.
  4. In the Linked issues section, select the plus icon ( plus ).
  5. For each issue to be linked, either:
  6. Select Add.

The selected GitLab issues are added to the Linked items section, and the linked issues counter is updated.

GitLab issues linked to a vulnerability are shown in the vulnerability report and the vulnerability’s page.

Be aware of the following conditions between a vulnerability and a linked GitLab issue:

Link a vulnerability to existing Jira issues

Prerequisites:

To link a vulnerability to existing Jira issues, add the following line to the Jira issue’s description:

/-/security/vulnerabilities/<id>

<id> is any vulnerability ID. You can add several lines with different IDs to one description.

Jira issues with appropriate description are added to the Related Jira issues section, and the linked issues counter is updated.

Jira issues linked to a vulnerability are shown only on the vulnerability page.

Be aware of the following conditions between a vulnerability and a linked Jira issue:

Resolve a vulnerability

For some vulnerabilities a solution is already known but needs to be implemented manually. The Solution field in the Vulnerability page is provided by the security scanning tool that reported the security finding, or entered during the manual creation of a vulnerability. The GitLab tools utilize information from the GitLab Advisory Database.

Additionally, some tools may include a software patch to apply the suggested solution. In those instances, a vulnerability’s page includes a Resolve with merge request option.

The following scanners are supported by this feature:

To resolve a vulnerability, you can either:

Resolve a vulnerability with a merge request

To resolve the vulnerability with a merge request:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Secure > Vulnerability report.
  3. Select the vulnerability’s description.
  4. From the Resolve with merge request dropdown list, select Resolve with merge request.

A merge request is created which applies the patch required to resolve the vulnerability. Process the merge request according to your standard workflow.

Resolve a vulnerability manually

To manually apply the patch that GitLab generated for a vulnerability:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Secure > Vulnerability report.
  3. Select the vulnerability’s description.
  4. From the Resolve with merge request dropdown list, select Download patch to resolve.
  5. Ensure your local project has the same commit checked out that was used to generate the patch.
  6. Run git apply remediation.patch.
  7. Verify and commit the changes to your branch.
  8. Create a merge request to apply the changes to your main branch.
  9. Process the merge request according to your standard workflow.
Enable security training for vulnerabilities

Security training is not accessible in an environment that is offline, meaning computers that are isolated from the public internet as a security measure. Specifically, the GitLab server needs the ability to query the API endpoints for any training provider you choose to enable. Some third-party training vendors may require you to sign up for a free account. Sign up for an account by going to any of Secure Code Warrior, Kontra, or SecureFlag. GitLab does not send any user information to these third-party vendors; we do send the CWE or OWASP identifier and the language name of the file extension.

Security training helps your developers learn how to fix vulnerabilities. Developers can view security training from selected educational providers, relevant to the detected vulnerability.

To enable security training for vulnerabilities in your project:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Secure > Security configuration.
  3. On the tab bar, select Vulnerability Management.
  4. To enable a security training provider, turn on the toggle.

Each integration submits the Vulnerability identifier, for example CWE or OWASP, and the language to the security training vendor. The resulting link to the vendor training is what appears in a GitLab Vulnerability.

View security training for a vulnerability

The vulnerability page may include a training link relevant to the detected vulnerability if security training is enabled. The availability of training depends on whether the enabled training vendor has content matching the particular vulnerability. Training content is requested based on the vulnerability identifiers. The identifier given to a vulnerability varies from one vulnerability to the next and the available training content varies between vendors. Some vulnerabilities do not display training content. Vulnerabilities with a CWE are most likely to return a training result.

To view the security training for a vulnerability:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Secure > Vulnerability report.
  3. Select the vulnerability for which you want to view security training.
  4. Select View training.
View the location of a vulnerability in transitive dependencies

History

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

When managing vulnerabilities found in dependencies in the vulnerability details, under Location, you can view:

If the vulnerability occurs in one or more transitive dependencies, knowing only the direct dependency may not be enough. Transitive dependencies are indirect dependencies that have a direct dependent as an ancestor.

If any transitive dependencies exist, you can view the paths to all dependencies, including the transitive dependencies that contain the vulnerability.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4