Static SBOMs are the compliance baseline most organisations recognise. You generate them at build time, file them away, and forget about them until the next audit. In a world of continuous deployment and AI-assisted development, they are almost immediately out of date.
AI coding agents widen the gap between recorded inventory and actual production state, writing code and selecting packages faster than manual processes can close. Treating SBOM generation as a checkbox gives you documentation, not defence. This article traces the evolution from the static SBOM to the structural shift that makes supply chain security operational — a paradigm shift that fits into the broader Project Lightwell story.
What is the static SBOM problem and why do point-in-time snapshots fail in 2026?
A static SBOM is generated at a single point and decays immediately. Cloudsmith describe it as printing a map of a city where the roads change every 24 hours. The document is not flawed, but without an operational workflow it becomes a liability.
Most SBOMs are generated from source code, missing containers and binaries that enter the supply chain outside the build pipeline. Binary lifecycle management governs compiled artefacts with the same rigour as source dependencies, closing that gap. Without reachability analysis, static SBOMs report every CVE regardless of whether your code calls the vulnerable function. 96% of dependencies flagged with critical vulnerabilities are not reachable at runtime. Security teams chase phantom CVEs while real risks go unnoticed.
AI coding assistants pull dependencies without explicit approval and hallucinate package names 5.2% to 21.7% of the time. Last year saw 48,000 new CVEs while 11.7 million new packages entered supply chains. If your SBOM is a PDF updated only when a release ships, it is a compliance artefact. An operational SBOM is continuously updated and enriched with VEX and EPSS data.
What is a living SBOM and how does it differ from a compliance snapshot?
A living SBOM is a queryable, decision-ready security asset pulling real-time vulnerability data, EPSS scores, and VEX data. It layers on reachability analysis, exploit probability, and runtime awareness. SPDX 3.0 (2024) introduced AI, Data, Build, and Security profiles; CycloneDX 1.7 extends to hardware, machine learning, and cryptographic bills of materials. But here is the complication. A living SBOM stays current and tells you what is wrong, but it remains passive. Living SBOMs are the necessary intermediate step, not the destination. OpenSSF tooling provides open source foundations for this shift, and Lightwell’s enterprise clearinghouse operationalises living-SBOM concepts at enterprise scale.
What is agentic governance and why does it matter for AI-assisted development?
Agentic governance is SBOMs that act, not just report. Continuous provenance verification cryptographically verifies chain of custody using Sigstore and SLSA attestations. Automated policy enforcement blocks non-compliant artefacts before deployment. Reachability analysis filters exploitable CVEs from noise. Automated remediation collapses detection-to-fix from weeks to hours. These enforcement workflows are enriched by AI-powered vulnerability discovery, which feeds real-time data into living SBOMs.
AI coding agents are autonomous actors introducing new attack vectors. Slopsquatting, where attackers register malicious packages under hallucinated names, is a growing threat. 45% of AI-generated code contains security flaws, exceeding what manual review can govern. Zero-trust CI/CD becomes the enforcement point: ephemeral build agents generate provenance data that agentic governance uses to enforce policies before production. Non-Human Identity gives every AI agent a distinct credential, turning compliance into a byproduct of engineering. That identity model becomes important when you consider how agents connect to your systems.
What is Model Context Protocol governance and why is it a supply chain concern?
Model Context Protocol (MCP) is how AI agents connect to external tools and services. Every MCP connection is a trust boundary. MCP governance catalogues MCP servers, logs agent queries, and enforces least-privilege access. As AI tools integrate via MCP, the protocol becomes a supply chain surface where a compromised server can poison package selections or exfiltrate source code. JFrog reported a 451% surge in malicious npm packages. Without governance, MCP servers become unmonitored ingestion channels for compromised artefacts. OX Security disclosed a flaw exposing 200,000 vulnerable MCP instances across 150 million package downloads. MCP governance sits within agentic governance: one governs what agents do, the other governs how they access the systems they do it through.
SBOM-based compliance vs. agentic governance: which approach will actually reduce supply chain breach risk?
SBOM-based compliance satisfies the EU Cyber Resilience Act, CMMC 2.0, and DORA, but creating a document does not stop an attack. It proves what was in your software at a moment, not that it is safe now. The goal is making compliance a byproduct of engineering. Agentic governance reduces breach risk actively: pipeline gates block non-compliant packages before production, provenance verification detects unauthorised modifications, reachability analysis filters phantom CVEs, and remediation accelerates fixes from weeks to hours. SLSA Level 3 requires provenance attestations with build isolation, and Sigstore provides the signing infrastructure to operationalise them. Key frameworks: SLSA, NIST SSDF, OpenSSF, SPDX, CycloneDX.
How can organisations assess whether their SBOM practices are operational or just compliance artefacts?
Can you answer an auditor’s question by running a query, or do you assemble spreadsheets? If your SBOM is a PDF generated at build time and updated only when a release ships, you have a compliance artefact. An operational SBOM is continuously updated, enriched with VEX, EPSS, and reachability analysis, correlated against runtime, and feeding automated CI/CD policy decisions. The auditor test: did you use a vulnerable Log4j version in June? A compliance-artefact organisation searches emails and produces a dated file. An operational organisation queries an immutable supply chain data platform and answers in seconds. CISA’s Shared Vision of SBOM frames this as the difference between a document and operational intelligence. The transition applies regardless of size: move to continuous generation, add enrichment, implement reachability, and integrate into CI/CD policy.
How to evaluate a software supply chain security platform in 2026
Once you know where you stand, what platform takes you forward? Prioritise continuous operation over point-in-time scanning, automated CI/CD gating over report generation, and pipeline integration over standalone tooling. The criteria have shifted from what does it find to what does it stop. Verify SLSA attestations and Sigstore signatures at every pipeline stage. Define security policy as version-controlled code and enforce it identically across environments. Govern compiled artefacts with the same rigour as source dependencies. Catalogue MCP servers, log access, and enforce least-privilege controls. Look for ephemeral build agents, deployment-gating policies, and automated remediation that creates fix PRs with human-in-the-loop approval. 48% of organisations still need a week or more for compliance evidence. A platform stopping five risks before production beats one generating two hundred reports.
The destination: from documentation to defence
You probably opened this article thinking SBOMs were the answer. They are the starting line: necessary for regulators, insufficient to stop an attack. The destination is agentic governance: continuous, automated oversight treating every actor as a governed security principal. The evolution arc is three maturity stages. Most organisations are at stage one, generating static SBOMs and filing them. Some reach stage two, with living SBOMs that stay current. The threat landscape in 2026 has made stage three the operational baseline. When agents produce code faster than humans can review, documentation processes cannot keep pace — the root causes driving the governance revolution are structural, not temporary. The criteria have shifted: what does it stop matters more than what does it find. Internalising that shift leads to different procurement decisions. Documentation is not defence. The distinction is the difference between having an inventory of your risks and actually governing them.
Frequently Asked Questions
Do we still need static SBOMs if we adopt agentic governance?
Yes, absolutely. Static SBOMs are the evidentiary foundation that agentic governance builds upon. Regulators under the EU Cyber Resilience Act and CMMC 2.0 will continue demanding compliance artefacts, and a signed SBOM at build time provides the baseline inventory that continuous enrichment extends. The goal is not to replace static SBOMs but to stop treating them as sufficient. Agentic governance makes the static SBOM the starting line, not the finish line.
Is agentic governance just a rebrand of DevSecOps?
No, though the two are complementary. DevSecOps embeds security checks into the development lifecycle, shifting detection left. Agentic governance goes further by treating every actor in the supply chain, human, CI/CD runner, and AI agent, as a governed security principal with automated policy enforcement at every boundary. It adds continuous provenance verification, non-human identity management, and automated remediation workflows that DevSecOps tooling alone does not provide.
How does reachability analysis actually filter out phantom CVEs?
Reachability analysis traces whether your application’s code execution path ever reaches a vulnerable function inside a dependency. If you import a library with a known CVE but never call the affected method, that vulnerability is not exploitable in your context. Sonatype’s analysis found that 96 percent of dependencies flagged with critical vulnerabilities are not reachable at runtime. This filtering transforms an unmanageable alert flood into a focused list of genuinely exploitable risks worth immediate attention.
Can agentic governance prevent the next xz utils style supply chain attack?
It can materially reduce the blast radius. An xz utils style attack, where a trusted maintainer inserted a backdoor into a compression library, would trigger multiple agentic governance controls: provenance attestation verification would detect unauthorised build modifications, policy-as-code would flag anomalous binary signatures at the CI/CD boundary, and automated reachability analysis would identify which services actually link the compromised binary. It is not a silver bullet, but it collapses the detection window from months to minutes.
What does agentic governance cost compared to traditional SCA tooling?
The cost comparison is misleading if framed as licence versus licence. Traditional SCA generates reports that require human triage, and the real cost is the engineering hours spent chasing phantom CVEs and manually assembling compliance evidence. Agentic governance platforms shift spend from reactive labour to automated enforcement. Organisations that benchmark by MTTR reduction and phantom CVE filtration rates rather than seat licences consistently find the operational savings outweigh the platform investment within the first year.
Is agentic governance only viable for large enterprises?
No, the architectural principles scale down effectively. Small teams can adopt policy-as-code enforcement at the CI/CD boundary, Sigstore-based provenance signing, and reachability analysis without building enterprise-grade clearinghouse infrastructure. Open source tooling from the OpenSSF, including Protobom and BomCTL, provides a starting point. The key shift is cultural, treating SBOMs as queryable security assets rather than compliance documents, and that shift costs nothing but attention.
How do we govern AI coding agents that select dependencies we did not approve?
This is the core case for agentic governance. AI coding agents must be treated as governed security principals with distinct non-human identities, auditable credential trails, and policy-enforced guardrails. Your CI/CD pipeline should intercept every dependency introduced by an AI agent, verify its provenance via Sigstore attestations, check it against your curation policy, and block non-compliant packages before they reach a merge. The agent does not get a free pass just because it writes code faster than a human.
What happens when a vulnerability has no CVE yet?
Agentic governance does not depend solely on CVE feeds. Continuous provenance verification detects tampering regardless of whether a CVE has been assigned, binary integrity checks catch unexpected changes in compiled artefacts, and policy-as-code can flag packages from unvetted registries or maintainers with anomalous commit patterns. The framework also consumes EPSS scores and threat intelligence feeds that surface emerging risks before they acquire a CVE identifier. Zero-day coverage is built into the model, not bolted on.
Does agentic governance work with proprietary and internal dependencies?
Yes, and this is one of its strongest use cases. Internal libraries and proprietary binaries are often the least governed because they fall outside public vulnerability databases. Agentic governance applies the same provenance verification, policy enforcement, and binary lifecycle management to internal artefacts as it does to open source dependencies. You define the policy once, version it as code, and enforce it identically across every dependency regardless of origin.
How do I begin moving from static SBOMs toward agentic governance?
Start with three concrete moves. First, shift from periodic to continuous SBOM generation so your inventory stays current. Second, add VEX and EPSS enrichment so you know which vulnerabilities actually affect you and how likely exploitation is. Third, implement reachability analysis to filter out phantom CVEs. Once these three capabilities are in place, introduce policy-as-code at your CI/CD boundary to block non-compliant artefacts before deployment. Each step delivers immediate risk reduction while building the foundation for the next.
