Vulnerability risk prioritization made simple with GitLab

Development and security teams are often overwhelmed by the number of vulnerabilities they need to remediate. Many organizations remediate less than 16% of their known vulnerabilities monthly. Vulnerability management teams face a constant challenge: which security flaws deserve immediate attention? Three key frameworks help answer this question: Common Vulnerability Scoring System (CVSS), Known Exploited Vulnerabilities (KEV), and Exploit Prediction Scoring System (EPSS). The GitLab 17.9 release adds support for these frameworks. In this article, you'll learn how to use these frameworks within GitLab to efficiently prioritize risk across your dependency and container image vulnerabilities using this data.

Vulnerability risk assessment data

CVSS

CVSS provides a standardized method for rating the severity of security vulnerabilities. Scores range from 0 to 10, with higher values indicating greater severity.

CVSS evaluates vulnerabilities across three dimension groups:

• Base metrics: intrinsic qualities that don't change over time (attack complexity, privileges required)
• Temporal metrics: factors that evolve (exploit maturity, remediation level)
• Environmental metrics: organization-specific impact considerations

CVSS offers a consistent severity baseline and common language for security teams. Its comprehensive scoring methodology considers multiple aspects of a vulnerability's technical impact.

KEV

The Cybersecurity and Infrastructure Security Agency (CISA) maintains the KEV catalog, which identifies vulnerabilities actively exploited in the wild.

Unlike academic severity scores, KEV focuses on real-world threat intelligence. Each entry includes:

• CVE identifier
• Vulnerability name
• Action required
• Due date for remediation (for federal agencies)

KEV provides actionable intelligence based on observed threat actor behavior. It cuts through scoring complexity with a binary signal: "This vulnerability is being actively exploited right now."

EPSS

The EPSS uses machine learning to predict the likelihood a vulnerability will be exploited in the next 30 days. Scores range from 0 to 1 (or 0%-100%), representing probability.

EPSS analyzes hundreds of factors, including:

• Technical characteristics
• Social media mentions
• Exploit availability
• Vulnerability age

EPSS brings risk-based prioritization to vulnerability management. Rather than focusing solely on technical severity, it helps teams understand which vulnerabilities attackers are most likely to target.

Combining the frameworks for effective prioritization

Each framework serves a unique purpose:

• CVSS indicates how severe a vulnerability is technically.
• KEV indicates which vulnerabilities are actively being exploited.
• EPSS indicates which vulnerabilities are likely to be exploited soon.

An effective prioritization strategy leverages all three:

1. Start with KEV-listed vulnerabilities as immediate priorities.
2. Use EPSS to identify high-probability threats not yet on KEV.
3. Consider CVSS for understanding technical impact.

By combining these complementary frameworks, security teams can focus limited resources on the vulnerabilities that pose the greatest actual risk to their organizations. You can get started with prioritizing vulnerabilities with GitLab by:

1. Adding security scanners to your pipeline
2. Viewing vulnerability insights
3. Setting the vulnerability status based metrics

Watch this video to learn more:

Adding security scanners to your pipeline

GitLab provides built-in security scanning tools through its templates that can be integrated directly into your CI/CD pipeline. GitLab offers several security scanners that address different aspects of your application security:

• Static Application Security Testing (SAST): Analyzes your source code for known vulnerabilities
• Dynamic Application Security Testing (DAST): Tests your running application for vulnerabilities
• Dependency Scanning: Checks your dependencies for known vulnerabilities
• Container Scanning: Identifies vulnerabilities in container images
• Secret Detection: Finds secrets and credentials accidentally committed to your repository
• Infrastructure as Code Scanning: Detects security issues in IaC files
• Coverage-guided Fuzzing: Sends random inputs to an instrumented version of your application in an effort to detect bugs
• Web API Fuzzing: Sets operation parameters to unexpected values in an effort to cause unexpected behavior and errors in the API backend

To add them to your pipeline, simply add the appropriate templates to .gitlab-ci.yml file. For example, adding SAST and Dependency Scanning to your pipeline is as simple as:

include:  
  - template: Security/SAST.gitlab-ci.yml  
  - template: Security/Dependency-Scanning.gitlab-ci.yml

stages:  
  - test  

Once you commit the above changes, security scanners will begin to run. These scanners can be further configured to meet the needs of your organization. To learn more about our various scanners, see the GitLab application security documentation.

Note: EPSS and KEV metrics are only provided for dependency and container image vulnerabilities.

Viewing vulnerability insights

Once a pipeline with your security scanners is run on the default branch, you can access the vulnerability report. The vulnerability report provides a consolidated view of all security vulnerabilities detected across your project by GitLab's security scanners. You can access it from your project by going to the side-tab and selecting Secure > Vulnerability Report.

Vulnerability report grouped by tool

From the vulnerability report, select a vulnerability to see its insights page, which includes the severity, EPSS, KEV, and CVSS along with the following:

• description
• when it was detected
• current status
• available actions
• linked issues
• actions log
• filename and line number of the vulnerability (if available)

This data can be used to effectively triage, remediate, or mitigate the vulnerability.

Note: From the insights page, you can also leverage GitLab Duo’s AI capabilities to explain and auto-resolve a vulnerability.

Setting the vulnerability status-based metrics

After examining the provided data, we can go ahead and change the status of our vulnerability by clicking the Change status button:

Change vulnerability status from insights page

Then we'll see a popup that will allow you to change the status of a vulnerability:

Change vulnerability status option

When you dismiss a vulnerability you can choose one of the following reasons and optionally provide a comment:

• Acceptable risk: The vulnerability is known, and has not been remediated or mitigated, but is considered to be an acceptable business risk.
• False positive: An error in reporting in which a test result incorrectly indicates the presence of a vulnerability in a system when the vulnerability is not present.
• Mitigating control: The vulnerability’s risk is mitigated by a management, operational, or technical control (that is, safeguard or countermeasure) employed by an organization that provides equivalent or comparable protection for an information system.
• Used in tests: The finding is not a vulnerability because it is part of a test or is test data.
• Not applicable: The vulnerability is known, and has not been remediated or mitigated, but is considered to be in a part of the application that will not be updated.

And there you have it, quick and easy vulnerability risk prioritization with GitLab!

Get started today with a free, 60-day trial of GitLab Ultimate!

Learn more

To learn more about GitLab security and governance features and how we can help enhance your security posture, check out the following resources:

• GitLab Risk Assessment Data
• GitLab Security and Compliance Solutions
• GitLab Application Security documentation
• GitLab Risk Assessment Data epic