Why CVSS scores mislead autonomous systems

CVSS was designed to give security analysts a consistent language for discussing vulnerability severity. It does that job reasonably well. What it was not designed for is a machine making a go or no-go decision in a deployment pipeline without a human reviewing the output.

The difference matters more as autonomous systems become the primary consumers of security data. A human analyst reading a CVSS 7.8 score on a vulnerability understands that 7.8 is not the whole picture. They know to check whether CISA has added it to the Known Exploited Vulnerabilities catalog, whether the specific version they run is affected, and whether any of the affected packages in their environment have been supply-chain-compromised regardless of their CVE status. The score is a starting point, not a conclusion.

An autonomous system that branches on a CVSS score has none of that context. It has a number.

What CVSS actually measures#

CVSS assigns a score between 0 and 10 based on the intrinsic technical characteristics of a vulnerability: how it is accessed, how complex exploitation is, whether privileges are required, whether user interaction is needed, and what the impact on confidentiality, integrity, and availability would be if successful. These metrics are constant. The base score does not change when a working exploit is published. It does not change when CISA adds the CVE to the KEV catalog. It does not change when the vulnerability is being actively used in ransomware campaigns.

FIRST, the organisation that maintains the CVSS standard, explicitly states that base scores should not be used alone for prioritisation. The score tells you about theoretical severity. It does not tell you about actual operational risk.

The exploitation gap#

According to Picus Security's Blue Report 2026, only 2.3% of CVSS 7+ vulnerabilities see actual exploitation attempts, while 28% of exploited CVEs carry only medium scores.

Read that again. A system that prioritises all CVSS 7+ vulnerabilities is spending most of its remediation effort on vulnerabilities that never get exploited. Meanwhile more than a quarter of the CVEs that do get exploited in real attacks were scored medium, the threshold many organisations treat as deprioritised.

CISA's Known Exploited Vulnerabilities catalog is the most reliable signal for which vulnerabilities are actually being used by threat actors in production attacks. It includes many vulnerabilities with medium CVSS scores that pose high operational risk because they are being actively targeted regardless of their theoretical severity rating. The KEV catalog and the CVSS score are measuring different things. Treating CVSS as a proxy for exploitation likelihood is the structural error that leads to security teams patching the wrong things first.

The version boundary problem#

CVSS scores are assigned at the CVE level, not the version level. A single CVE affecting nginx can cover dozens of version ranges across multiple release lines. The base score tells you how severe the vulnerability is in theory. It does not tell you whether the specific version you are running is affected.

A system that checks a CVSS score and concludes that nginx is high severity has not answered the operational question. The operational question is whether nginx 1.27.4 specifically is affected by this specific CVE and whether a patched version exists and what that version is.

This version-level resolution is not a minor implementation detail. It is the entire difference between a security signal that is actionable and one that produces alert fatigue. A deployment pipeline that can only determine that a product category has some CVEs is not making useful decisions. A deployment pipeline that can determine whether the exact version it is deploying has a known critical vulnerability with a patched replacement available is making a useful decision.

The supply chain blind spot#

CVSS is built entirely around the CVE framework. It scores vulnerabilities in legitimate software. It has no mechanism for representing a package that has been compromised by an attacker publishing a malicious version through a stolen maintainer credential.

[email protected] carried North Korean malware for several hours in September 2025. Its CVSS score is zero. It has no CVE. A system that makes deployment decisions based on CVSS passes it clean. The same is true for [email protected] and [email protected] at the ChainDrop-compromised version, every package in the Shai-Hulud worm campaign, and every package in the ViteVenom, JoyFill, and WEL1DROPPER campaigns documented in 2026. The [email protected] compromise in March 2026 is a related case: the malicious publish itself had no malware CVE at the time of the attack, though the package carries legitimate CVEs unrelated to the supply chain event.

The supply chain compromise signal and the CVE signal are orthogonal. A package can have a known critical CVE and a clean supply chain. A package can have a compromised supply chain and a CVSS score of zero. A system that only checks one is blind to the other. For the 2026 threat landscape, where supply chain attacks have become a primary attack vector against developer environments, being blind to the supply chain signal is the more dangerous of the two gaps.

What CVSS does not tell you that autonomous systems need to know#

An autonomous system making a deployment or installation decision needs to answer several specific questions. CVSS answers one of them partially and leaves the rest unanswered.

Is this specific version affected? CVSS does not answer this. It scores a CVE. Version-level resolution is a separate engineering problem.

Is this vulnerability being actively exploited right now? CVSS does not answer this. The base score is static. CISA KEV answers this. EPSS adds exploitation probability. Neither is embedded in the base CVSS score.

Has a fix been published? CVSS does not answer this. Patch availability is a separate data point not embedded in the score.

Has this package been compromised through its supply chain? CVSS cannot answer this. No CVE exists for a supply chain compromise.

Is this package name legitimate or hallucinated? CVSS cannot answer this. Typosquatting and slopsquatting have no CVE records.

A security signal that answers one of five questions is not a complete security signal for autonomous systems. It is a starting point that requires significant additional context before it becomes actionable.

What Attestd returns instead#

The Attestd API is designed to answer the questions CVSS leaves unanswered in a single call. For any product version or package, the response includes:

risk_state: the operational risk classification combining NVD data, CISA KEV active exploitation status, and version-specific affected range resolution. Not a theoretical severity score. A verdict: none, low, elevated, high, or critical.

actively_exploited: whether CISA has flagged this CVE as being exploited in the wild. This is the question CVSS base scores never answer.

patch_available and fixed_version: whether a remediated version exists and which version to upgrade to.

supply_chain.compromised: whether this specific package version has been flagged as maliciously modified, independent of any CVE record.

typosquat: whether the package name matches a pattern consistent with typosquatting or AI hallucination.

A live example. [email protected], the version vulnerable to CVE-2025-3248, the entry point for both the JADEPUFFER and ENCFORGE autonomous ransomware campaigns:

curl "https://api.attestd.io/v1/check?product=langflow&version=1.2.0" \
  -H "Authorization: Bearer $ATTESTD_API_KEY"

{
  "risk_state": "critical",
  "risk_factors": ["active_exploitation", "remote_code_execution", "no_authentication_required", "internet_exposed_service", "patch_available"],
  "actively_exploited": true,
  "authentication_required": false,
  "patch_available": true,
  "fixed_version": "1.11.0",
  "max_epss": 0.99996
}

actively_exploited: true and max_epss: 0.9999 are the signals CVSS cannot provide. The base score tells you it is critical. The KEV-enriched response tells you exploitation is essentially certain, that it requires no authentication, and that a specific fixed version exists. Those are the fields an autonomous system can branch on. A number from 0 to 10 is not.

The implication for autonomous systems#

When a human analyst reviews a CVSS score, their expertise fills in the gaps. They check whether the product is in KEV, whether the affected version range matches what they run, whether exploitation is theoretical or active. The score is one input among several.

When an autonomous system reviews a CVSS score with no additional context, the score is the only input. Whatever gaps exist in the CVSS framework become gaps in the system's decision-making. An autonomous deployment pipeline that passes a compromised package because it has no CVE, or deprioritises an actively-exploited medium vulnerability because 5.5 does not trigger its threshold, is not making a security decision. It is following a heuristic that does not match the threat landscape it is operating in.

The machine speed thesis makes this point structurally: if autonomous systems consume security data at machine speed, the security data layer must operate at the same speed and answer the same questions. CVSS answers a subset of the questions and does so statically. The gap between what CVSS provides and what autonomous systems need is the problem Attestd addresses.

Further reading#

The case for why NVD and CVSS-based signals are insufficient for operational use: attestd.io/vs-nvd

How the supply chain signal is independent of the CVE signal: attestd.io/blog/npm-supply-chain-attacks-how-they-work

The JADEPUFFER and ENCFORGE cases where CVSS alone would not have prevented the attack: attestd.io/blog/encforge-jadepuffer-langflow-ai-ransomware