Why A 9.8 CVSS Score May Not Matter: Reducing Risks And Unnecessary Alerts Using JFrog Xray and GitLab’s Dependency Scanning

The loudest complaint in DevSecOps right now is not a lack of security data. It is too much of it. Teams are flooded with “Critical” and “High” findings from standard base images, transitive packages, and common open-source components that may never be invoked at runtime. Even minimal images can produce a wall of CVEs that overwhelms engineering teams and creates triage fatigue. The core problem is that the Common Vulnerability Scoring System (CVSS) tells you how severe a vulnerability could be in theory, not whether it is actually reachable or exploitable in your environment.

That is why severity-only prioritization is breaking down. A 9.8 score is useful context, but it should not automatically drive your remediation queue. What matters more is exploitability context: Is the vulnerable package imported? Is the affected function reachable? Is the component actually used in the shipped application? GitLab now explicitly supports static reachability analysis in dependency scanning to identify vulnerable packages that are imported by your application, so teams can prioritize based on actual exposure instead of theoretical risk.

JFrog Xray takes a similar approach through Contextual Analysis of CVEs. In JFrog Advanced Security, Xray can determine whether a vulnerability is Applicable, Not Applicable, or Undetermined based on how dependencies are used in first-party code. For transitive dependencies, JFrog can also surface evidence such as call chains, functions, file paths, and line numbers. That turns vulnerability management from “sort by highest CVSS” into “fix what can actually be exploited.”

The operational fix is to configure the tooling so it suppresses noise by design.

How to surface actionable security data in JFrog and GitLab

In JFrog Xray, start by creating Watches that scope analysis to the repositories, builds, and projects that matter most. Then attach Policies so the right thresholds apply to the right assets instead of one global rule for everything. Xray’s policy model is designed to assess software by SDLC phase, and Watches let you continuously track only the relevant artifacts. For findings that are known false positives, non-exploitable in your context, or temporarily accepted risk, use Ignore Rules. Those rules suppress violations from blocking builds or triggering alerts while still keeping them logged for audit purposes. That is one of the fastest ways to reduce repetitive noise without losing traceability.

In GitLab, make sure you are not just running dependency scanning blindly. Enable dependency scanning in CI/CD, and where supported, use static reachability analysis so teams can focus on reachable vulnerabilities first. GitLab also supports SBOM-based dependency scanning, which helps normalize visibility across direct and transitive dependencies. At the governance layer, use scan execution policies to standardize how scans run across projects, and license approval policies where appropriate so enforcement is consistent instead of ad hoc.

A practical GitLab pattern looks like this:

include:
– template: Jobs/Dependency-Scanning.latest.gitlab-ci.yml

That gets dependency scanning into the pipeline. From there, teams should prioritize vulnerabilities flagged as reachable, then decide which findings require remediation, risk acceptance, or workflow-based suppression through policy rather than treating every high score as an emergency. GitLab documents the template include pattern directly in its migration and scanning guidance.

The bottom line is simple: stop managing risk by CVSS alone. Use Xray Watches + Policies + Ignore Rules + Contextual Analysis and GitLab Dependency Scanning + Static Reachability + Policy Enforcement to shrink the alert queue to the findings that are actually actionable. The goal is not fewer vulnerabilities on paper. The goal is fewer wasted hours chasing vulnerabilities that were never exploitable in the first place.

Reach out today If you need help building a system like this!