The Patch Is the Exploit: Why Your SBOM Stopped Working in 2026
Time-to-exploit has gone negative and NVD enrichment is collapsing. Why the legacy SBOM can't keep pace with AI-era exploitation — and what replaces it.
On 8 April 2026, the maintainers of Marimo — an open-source Python notebook used heavily in AI and ML pipelines — published an advisory for a pre-authentication remote code execution flaw, later assigned CVE-2026-39987. There was no public proof-of-concept. There was no exploit code circulating. There was just the advisory text.
Nine hours and forty-one minutes later, Sysdig observed the first in-the-wild exploitation. The attacker had read the advisory, built a working exploit from it, opened a shell, and exfiltrated AWS credentials — the last part in roughly three minutes.
Now ask an uncomfortable question. In those nine hours, what did your SBOM do?
It did what SBOMs do. It sat in an artifact registry, correctly listing a package version, waiting for a vulnerability database to tell it that the version was bad. By the time the enrichment landed, the credentials were gone.
This is not a tooling gap. It is an arithmetic problem, and the arithmetic has inverted.
The window didn’t shrink. It closed.
For two decades, every vulnerability management process ever designed rested on one assumption: there is a gap between disclosure and exploitation, and defenders live inside it.
Identify. Prioritise. Test. Schedule. Deploy. Verify. That sequence assumes time exists.
Look at what happened to that time:
| Year | Median time from disclosure to first observed exploit |
|---|---|
| 2018 | ~771 days |
| 2021 | ~84 days |
| 2023 | ~6 days |
| 2024 | hours |
| 2026 | routinely negative |
(Source: Sysdig’s Zero Day Clock, built on thousands of CVE–exploit pairs from CISA KEV, VulnCheck KEV and ExploitDB.)
“Negative” is not rhetorical. Mandiant’s M-Trends 2026 puts mean time-to-exploit at roughly minus seven days — on average, exploitation now precedes the patch. CrowdStrike’s 2026 Global Threat Report finds 42% of exploited vulnerabilities were attacked before public disclosure. Sysdig’s data shows 67% of exploited CVEs in 2026 were zero-days, up from 16% in 2018.
The gap where your patch cycle lives has been squeezed out of existence.
What changed: the cost of weaponisation collapsed
The mechanism is not mysterious. Two attacker tasks that used to be slow, expert, and expensive have become fast, automated, and cheap.
Finding the bug. Frontier models now do at scale what used to require a specialist.
Weaponising the patch. This is the part that should worry supply chain teams most, and it is the part almost nobody has priced in.
N-day exploitation works by patch diffing: compare the pre-patch and post-patch binary, find what changed, reverse-engineer the bug the patch was written to fix. The patch is the map. Historically that work took expert-weeks — WannaCry landed 59 days after MS17-010; the public Citrix Bleed exploit took about two weeks — which is exactly why staged, multi-week rollouts were safe.
In June 2026, Anthropic published measurements of how far LLMs have compressed that work. Given only what an attacker gets on patch day — the vulnerable and patched binaries, public symbols, a Ghidra decompilation, a function-level diff, and the vendor advisory — their Mythos Preview model produced working proof-of-concepts for 18 of 21 Windows kernel vulnerabilities in under six hours, at a total cost of about $2,200 in API credits. Their own summary of the implication is blunt: the industry’s release cadences were built on the assumption that weaponising a patch takes expert-weeks. It doesn’t. “N-day” is now closer to “N-hour.”
Sit with what that means for a supply chain team. A single actor with no particular expertise can turn a month of published patches into working exploits in an afternoon, for the price of a laptop. Your staged rollout window is now the attacker’s working window — and you are the one who told them where to look, by publishing the fix.
Why the SBOM specifically fails
The SBOM was a good answer to the 2018 question. It fails now for three distinct reasons — and it is worth separating them, because they break in different ways.
1. It’s a snapshot, and the shutter speed is wrong
An SBOM is a point-in-time inventory. Generate it at build, export it quarterly, attach it to a compliance packet. That cadence was fine when exploitation took 84 days.
When exploitation precedes disclosure, a quarterly artefact is not a security control. It is a receipt.
2. The lookup table is quietly failing
This is the one nobody talks about, and it’s fatal. An SBOM has no security value on its own — it’s a list of names. Its value comes entirely from joining that list against an enriched vulnerability database.
That database is capitulating. On 15 April 2026, NIST formally moved the National Vulnerability Database to a triage model: roughly 29,000 backlog CVEs reclassified as Not Scheduled, with enrichment committed only for an estimated 15–20% of incoming CVEs — those intersecting KEV, federal software, or critical-software lists. Meanwhile CVE submissions grew 263% between 2020 and 2025, running at roughly 131 disclosures per day.
So: the volume of vulnerabilities is exploding, the enrichment that makes SBOMs actionable is being rationed, and the exploitation window has gone negative. Every leg of the model is failing simultaneously. Scanning faster does not help. You cannot scan your way to negative time.
3. It inventories the wrong things
Even where the SBOM works perfectly, it is now cataloguing a shrinking fraction of your actual attack surface.
AI-native systems are assembled from components that never appear in a manifest: foundation models called through a single API line, models pulled from Hugging Face and swapped weekly, prompt templates, fine-tuning datasets, agent frameworks, tool definitions, and MCP servers spun up dynamically at runtime. Snyk’s own 2026 telemetry is striking here: for every AI model deployed, enterprises introduce close to three times as many untracked components, with 82% of AI tooling sourced from external packages.
None of that shows up in a package-lock.json. A model can be poisoned, a prompt template can be injected, an MCP server can be malicious — and your application code hasn’t changed by a single byte. The SBOM stays green.
And underneath all of it, AI coding agents are now the largest contributors to your dependency graph, pulling in transitive packages no engineer on your team ever evaluated.
The market has noticed — but inventory is not the answer
Snyk, to their credit, has been early and loud here. Their snyk aibom command generates a CycloneDX inventory of models, agents, tools, datasets and MCP clients/servers, and their positioning has moved from AI-BOM toward AI Security Posture Management and, most recently, continuous offensive testing — the argument being that visibility must become governance, and governance must become proof.
We agree with the direction of travel. We think the industry is still framing the problem one layer too high.
A better inventory of a broken model is still a broken model. An AI-BOM tells you what you have. It does not tell you what an autonomous adversary can reach in your runtime in the next nine hours. When 67% of exploited CVEs are zero-days and the enrichment pipeline covers a fifth of new disclosures, “what do I have, and does it match a known CVE?” is the wrong primary key.
The right primary key is exploitability.
Zerberus Trace AI: built for negative time
Trace AI starts from a different question than “what do I have?” It asks “of everything I have, what is actually being exploited in the wild right now — and can I prove how I decided?”
Underneath it sits ZSBOM — our open-source scanner. That is a deliberate architectural and philosophical choice, and it is worth being explicit about why.
The whole game now is separating the handful of dependencies that matter from the thousands that don’t. Every scanner claims to do this. The difference is whether you can check their work. When a tool tells you a CVE is not worth your time, it is asking you to accept a negative finding and stake production on it — a much heavier ask than flagging a positive one. Most vendors ask you to take that on faith from a black box.
ZSBOM’s classification logic is public. You can read exactly how it scores risk, run it in your own CI, fork the policy, and check every call it makes. Trace AI is the platform on top: continuous scanning across your repos, threat-intelligence enrichment, license and vendor visibility, and audit-ready evidence export. ZSBOM is the engine — and it’s open.
What that gives you:
- Real-time SBOMs, not quarterly exports. CycloneDX and SPDX generated from your CI, with direct and transitive dependencies tracked continuously as your code changes — because an artefact generated once at build time is already stale by deployment.
- Exploit-aware prioritisation. Instead of dumping every CVE, ZSBOM cross-references multiple threat-intelligence sources to surface which vulnerabilities have known exploits circulating in the wild. In a world where two-thirds of exploited CVEs are zero-days, “is this being weaponised now” is a far better triage key than CVSS severity — and it collapses the queue from thousands to the few that need action today.
- License and vendor visibility. GPL, LGPL and other copyleft exposure flagged instantly; APIs, SDKs, SLA expiry and breach history tracked alongside your code dependencies — the things that surface late in an enterprise procurement review, caught early.
- Auditable by construction. Open classification logic and policy-as-code mean your security team, your auditor, and your enterprise customer’s third-party risk reviewer can all inspect the same source of truth. In a market where every vendor now claims to know what’s “really exploitable,” being checkable is the differentiator no black box can copy.
- Evidence, not attestation. SBOM data maps cleanly to ISO 27001, SOC 2 and other framework controls, exported as audit-ready reports — so compliance becomes a by-product of security rather than a quarterly spreadsheet exercise.
Start with ZSBOM. Point it at a repository today, for free — up to five repos, no card. If what it surfaces is uncomfortable, that’s what Trace AI is for.
What to do on Monday, whatever tooling you use
You do not need to buy anything today to start closing this gap:
- Assume the patch is the exploit. Treat any published fix in an internet-facing or credential-holding dependency as an active exposure, not a scheduled task. Note that CISA is reportedly weighing a cut to its KEV remediation window from two weeks to three days, explicitly in response to AI-accelerated exploitation — that is where the regulatory floor is heading.
- Stop triaging on CVSS alone. A CVSS 6.0 with a known exploit circulating outranks a CVSS 9.8 that no attacker has ever touched. Prioritise on what’s being weaponised now, not on theoretical severity.
- Inventory what your SBOM cannot see. Ask one question in your next architecture review: which models, agents, tools and MCP servers are running in production, and who approved them? Standard SBOM tooling — ours included — is built around package ecosystems, so today this is a question for your architecture review, not a scanner. If nobody can answer within an hour, that is your finding.
- Instrument your runtime. Detection time, not patch time, is now the control that determines outcomes.
- Assume your AI coding agents are contributing dependencies nobody reviewed. Because they are.
Don’t bring a photograph to a gunfight. The attackers stopped taking snapshots in 2024.
Point ZSBOM at a repository and see which of your dependencies are actually being exploited in the wild — not just which ones have a CVE. It’s open source, so you can read exactly how it decides. When you want that running continuously across every repo, with license, vendor and audit evidence attached, that’s Zerberus Trace AI. First five repos free.
Where does your team sit today: still patching after disclosure, or already detecting before it?
