Every SBOM answers the same question: what's in this software? The problem is when it answers it. A static SBOM captures a single build at a single moment, and by the time it lands in a compliance folder, the underlying application has already shipped a new dependency, swapped a base image, or fine-tuned a model on fresh data. Snyk — whose Snyk Open Source product has generated a standard Snyk SBOM from dependency manifests for years — takes a different approach with AI-BOM: instead of generating a document on demand and filing it away, it treats the bill of materials as a living artifact that updates as the AI system's components change. That distinction — snapshot versus continuously refreshed inventory — matters more for AI systems than for traditional software, because models, datasets, and adapters change shape far more often than a package.json or requirements.txt file does. This post walks through how the two approaches actually differ mechanically, without treating either as a finished product to be crowned "better."
What is a static SBOM snapshot, and why does it go stale?
A static SBOM snapshot is a bill of materials generated once, at a specific point in the build or release pipeline, and then stored as a fixed record. Tools like Syft, CycloneDX generators, or SPDX exporters typically run at build time, scan the resulting artifact (a container image, a binary, a package), and emit a JSON or XML file listing every component, version, and license they found. That file is accurate for exactly one thing: the artifact as it existed at that build timestamp.
The staleness problem shows up almost immediately after export. A component gets patched upstream two days later, a transitive dependency is swapped during a routine npm audit fix, or a new CVE is disclosed against a library version that was "clean" when the SBOM was generated. None of that is reflected in the stored document. NTIA's 2021 minimum elements guidance for SBOMs never mandated a refresh cadence — it left "when to regenerate" as an open question, which is why most static-SBOM programs regenerate on release cut, not continuously. For a monolithic application released quarterly, that gap is tolerable. For an AI pipeline where a model can be re-fine-tuned, a dataset re-pulled, or a LoRA adapter swapped in a single sprint, a quarterly or even per-release snapshot can be weeks out of date before anyone notices.
How does an AI-BOM differ from a traditional software SBOM?
An AI-BOM extends the same bill-of-materials concept behind a standard Snyk SBOM to the components that make up an AI system, not just its code dependencies. Where a traditional SBOM enumerates packages, libraries, and their versions, an AI-BOM additionally tracks model architectures, model weights and their provenance, training and fine-tuning datasets, embeddings, adapters (like LoRA layers), and the inference frameworks that serve them. This isn't a Snyk-specific idea — CycloneDX 1.6, published by OWASP in 2024, formally added ML-BOM support, including component types for machine-learning-model and data alongside fields for model cards, quantitative analysis, and considerations like fairness or safety risks.
The practical reason this extension matters is that AI components don't behave like pinned library versions. A dataset referenced by a model isn't a static tarball with a checksum that never changes — many datasets are living collections that get re-scraped, deduplicated, or filtered on an ongoing basis. A model registry entry can point to the "latest" checkpoint rather than an immutable hash. Snyk's AI-BOM inherits the CycloneDX ML-BOM schema to represent these entities, but the more consequential design choice is what happens after the document is generated — whether it's treated as a one-time export or as a record that gets kept in sync with the environment it describes.
What does "continuous refresh" actually mean in Snyk's AI-BOM model?
Continuous refresh means the AI-BOM is regenerated automatically as the underlying repository, pipeline, or model registry changes, rather than only when someone manually triggers a scan. Snyk has built AI-BOM as a capability on top of its existing platform, which already performs ongoing monitoring of connected source repositories and registries for Snyk Open Source and Snyk Code — the same monitoring infrastructure that flags new CVEs against previously-scanned dependencies without a full re-scan being manually requested. Applying that model to AI components means the inventory of models, datasets, and frameworks discovered in a codebase is kept current as commits land, rather than being frozen at the last export.
The distinction is closer to a live inventory than a static "point-in-time" document. Instead of asking "generate me the AI-BOM," the workflow is closer to "maintain an AI-BOM," where changes — a new model reference committed to a config file, a dataset path updated in a training script, a new package pulled into an inference service — get picked up as part of Snyk's normal repository monitoring rather than requiring a separate BOM-generation step to be re-run. Snyk has publicly described this as answering "what AI is in my organization right now" as opposed to "what AI was in this build."
Why does refresh cadence matter more for AI components than for typical software packages?
Refresh cadence matters more for AI components because model and dataset references change through paths that traditional dependency management doesn't cover, so a snapshot approach systematically misses more of them. A pinned npm or Maven dependency changes only when someone edits a manifest file and re-runs a build — an event that's easy to hook a scanner into. Model and dataset references, by contrast, often live in application code, notebook cells, YAML configs, or environment variables, and they frequently point to mutable identifiers (a Hugging Face repo tag, an S3 prefix, a registry "latest" alias) rather than a content-addressed version. A single-point scan can capture the identifier that was in place at scan time and miss that the artifact behind that identifier was swapped a week later without any corresponding commit to the application's own repository.
This is also where the volume problem compounds the staleness problem. Teams experimenting with AI features tend to add and drop model dependencies faster than they add and drop traditional libraries, because trying a different embedding model or a different foundation model API is often a one-line change. A BOM process that only runs at release time can undercount the number of AI components an organization is actually using by a wide margin, simply because most of the churn happens between releases, not at them.
What are the practical risks of relying on a point-in-time snapshot for AI systems?
The practical risk is a widening gap between the compliance record and the deployed reality, which shows up first during incident response and audits. When a new vulnerability is disclosed against a model architecture, a serialization format (like the well-documented pickle deserialization risks in some model file formats), or a popular dataset, a security team's first question is "where are we exposed?" If the answer comes from a quarterly SBOM export, the team is checking a document that may already be inaccurate about which models are in production, which is functionally the same problem static SBOMs have always had with traditional dependencies — except the AI component churn rate makes the blind spot bigger.
Audit and compliance workflows suffer a related failure mode: a static snapshot can pass an audit checklist ("do you maintain an SBOM? yes") while telling reviewers almost nothing about the system as it exists on the audit date. Frameworks referencing SBOM practices, including guidance stemming from Executive Order 14028 (2021) and evolving NIST guidance on AI risk management (the AI RMF, published 2023, and its generative AI profile released in 2024), increasingly expect organizations to demonstrate current-state visibility, not archived paperwork.
How Safeguard Helps
Safeguard's role is to make sure that whichever BOM approach a team uses — static, continuously refreshed, or something in between — the data feeding it is accurate and the gaps are visible rather than hidden. Safeguard ingests SBOM and AI-BOM outputs from tools across the pipeline, normalizes them against CycloneDX and SPDX schemas, and cross-references component and model inventories against live vulnerability and provenance data so that a component's risk status doesn't quietly go stale between generation events. For AI-specific components, Safeguard tracks model and dataset provenance signals alongside traditional dependency data, giving security and compliance teams one place to see when a BOM record — regardless of which vendor produced it — no longer reflects what's actually running in production. That closes the exact gap this post describes: the difference between having a document that says what was true once, and having visibility into what's true now.