Security teams used to have one job when a scanner fired: check the CVSS score, patch the red ones first. That model is now breaking in two directions at once. On one side, the volume of disclosed vulnerabilities keeps climbing — NVD logged more than 40,000 CVEs in 2024, and 2025 is on pace to beat that number again. On the other side, AI coding assistants are shipping code faster than security teams can review it, quietly widening the attack surface with every autocomplete suggestion. A 2024 GitClear analysis of 153 million changed lines of code found a measurable rise in duplicated and "churned" code correlating with AI-assisted development — the kind of pattern that hides vulnerable logic in plain sight. Sonatype and other legacy SCA vendors built their prioritization models for a slower, human-authored world. This post breaks down what's actually changed, why score-based triage no longer holds up, and what a prioritization model built for the AI era needs to do differently.
Why doesn't CVSS severity alone predict real-world risk anymore?
Because fewer than 5% of published CVEs are ever actually exploited in the wild, yet CVSS alone can't tell you which 5%. Research from the FIRST.org EPSS project has repeatedly shown that a huge share of "Critical" (9.0+) CVSS-scored vulnerabilities sit unexploited for years, while some "Medium" severity flaws get weaponized within days of disclosure — the Log4Shell-adjacent Text4Shell (CVE-2022-42889, scored 9.8) and the far quieter CVE-2023-4966 "Citrix Bleed" (scored 7.5) are a good contrast: Citrix Bleed was added to CISA's Known Exploited Vulnerabilities (KEV) catalog within three weeks of disclosure and used in ransomware campaigns against Boeing and others, despite a "High" rather than "Critical" score. Sonatype's IQ Server and most SCA tools still default to severity-and-policy-based gating, which means teams triaging by CVSS number alone are statistically likely to fix the wrong 20 issues before lunch. The fix isn't a better score — it's combining exploit-probability data (EPSS), active-exploitation data (KEV), and reachability analysis into one ranked queue.
How is AI-generated code changing what "vulnerable" even means?
Because a growing share of the code entering your repos was never written by a human who understood its security context. GitHub reported in 2024 that Copilot was generating roughly 30-46% of code in files where it was enabled, depending on language, and a Stanford study found developers using AI assistants were more likely to introduce security bugs while also being more confident the code was safe — a dangerous combination auditors call "automation bias." Snyk's 2024 AI Code Security report found that 56% of developers using AI coding tools had shipped AI-suggested code containing a known vulnerability pattern, most commonly injection flaws and hardcoded secrets. This isn't hypothetical: in early 2024, security researchers demonstrated that popular AI coding assistants would recommend deprecated or typosquatted packages when developers asked for common libraries, a technique now nicknamed "slopsquatting." Traditional SCA prioritization assumes vulnerabilities enter your codebase through known, versioned dependencies added deliberately. AI-assisted development breaks that assumption — vulnerable code and malicious packages can now enter through a suggestion accepted in under a second.
Why does Sonatype's approach fall short for AI-era prioritization?
Because Sonatype was architected around component-level intelligence for a world where humans manually chose and vetted dependencies — not one where AI agents and copilots are generating, modifying, and importing code continuously. Sonatype's core strength, its OSS component database (Sonatype OSS Index), is genuinely large — it tracks well over 700,000 open-source projects — but component-level metadata doesn't tell you whether the vulnerable function in that component is ever actually called by your application. Nexus IQ's policy engine is largely severity- and license-driven, which means two teams using identical Sonatype configurations will get identical priority rankings for a CVE even if one team's code path never touches the vulnerable function and the other's exposes it directly to an unauthenticated API endpoint. Sonatype has added SBOM and some exploitability signal in recent releases, but reachability analysis — determining whether vulnerable code is actually invoked at runtime or in the call graph — remains a bolt-on rather than the foundation of how findings get ranked. In an era where AI is generating new call paths and new dependency combinations faster than any human reviewer can map them by hand, a scanner that ranks by component metadata instead of actual code reachability produces a queue that looks thorough but doesn't reflect exploitable risk.
Do EPSS and KEV actually fix the prioritization problem?
Partially — they narrow the list dramatically, but they still don't tell you if the vulnerability applies to how your specific application uses the code. CISA's KEV catalog has grown from roughly 300 entries at its late-2021 launch to over 1,300 by mid-2026, and every entry on it represents a vulnerability with confirmed active exploitation — a far stronger signal than CVSS alone. Layering EPSS (which assigns each CVE a probability of exploitation in the next 30 days, updated daily using real telemetry) on top of KEV lets teams triage the roughly 240,000+ CVEs in NVD down to a working list of a few hundred that matter this quarter. But EPSS and KEV are both vulnerability-centric, not application-centric: they tell you a CVE is dangerous in general, not whether your specific build ever executes the vulnerable function, whether it's reachable from an internet-facing entry point, or whether an AI-written wrapper around that dependency changed the call path since your last scan. Teams that stop at EPSS/KEV filtering still end up patching library versions that are present in a container image but never loaded at runtime — real engineering hours spent on theoretical risk.
Can AI actually make vulnerability triage faster instead of just adding more noise?
Yes, but only when it's scoped to analyzing your actual code paths rather than generating generic advice. Manual triage of a single finding — pulling the CVE detail, checking the changelog, tracing the call graph, deciding on a fix — routinely takes a security engineer 20-40 minutes per finding according to internal benchmarks reported by multiple AppSec teams in 2024-2025 surveys; at a typical mid-size org surfacing 200-400 new findings a month from SCA and SAST combined, that's 65-260 engineer-hours a month spent on investigation alone, before any remediation happens. LLM-based triage agents that read the actual vulnerable function, the surrounding call chain, and the CVE's proof-of-concept can reduce that investigation step to seconds when applied correctly, but only if the model is grounded in your real dependency graph and reachability data — an LLM asked to "explain this CVE" with no code context will happily generate a plausible-sounding risk assessment for a vulnerability that's never actually reachable in your application, which is worse than no answer at all because it's confidently wrong.
How Safeguard Helps
Safeguard was built for this exact gap: prioritization that starts from what your code actually does, not from what a component database says in the abstract. Instead of ranking findings by CVSS severity or component popularity, Safeguard's reachability engine traces whether a vulnerable function in a dependency is actually called from your application's code paths — including code paths introduced by AI-assisted commits — before it ever reaches a human's queue. That reachability signal is combined with EPSS exploitation probability and live CISA KEV status, so the findings that surface first are the ones that are both reachable and actively being exploited, not just theoretically severe.
For the AI-generated code problem specifically, Safeguard continuously maps new commits and dependency changes as they land, flagging when an AI-suggested import introduces a typosquatted or newly-published package, and running the same reachability analysis against freshly generated code that it runs against the rest of the codebase — so a vulnerability introduced by a copilot suggestion this morning gets the same real-context triage as a legacy dependency from three years ago. Where legacy SCA tools produce a static severity-ranked list, Safeguard's triage layer uses code-grounded AI analysis to explain, in plain language tied to the actual call graph, why a specific finding does or doesn't matter for your deployment — cutting investigation time from tens of minutes to seconds while keeping the reasoning auditable for SOC 2 and compliance reviews.
The result is a prioritized queue that reflects three things Sonatype's component-centric model wasn't built to combine natively: real exploitability data (EPSS/KEV), real code reachability, and continuous coverage of the AI-generated code that's now a permanent part of how software gets written. That's the difference between a list of 400 vulnerabilities ranked by severity and a list of 12 that actually need attention this week.