Why CVSS Is Not Enough

A score of 9.8 tells you how severe a vulnerability is in the lab. It does not tell you whether your product is affected, whether anyone is exploiting it, and what you should address first on Monday morning.

Forty Critical Findings Are Not an Agenda

The process is almost always the same in every product team. The release is two weeks away, the scanner runs against the software bill of materials, and the next morning there is a list on the table: 312 findings, 40 of them “critical.” Then someone from product management asks the only question that matters:

Which of these do we need to fix before the release?

An dieser Stelle hilft die Spalte, nach der alle sortiert haben, kein Stück weiter. Vierzig Zeilen, die alle „kritisch“ heißen, sind keine Tagesordnung – sie sind vierzig Mal dieselbe Auskunft. Die Sortierung nach CVSS beantwortet die Frage wie schlimm wäre es, gefragt war aber was tun wir zuerst. Das sind zwei verschiedene Fragen, und die zweite ist die teurere.

Der übliche Ausweg ist eine Schwelle: „alles ab 7,0 wird behoben“. Das ist keine Priorisierung, sondern eine Verlagerung. Sie erzeugt Arbeit an Funden, die das Produkt nie erreichen, und lässt eine 5,9 liegen, für die es seit Wochen fertigen Exploit-Code gibt.

What CVSS Is—and What It Was Never Meant to Be

The misunderstanding does not begin with CVSS itself, but with how it is used. The Common Vulnerability Scoring System, developed by the FIRST organization, consists of three metric groups:

What appears in the databases, what scanners output, and what shows up in every report is the Base group. It is explicitly designed to apply independently of any specific installation—time and context are deliberately excluded. The standard itself makes clear that a Base Score describes severity, not risk.

So, when you prioritize based on the Base Score, you are using precisely the one metric from which everything that needs to be considered for a decision has been removed. Not because CVSS is bad, but because it was never designed to answer that question.

To be fair,

What CVSS does well. It makes severity levels comparable across vendors, it can be broken down and audited, the vector shows how the score was derived, and it is the common language spoken across half the industry. None of that should be replaced. It simply needs to stop standing alone.

Five Blind Spots

A significant portion of findings concerns code that never actually makes it into the shipped product: test dependencies, unused modules, optimized-away paths, or a library that is only needed during the build. The score for these findings is still 9.8. And each one still costs time for a manual assessment.

The answer to this is VEX (Vulnerability Exploitability eXchange): a formal, machine-readable statement of whether a product is affected, using one of the standardized justifications, such as “vulnerable code not present” or “vulnerable code not in the execution path.”

The difference between this and simply dismissing a finding is the evidence: a dismissed finding is a claim; a VEX statement with a justification and supporting evidence stands up to scrutiny.

Every assessment that lacks this knowledge will flag the component as vulnerable, with a score, a red bar, and a ticket. On a well-maintained system, these are not just a handful of cases: in a trial using a real-world package list, Curator Pro identified 601 (component, CVE) pairs as demonstrably fixed that a generic assessment would have reported as vulnerable.

Hundreds of false positives are the most common reason a tool gets switched off again. And the error is not symmetrical: anyone who ignores the distribution’s perspective does not just produce noise—they also miss genuine findings.

Security information is published for the source package, but what is installed are binary packages—the tracker lists openssl, while the device has libssl3; the tracker lists glibc, while the device has libc6 and libc-bin. If you skip this translation, you will find nothing for some of the most common system libraries and quietly report the system as “clean.”

• EPSS (Exploit Prediction Scoring System) estimates daily the probability that a vulnerability will be exploited within the next 30 days. Only a small fraction of all CVEs ever published are actually exploited.
• The KEV Catalog maintained by the U.S. agency CISA lists vulnerabilities for which exploitation has been observed.

The difference between the two is not a subtle distinction, it is the foundation of any reliable prioritization: EPSS is a prediction; KEV is an observation.

A KEV entry should therefore carry more weight than even the highest possible EPSS score, otherwise a prediction would outweigh evidence. The reverse is true as well: a 6.1 with a KEV entry belongs ahead of a 9.8 that no one has touched in three years.

That is exactly what the Environmental metrics are meant to address. But in practice, they are almost never maintained because they would have to be recorded for each finding, even though the answer is always the same for each product.

The solution is to ask the question where it belongs: How critical a failure is to the operator’s mission and to people is a property of the product.

Once maintained, that information can feed into every decision—instead of being guessed a thousand times.

In both cases, the third deadline is tied to a different anchor than the moment of becoming aware, and that anchor does not even exist at the outset. A table of CVSS scores cannot capture this distinction. It does not even tell you which of your findings actually sits on a shipped release and is therefore subject to reporting.

The Biggest Blind Spot: “No Findings” Does Not Mean “Assessed”

An empty report is the most reassuring output a tool can provide, and the most dangerous. Because it can have two completely different meanings:

1. All components were queried, and none are affected.
2. The tool never had a key for half of the components, so it could not have queried them in the first place.

No CVSS score in the world makes this distinction visible, because in the second case, there simply is no score. That is why Curator Pro measures coverage as a separate metric: the proportion of components that can actually be queried by the enabled sources, broken down into queryable, source disabled, and no key available, along with the additional coverage that enabling another source would provide.

A security statement that does not know its own blind spots is not a security statement.

What takes its place – not instead of CVSS, but around CVSS

The answer is not a better score, but rather separating the questions:

SSVC (Stakeholder-Specific Vulnerability Categorization), developed by CERT/CC, is where the break with score-based thinking happens: instead of a number, it delivers an action. Four questions—Is it being exploited? Is the attack automatable? How significant is the technical impact? How critical is the product to the mission and to people?—and four possible outcomes: Track (monitor), Track* (increased attention), Attend (address promptly), and Act (take immediate action).

That can be taken straight into sprint planning. “9.8” cannot.

How Curator Pro Implements This

Curator Pro is a platform for Software Composition Analysis and CRA compliance. For the purposes of this article, eight building blocks are relevant, all visible in the same interface where the findings are displayed.

The Action Priority (0–100)

sits next to the CVSS value, not in its place. It combines what is already attached to the finding: severity, EPSS, KEV status, the ENISA designation “actively exploited,” the reachability of the vulnerable code, an existing SSVC decision, and the VEX status. One click shows the complete calculation, each contribution with its score and rationale, followed by the total.

A black-box number would be worthless in a compliance product: the first challenge (“why is this above that one?”) would undermine trust, and after that everyone would go back to sorting manually. The weights are a setting, not a trade secret.

The SSVC Decision Tree

is guided, and the result appears live as soon as all four axes have been set—not only after saving. Seeing how an answer shifts the result helps users understand the tree. Only evidence-based values are prefilled: if the vulnerability appears in the KEV Catalog, Curator Pro sets the first axis to actively exploited and cites the evidence.

It never sets no evidence automatically—whether something is not being exploited cannot be measured. The decision is saved together with its vector (SSVCv2/E:A/A:Y/T:T/M:H/D:Act/), because that is exactly what an auditor will ask for.

The File Inventory Evidence

answers, without any code analysis, whether the vulnerable code is actually shipped. If an advisory identifies the affected source file and that file is not present in the component’s known file inventory, Curator Pro generates an evidence-based suggestion: “not affected / vulnerable code not present”—with the file list as supporting evidence.

And when the assessment cannot reach a conclusion, it says why, using four distinct reasons. A box that simply stays silent would make “not assessed” look like “assessed and clean.”

Distribution Advisories

read the package manager’s inventory directly from the uploaded archive (/var/lib/dpkg/status, /lib/apk/db/installed, /etc/os-release), translate binary packages into source packages, and assess the backported revision.

Without a known release, the component is marked not assessable, not silently cleared.

The Remediation Plan

calculates what nobody else does: for each component, the smallest target version that closes all of its findings. It includes the change risk (patch / minor / major), intermediate steps, risk points resolved per unit of effort—and, most importantly, how many findings remain open afterward.

A plan that says “upgrade to 2.4.1” while hiding that information would be worse than no plan at all: the team would assume the component was fully remediated afterward.

Time-Bounded Risk Acceptance

captures the most common real-world state of a finding—neither “not affected” nor “fixed,” but “affected, will be fixed in 4.2, and we accept the risk until then.”

It requires a rationale and a compensating control, an expiration date, and four-eyes approval. An acceptance without a rationale is suppression; one without a compensating control does not answer the question every assessment will ask next.

The Reporting Clock

tracks both CRA triggers, each with its own anchor. The moment of becoming aware is explicitly recorded rather than inferred from when the ticket was created—it almost always occurred earlier, and that difference is precisely what a regulator cares about.

The clock is started manually: clicking the control starts a legal deadline, and a tool that automatically starts the 24-hour clock would either create false alarms involving authorities or start a clock that nobody notices.

Security Metrics

close the loop: How long has a finding remained unassessed? Are we meeting our own deadlines? Are we working down the backlog or merely managing it?

Where a metric could not be determined, the system shows a dash with the reason underneath—not a reassuring zero.

Three Principles That Hold It All Together

01 Evidence Beats Prediction.

An observation carries more weight than any prediction. That is why EPSS feeds into the ranking, but not into the SSVC decision tree—mapping it to “public exploit code” would confuse prediction with observation.

02 Unknown Never Scores.

A signal that was never assessed should have neither a positive nor a negative effect. A missing value must not be treated as 0—otherwise “never assessed” silently becomes “nothing to worry about.”

03 A Suggestion Is Not a Decision.

Reachability analyses, knowledge-base matches, and automatic VEX suggestions suggest; a human accepts them with a click, and that acceptance becomes the documented curation decision. Regulatory evidence generated solely by a machine does not stand up to scrutiny.

Conclusion

CVSS is a good answer to a question you did not ask.

The question is not “how severe is this vulnerability?” but rather: Does it affect our product—is it being exploited—what should we address first—and by when do we need to have done it? Four questions, four different instruments. A single score cannot answer any of them, and it was never designed to.

In the end, the difference between a tool that shows findings and one that makes findings actionable comes down to exactly this: whether, next to the number, it tells you where that number comes from, what it does not know—and what you should do about it.

Curator Pro

Bitsea’s SCA and CRA compliance platform: import software bills of materials and source code, identify components, licenses, and vulnerabilities, document assessment decisions in an audit-proof manner, and generate the resulting regulatory evidence—all optionally without any internet connection.

Get in touch with us if you would like to see what your findings look like with an action priority, SSVC, and coverage metrics.