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:
Start with KEV-listed vulnerabilities as immediate priorities.
Use EPSS to identify high-probability threats not yet on KEV.
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:
Adding security scanners to your pipeline
Viewing vulnerability insights
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
