Continuous SBOM Generation vs Point-in-Time Snapshots

Software bills of materials go stale the moment a dependency updates, gets swapped, or turns malicious after the fact, and most security programs still generate one at release and file it away as if that moment of accuracy holds forever. It doesn't. Continuous SBOM generation, built into the pipeline as a native stage rather than a release-day export, is the only architecture that keeps pace with how modern software actually changes. Anyone still treating an SBOM as a document produced once a quarter is solving a compliance problem, not a security one, and those are not the same problem wearing different clothes. This piece explains why the snapshot model fails structurally, what regulators are now demanding instead, and what has to change, in tooling and in organizational ownership, to close the gap.

Plenty of security teams generate an SBOM at release, file it somewhere, and treat it as evidence of an ongoing security posture. It isn't. "Plenty of organizations can produce an SBOM document," says Justin Beals, CEO of Strike Graph. "Far fewer can prove the components listed in it are still accurate six months later." That distinction is the whole article. A dependency can change, get replaced, or get compromised without a new build ever running, and the decay that follows is a structural consequence of how these systems work. It's a structural fact about the gap between a static record and a moving environment.

Take a lock file that declares a dependency as "^4.17.0." The version actually resolved and installed might be 4.17.21, and a stale SBOM generated before that resolution may still show the range instead of what landed on disk. Or consider the hash gap: a package identifier tells a scanner what a component is supposed to be, but if someone swaps out the library's actual contents while leaving the name and version untouched, that identifier still looks clean. Only a hash of the real bytes catches the substitution. "It's a snapshot," Beals says, and a static list filed once and never revisited isn't proof of anything ongoing.

The scale of exposure makes this worse than it sounds. Somewhere between 70 and 90 percent of a typical modern application is open-source dependencies, according to Anchore, which means the surface area that can shift underneath a team, without anyone touching a line of the application's own code, dwarfs the part anyone actually wrote. Layered on top of that is a second, quieter failure mode, and it's arguably the more dishonest one: some vendors generate SBOMs that prioritize a clean appearance over genuine accuracy, a pattern that undermines the very visibility these documents are supposed to provide.

How fast the threat environment moves relative to a static inventory

Sonatype identified more than 454,600 new malicious packages in 2025 alone, pushing the cumulative total past 1.2 million. Sit with that for a second. An SBOM generated on day one of a project gets measured, months later, against a threat landscape that added hundreds of thousands of newly malicious packages while that document sat untouched in a repository.

Over 70 percent of organizations reported at least one incident tied to third-party software, and the global cost of these attacks reached an estimated $60 billion, on a trajectory toward $138 billion by 2031. These aren't projections about some distant risk category. They describe attacks happening now, against software that, in many cases, shipped with a perfectly clean SBOM on file the day it went out the door.

The OpenAI incident is the clearest illustration available. A vulnerability that originated in the Redis library temporarily forced OpenAI to suspend ChatGPT and exposed user data. A transitive dependency, not code anyone at OpenAI wrote directly, produced a real production incident. Transitive dependencies are exactly where a large share of real-world supply chain vulnerabilities hide, and direct dependency scanning simply doesn't see them. An SBOM that isn't tracking transitive dependencies continuously has a blind spot built into its foundation, not bolted onto it as an afterthought.

New CVEs get published against existing, previously deployed components constantly, not just against brand-new packages. A component clean at generation time can become exploitable by that afternoon. The gap between an SBOM's generation date and today measures exactly how far the software has drifted from what the document claims. That's an open window, and it stays open for as long as the snapshot goes unrefreshed.

What regulators now require that snapshot programs cannot satisfy

CISA's 2026 update to the Minimum Elements for an SBOM, replacing the 2021 NTIA baseline, wasn't a quiet tweak. It came out of work with the NSA, the FBI, and international partners, following more than 90 public comments, and it took years to land.

The new required minimum fields include the component's hash algorithm, its license, the name of the SBOM generation tool, and the generation context. "Supplier Name" is now "Component Producer," a small rename with a clear intent behind it: precision. The hash requirement matters most here, because it directly closes the substitution gap described above. For the first time, organizations have a standardized way to verify that what's documented on paper matches what's actually running in production.

Scope expanded too. The minimum elements now apply to all software types, including open-source software, AI software, and software-as-a-service, a real departure from 2021, when neither AI nor SaaS delivery was the industry default. Meanwhile the EU's Cyber Resilience Act adds its own timeline: vulnerability and incident reporting obligations start September 11, 2026, with broader product security obligations following on December 11, 2027.

In one jurisdiction, a federal budget office memorandum issued in January 2026 rescinded earlier mandatory self-attestation memoranda in favor of an agency-led, risk-based approach, though a prior executive directive itself stays in effect. Federal posture is shifting toward agencies making their own risk calls rather than following one blanket mandate, which makes a well-built minimum-elements baseline more important, not less: agencies now need a floor they can trust without a single top-down attestation process to lean on.

CISA is explicit that these elements are a floor, not a ceiling. AI systems and cloud-based SaaS will need more on top of the baseline, full stop. And as one commentary on the guidance put it: generating an SBOM isn't enough, organizations need continuous validation to keep the component information accurate over time. Snapshot programs fail this test by design, and no amount of craftsmanship on day one changes that. A document generated once and filed away cannot satisfy a "continuous validation" requirement no matter how well it was built. As SBOM obligations get pulled deeper into frameworks like CMMC and FedRAMP, the space between a filed snapshot and a living inventory becomes the actual point of failure auditors will find.

The five criteria that separate a useful SBOM from a checkbox artifact

An SBOM that satisfies a compliance checkbox and an SBOM that actually reduces risk are not automatically the same document. Five criteria separate them, and most generation approaches quietly fail two or three of the five without anyone flagging it until an audit does.

Completeness comes first: every component, across every layer and package type, needs to show up. OS packages from the base image, application dependencies pulled from every package manager in use, and tooling added mid-build all count. Multi-stage and minimal base images make this genuinely hard. A Dockerfile with a Node frontend, a statically linked C or C++ component, and a distroless final stage presents three separate detection problems, and post-build scanners routinely miss at least one of them.

Accuracy means recording resolved versions, not declared ranges, the 4.17.21-versus-^4.17.0 problem from earlier, applied consistently across the whole dependency tree. Freshness follows from a simple architectural fact laid out in guidance from container tooling vendors: an SBOM is tied to one specific build. Every rebuild needs a fresh SBOM, because a stale one creates exactly the false sense of visibility this whole piece is arguing against.

Verifiability is where cryptographic signing and attestation come in. Frameworks like in-toto and SLSA bind an SBOM to a specific artifact digest and record where and how that artifact was built. A verifiable SBOM is one a consumer, whether that's a security team or an auditor, can confirm was actually produced by the build system and hasn't been tampered with afterward.

Format compliance rounds it out. SPDX and CycloneDX define required and optional fields, and an SBOM that validates cleanly against those schemas stays interoperable across scanning tools, policy engines, and compliance pipelines. One that doesn't might work fine with today's tools and then quietly break the moment tooling changes.

Omdia's 2026 software supply chain security report found that 86 percent of organizations describe SBOM generation as challenging. That number makes sense against these five criteria, and it exposes where the actual liability sits: not in the fields a tool gets right, but in the two or three it skips without anyone noticing.

How build-time pipeline integration produces continuous generation rather than periodic snapshots

The fix is architectural. SBOM generation has to move from a post-release export step into a native pipeline stage that fires on every build, not once at the end of a release cycle.

Three integration points do the real work. At build time, SBOM generation and initial CVE scanning run automatically on every build, and because the generator is present while the artifact is actually being assembled, it has access to the resolved dependency tree, the package manager files, and the full build context, information a scanner working from the outside never sees. Dependency change detection compares each development stage against the one before it, catching dependency injection in near real time, which meaningfully cuts the window an attacker has to exploit a malicious swap before anyone notices. And continuous CVE cross-referencing runs on an ongoing basis rather than only at generation, so a CVE published against a component already in production surfaces as soon as it's published, not whenever the next scheduled scan happens to run.

Build-time generation beats post-build scanning for one plain reason: the generator was there. It watched the artifact get assembled, so it captures the resolved state of every dependency, transitive ones included, in a way a post-build heuristic scanner working from the finished artifact alone often cannot. Post-build scanning still earns its place for third-party images a team consumes but never builds, or for legacy artifacts with no build-system integration to hook into. But for anything a team actually builds itself, treating post-build scanning as the primary method is a mistake dressed up as a shortcut, and it's the mistake most teams still default to because it's easier to bolt on than to redesign around.

Provenance enrichment happens at generation time too. SBOM entries get tagged with repository URLs, commit SHAs, in-toto attestations, and SLSA provenance, which makes it possible to trace a binary all the way back to its source. Container build systems with native attestation support can produce an SPDX SBOM during the image build itself, attach it as an in-toto attestation, and push the image and the SBOM to the registry together, in one operation.

Decoupling SBOM generation from vulnerability scanning matters here. Generating the SBOM early lets a team cross-reference components against vulnerability databases continuously, catching risk before it ever reaches production, rather than waiting for a scan cycle to catch up. Once generation is wired into the pipeline natively, something else falls out almost for free: a historical record of how the application evolved, stage by stage, each one comparable to the last. Drift stops being invisible.

One coupling worth flagging directly: the environment that produces the build determines what the SBOM can actually capture. If a developer's local environment differs from CI, the SBOM produced in CI may not represent what that developer was really running on their own machine. Environment consistency and SBOM accuracy aren't two separate problems. They're the same problem wearing two names.

Tool choices for teams moving to continuous generation

Omdia's 2026 research flags a tool-sprawl problem that's easy to recognize: teams stitch together different scanners for different artifact types, get inconsistent output across pipelines, and end up spending engineering time reconciling conflicting results instead of acting on any of them.

Open standards are the anchor that keeps this from spiraling. CycloneDX and SPDX for the SBOM itself, in-toto and SLSA for provenance, OSV for vulnerability data, VEX for exploitability context, all chosen specifically to avoid vendor lock-in and to make it possible to hand evidence to customers and regulators without a translation layer sitting in between.

Within that standard-format world, there's a real choice between specialist and generalist tools, and the specialist should win in most cases where accuracy actually matters. A single-language tool built for one ecosystem, an npm-focused SBOM generator, say, tends to produce meaningfully higher accuracy for that specific ecosystem than a generalist tool trying to cover five package managers at once. Multi-language tools trade that precision for broader coverage across polyglot builds, and that trade-off only makes sense once a team has already accepted lower fidelity in exchange for not maintaining five separate tools, which is a narrower case than most teams assume. What matters more than either choice is picking one approach and running it consistently, in local development and in CI, rather than switching mid-stream and losing comparability across builds.

Ecosystem-native generation is starting to close this gap on its own. The Yocto Project's OpenEmbedded build system now ships native SBOM generation, a real blueprint for building SBOM creation directly into a developer's toolchain rather than bolting it on afterward. Through 2025, several major software ecosystems began treating SBOMs as first-class citizens inside their own build tools: the Python and Perl ecosystems have started exploring build-native SBOM support, and the Java ecosystem, through projects tied to the Eclipse Foundation and Spring Boot, is already piloting integrations along the same lines.

Whatever tool a team lands on, using the same one in CI as in local development is non-negotiable. That parity closes the gap between what a developer sees locally and what the pipeline produces, and it's the difference between an SBOM that's accurate end to end and one that's only accurate in CI. Reproducible, declarative development environments do a lot of this work before a single SBOM flag gets set: if the environment building the software resolves to the same state every time, down to exact package versions and hashes across every architecture and OS in play, the SBOM it produces inherits that consistency for free. Drift in the build environment shows up as drift in the SBOM even when the application's own code hasn't changed a line.

VEX documents deserve mention as a companion, not a substitute. Cross-referencing an SBOM against VEX statements, CISA's Known Exploited Vulnerabilities catalog, and EPSS scores turns a raw CVE list, sorted by CVSS score and full of noise, into something a security team can actually act on in priority order.

AI and SaaS components: where continuous generation programs are not yet reaching

CISA's 2026 scope expansion names AI software and SaaS explicitly, a real shift from 2021, when neither one was the default way software got delivered. Naming them in the standard is the easy part. Actually generating SBOMs for them is where most continuous generation programs currently stop short, and pretending otherwise is the second failure mode this piece has to call out plainly.

Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at Futurum Group, frames the SaaS problem in one line: "Extending the baseline to AI and SaaS moves the work from your build pipeline to your vendor contracts. You cannot hash a binary you never compile. The SBOM has to arrive with the service." That's not a minor caveat. It's disqualifying for the entire build-time integration model described above. Generation as a pipeline stage has no pipeline to attach to when the software in question is a vendor's SaaS product, running on infrastructure the consuming team never touches.

AI models introduce a separate mess. Plenty of them ship in formats, pickle being the most common example, that allow remote code execution the moment the model loads, and traditional scanners have no way to inspect what's actually inside. That's driving interest in something like an ML-BOM: documentation of training data, architecture decisions, and safety benchmarks, a distinct artifact class that standard SBOM tooling was never designed to produce. A model or a dataset can also get updated without triggering any build event at all, so programs keyed strictly to release events miss those changes entirely, no exceptions. Ashley's point about vendor contracts applies here just as directly as it does to SaaS.

There's a newer wrinkle too: governing Model Context Protocol servers, the pieces that let AI agents reach into organizational data, is now recognized as its own distinct supply chain concern, and Sonatype has already identified malicious packages specifically targeting the ML ecosystem. CISA and G7 partners released companion guidance for AI systems in 2026, built explicitly as a supplement to the general SBOM minimum elements rather than a replacement for them.

Continuous generation programs need to extend SBOMs, signed artifacts, and provenance verification into AI and ML pipelines with the same rigor applied to conventional software, even where the fix isn't straightforward. SBOM delivery needs to get written into vendor contracts and renewal terms for every component a team consumes but never compiles itself, because asking nicely after the fact doesn't work, and most vendors won't volunteer it until the contract requires it.

What teams need to change organizationally, not just technically

A lot of teams conflate generation with analysis, and that conflation is the whole organizational failure in miniature. Producing the SBOM is not the finish line, whatever the compliance checklist implies. A document generated once and filed for an audit functions merely as a compliance record, not as a security tool.

Mature programs treat generation and analysis as two distinct, ongoing functions rather than one event that happens at release. Generation needs to be automatic, continuous, and invisible to the engineers doing the actual build work, wired into the pipeline the way tests and linting already are. Analysis needs a team, or at minimum a clear owner, whose job is to actually look at what the SBOM says, cross-reference it against new CVEs and VEX data as they publish, and act on findings before they age into an incident.

That ownership question is where most organizations are still stuck, and it's the part worth fixing first, ahead of any tooling decision. Security teams often own the compliance requirement to produce an SBOM, but engineering owns the pipeline where generation actually needs to live, and nobody owns the ongoing analysis sitting in between the two. Closing that gap means treating the SBOM the way a team already treats test coverage or deployment health: a living metric somebody checks on a schedule, not a document filed once and rediscovered at the next audit.