{News}
by alchemain team
Most vulnerability SLAs read something like this: fix Criticals within 15 days, Highs within 30. It sounds rigorous. It assumes every new vulnerability shows up with a severity score attached.
It usually doesn't.
The scoring gap is the rule, not the exception
Sonatype's latest research puts numbers on a problem every AppSec team already feels:
64% of 1,552 open source CVEs it analyzed had no CVSS score at all.
When scores did exist, severity ratings matched across sources only 19% of the time.
The delay before a score appeared averaged about six weeks.
In one recent week (Oct 26 to Nov 2), Sonatype tracked nearly 1,600 new open source vulnerabilities, and roughly 86% hadn't been scored by the NVD. Its own researchers rated almost half of them Critical or High.
So a "Critical within 15 days" policy really means "Critical within 15 days of a score that may arrive in six weeks, may not match another source, or may never arrive." The attacker's clock started at disclosure. Yours started a month and a half later.
Then the blast radius arrives
Scale makes it worse. When a batch of Spring vulnerabilities landed in August 2026, Sonatype counted 91 CVEs across Spring and related projects, touching 148,608 downstream components, including components that bundle vulnerable Spring code inside them.
Each of those components sits inside a Transitive Dependency Graph somewhere. Each upgrade is a chance to break a sibling library, drift a JDK requirement, or trigger a runtime NoSuchMethodError. That's why Veracode's 2026 data shows third-party flaws taking 358 days to fix on average, and why two-thirds of the most dangerous long-lived vulnerabilities come from third-party code.
Governance is necessary. It doesn't fix anything.
The industry's answer was "stop chasing CVEs, start governing dependencies." Govern what comes in, set policy, route decisions to owners.
We agree with the diagnosis. Chasing CVEs one by one, sorted by a score that doesn't exist yet, is a losing game. Policy helps you choose better packages in the first place.
But governance tells you what should happen. It doesn't upgrade 148,608 components or refactor the code that calls a changed API. Somebody still has to make the fix, and today that somebody is a developer with a Jira ticket and a red build.
Replace the severity question with three better ones
The score was always a stand-in for the questions that actually matter:
Is the vulnerable code reachable? Executability & Reachability Analysis answers that from your actual call graph, with or without a CVSS score.
Where does it sit in my dependency graph? A direct dependency, or three levels down behind a library you don't control?
Can I upgrade without breaking production? That needs a real build and real tests, not a version range in a manifest.
If you can answer all three in minutes, the scoring gap stops mattering. You stop prioritizing by a number and start remediating by exposure.
What that looks like with 00felix
Without 00felix | With 00felix |
|---|---|
Wait for a CVSS score to set the SLA clock | Reachability decides exposure on day zero |
Ticket assigned to every team that uses the package | One resolution applied fleet-wide across every affected repo |
Version bump breaks a transitive caller | Transitive Dependency Graph analysis picks a version set that resolves together |
Developer refactors the broken API calls by hand | AST-level refactoring updates the call sites |
CI goes red; ticket reopens | Self-Healing Compile-to-Test Loop iterates until green |
Audit evidence: a closed ticket | Audit evidence: a build-verified, test-passing commit |
00felix is the Agentic Harness for Verified SAST & SCA Remediation: Detect → Refactor → Verify → Deliver. The same loop covers first-party code. When a SAST finding is reachable, 00felix rewrites the vulnerable pattern and proves the fix compiles and passes your tests before opening the PR.
Your engineers stay in control. They review a green, validated PR instead of writing the fix themselves.
The bottom line for AppSec leaders
The scoring system isn't going to get six weeks faster. AI-assisted vulnerability research is only increasing the volume of disclosures. A program that waits for severity, then files tickets, then waits for developers, will fall further behind every quarter.
Security needs to move from "Tell me" to "Fix me."
See how 00felix turns SAST and SCA alert backlogs into green pull requests, by trying it free on any repo.
Just Fix It.
