Flag missing context in triage

Vulnerability triage sounds clean on paper. A CVE comes out, it gets a score, the patch queue moves. But real teams know the ugly part — the record often tells you that a bug exists without telling you the two things that matter most in the first hour: what has to be true for an attacker to use it, and what you could actually watch for in your environment. That gap is why “critical” bugs keep eating time while some medium-severity issue turns out to be the real fire. CISA’s recent Vulnrichment work is basically an attempt to fix part of that context problem, but it also makes clear what the ecosystem still does not carry well. (cisa.gov) ### What’s the missing piece in normal CVE triage? A plain CVE record is a naming and exchange system first, not a full operational briefing. The current CVE schema supports rich fields and enrichment, but the baseline record still centers on things like affected products, versions, descriptions, and references. That is useful, but it does not guarantee the r(cisa.gov)elemetry. In practice, that means two bugs with similar severity can have wildly different real-world urgency. (cveproject.github.io) ### Why doesn’t CVSS solve that? Because severity is not the same thing as exploitability in your shop. CVSS tells you how bad successful exploitation could be under a defined scoring model. It does not answer whether attackers are likely to bother, whether the bug is easy to automate, or whether your setup even exposes the vulnerable path. That is exactly why newer prioritization layers have grown around CVE data instead of replacing it. (cisa.gov) ### What is CISA adding now? CISA, acting as the CVE Program’s first Authorized Data Publisher, enriches CVE records in a separate ADP container rather than rewriting the original CNA entry. For every new CVE record, CISA adds three SSVC decision points on a first pass: Exploitation, Automatable, and Technical Impact. For some records, it also adds missing CVSS, (cisa.gov)o actual triage instead of leaving defenders with a naked identifier and a severity label. (cve.org) ### What do those SSVC fields actually tell you? They answer questions defenders ask in standup. Has exploitation been seen in the wild, or is there only a proof of concept? Can the attack path be automated at scale? If exploitation works, does it give partial or total control? CISA’s SSVC model then turns those inputs into response buckets lik(cve.org) a dashboard. (cisa.gov) ### So why are teams still frustrated? Because even enriched records can stop short of the local “can this hit us today?” question. A defender often needs prerequisites — exposed service, valid credentials, a specific feature enabled, adjacent network position, user interaction, unusual configuration. They also need detection hooks — logs, process behavior, netwo(cisa.gov)ta. CISA itself frames Vulnrichment as adding context and actionable insight because basic CVE publication alone is rarely enough to act. (cisa.gov) ### Don’t KEV and EPSS already cover urgency? They help, but they answer different questions. KEV tells you a vulnerability is known to have been exploited in the wild and should feed prioritization. EPSS estimates the probability that a published CVE will be exploited in the next 30 days. Both are extremely useful. But neither one tells your SOC exactly what(cisa.gov)oon. (cisa.gov) ### What would a “missing context” flag actually do? Basically, it would separate “low information” from “low risk.” That is the key distinction. If a disclosure lacks exploit prerequisites or concrete detection guidance, the right label is not “probably fine.” The right label is “decision quality is degraded.” That flag would force analysts to ask for the missing pieces before(cisa.gov)d is getting better at enrichment. But the last mile is still operational context. Until disclosures routinely carry exploit prerequisites and detection clues, triage teams will keep mistaking incomplete information for low urgency.