SBOM and Provenance Tracking for AI-Generated Code Dependencies

AI agents now write dependencies into codebases faster than any human review cycle can track. The Cloudsmith 2025 Artifact Management Report found that 42% of developers using AI tools say at least half their codebase is now AI-generated, and Veracode's 2025 GenAI Code Security Report put a number on the quality gap: AI-generated code carries 2.74 times more vulnerabilities than code written by hand, with 45% of sampled outputs introducing an OWASP Top 10 flaw somewhere in the mix. Those numbers describe a code quality problem. The dependency problem sitting underneath it is worse, because it's structural rather than statistical.

An agent doesn't just write flawed logic. It reaches into a package ecosystem and pulls in whatever name it thinks solves the problem in front of it, whether or not that package exists, whether or not it's safe, and whether or not anyone signed off on it. One study of agent behavior found that 45.0% of agent-driven edits introduced an entirely new direct dependency. That's a decision made under pressure, not a developer weighing a library tradeoff over coffee. That's an autonomous process rewriting the dependency graph in the gap between one human review and the next.

The scale of the hallucination problem is now measured, not hypothetical. A USENIX Security 2025 study scanned 576,000 code samples across 16 different LLMs and found that 19.7% of generated packages didn't exist at all, producing 205,474 unique fictional package names. The Python Software Foundation's Seth Larson gave this failure mode a name in April 2025: slopsquatting, the practice of registering a package name an LLM is likely to hallucinate and waiting for someone's build to pull it down. A later re-evaluation across five frontier models found hallucination rates settling between 4.62% and 6.10%, still nontrivial at any production scale. Of 199,845 prompts tested, 127 package names were hallucinated identically across all five models, meaning an attacker doesn't need to guess what a single model might invent, just what several models agree on. As of April 2026, 53 of those 127 names remained available to register. That's a demonstrated attack surface, not a theoretical one. That's an open door with a sign on it.

Underneath all of this sits a provenance vacuum that most security programs haven't priced in yet. A model doesn't cite where its training data came from. It doesn't disclose which existing codebase a given function was lifted from. It leaves no audit trail connecting its output to a source. Software supply chain security guidance broadly calls for traceability back to origin, and AI-generated code, by its nature, makes that traceability nearly impossible to reconstruct after the fact. The question worth asking isn't whether AI is writing dependencies into production systems. It already is. Whether the tooling around it knows the moment that happens is what matters.

What SBOMs were designed to do and where that design breaks under agentic workflows

A software bill of materials is a structured inventory of everything a piece of software is built from: its libraries, its dependencies, where each of those came from. It exists to support four things at once: finding vulnerabilities, giving supply chain transparency, meeting compliance obligations, and speeding up incident response when something goes wrong. License governance rides along as a fifth.

The design assumes something about how software gets built that no longer holds. It assumes a human makes a dependency decision at a specific, deliberate moment, that someone typed npm install and knew why. An SBOM captures that decision as a snapshot, and the snapshot stays accurate until the next deliberate change happens. That model worked fine when dependency changes were rare enough to track by hand.

Agents break the model because they don't wait for a review cycle. An analysis by augmentcode.com of build workflows lays out the failure: when an agent merges a new package into a project on a Tuesday, the SBOM generated the previous Monday describes software that no longer exists. Nobody lied. Nobody skipped a step. The tooling just wasn't built for a world where the dependency graph moves between manual exports instead of at them.

Regulators are catching up to the problem faster than most engineering teams have. CISA's 2026 SBOM minimum elements baseline, finalized from a 2025 draft, names "Automation Support" as a required element, not a nice-to-have. NIST SP 800-161r1 recommends that enterprises produce SBOMs for applicable and appropriate classes of software, open-source components included. The direction of travel is unambiguous: continuous, queryable evidence instead of a document generated once a quarter and filed away.

Visibility alone doesn't close the gap, though. Sonatype's research found that 80% of dependencies go more than a year without an upgrade, even in cases where 95% of the vulnerable versions in question have a safer replacement sitting right there. Knowing what's in your codebase and doing something about it are two different muscles, and an SBOM only exercises the first one. Emerging regulatory and certification frameworks are pushing organizations toward systems that stay current automatically, because a static inventory just becomes a longer and longer backlog nobody clears.

Here's the distinction that matters most: an SBOM tells you what exists. It does not tell you which of those components is actually reachable, actually loaded, and actually exploitable once the software is running. Presence in an inventory and presence in an attack path are not the same fact, and conflating them is how security teams end up chasing thousands of line items that were never going to matter. What decides that difference is execution lineage: whether a dependency gets called at runtime, not whether it sits quietly in a manifest file.

Build-time SBOM generation as the architectural response to agent-introduced dependencies

The fix is an automated process. It's removing the manual step entirely. Generate the SBOM from the lock file on every build that produces an artifact, every single time, so the inventory is tied to the exact software the pipeline assembled rather than to whatever a developer remembered to document. Per augmentcode.com's framing, this is the only approach that reliably catches a dependency an agent introduced without telling anyone.

A study of 2,414 open-source repositories found a detail worth sitting with: scanning a requirements.txt file with Trivy or Syft only resolves direct dependencies, missing the transitive ones entirely. Lock files fix that, because they record the full resolved tree. In practice, enforce npm ci instead of npm install in CI, commit the output of pip-compile rather than a loose requirements file, and generate SBOMs during the build step itself for compiled languages, not after the fact from source.

A pipeline built around this looks something like the following. Right after checkout and before the build starts, run a language-native tool like cdxgen or a general scanner like Syft against the source and manifest files, outputting SPDX or CycloneDX format. After the build finishes and before anything gets pushed, scan the resulting container image with Syft or a SHA-pinned version of Trivy. On a tag or release event, attach the generated SBOM to the release assets so downstream consumers can pull it without asking. On GitHub specifically, an SBOM action can run Syft, upload the result as a workflow artifact, and attach it to the release automatically, provided every action in the chain is pinned to a commit SHA rather than a mutable tag like @v1.

That last point isn't optional hygiene. On March 19, 2026, attackers compromised the aquasecurity/trivy-action, a widely used component in exactly this kind of pipeline. Teams that pinned to a specific commit hash rather than a floating tag weren't exposed to the compromised update. Teams that hadn't were. On GitLab, native dependency scanning consumes CycloneDX artifacts and checks them against the GitLab Advisory Database without extra plumbing.

Tool choice matters more than it looks like it should. A large-scale empirical analysis evaluated major SBOM generation tools and found them hitting full compliance on mandatory field presence while falling well short on semantic completeness, meaning the SBOMs were technically valid and still missing information a security team would actually need. Syft, at version 1.46.0, scans lock files, image layers, and binaries, and it's listed by CISA as a reference tool, but the benchmark clocked it at 11.47% precision and 13.89% recall, strong on breadth and weak on depth. The gap shows up concretely: scanning the same Juice Shop container image, Dependency-Track found 35 vulnerabilities in an SBOM generated by Trivy versus 88 in one generated by Syft. The difference traces back to how completely each tool populates the component metadata that vulnerability databases need to make a match. Skip key fields and matches silently disappear.

In practice, pair tools rather than pick one: a build-system-native generator alongside a container scanner, since each one reads a different layer of evidence and neither substitutes for the other.

Generation is only the start, though. An open-source tool built natively around CycloneDX consumes both SBOMs and VEX documents, continuously re-checking every component against multiple vulnerability databases and advisory data sources, with EPSS scoring layered on top to help prioritize what actually needs attention first. That continuous re-analysis is what keeps an SBOM from going stale the moment it's generated. GUAC, an OpenSSF project, goes a step further and aggregates SBOMs, SLSA and in-toto attestations, vulnerability data, and Scorecard results into a single queryable graph, treating provenance as a data structure you can ask questions of rather than a PDF you file away.

One underused feature deserves more attention than it gets: the CycloneDX CLI's diff subcommand can compare two SBOMs and report exactly which components were added, removed, or changed, in either text or JSON. That diff is a governance mechanism in its own right. When an agent slips a new package into the build on a Tuesday, the diff between Monday's SBOM and Tuesday's turns that silent change into a reviewable event with a name and a version number attached. Tag every SBOM with its commit hash, build number, and deployment target, at minimum, because that's the floor for reconstructing what happened later.

Cryptographic attestation and SLSA provenance as the enforcement layer above generation

An SBOM, even a freshly generated one, proves nothing about where it came from unless something ties it cryptographically to the artifact it describes. An unsigned SBOM is a claim. A signed attestation is evidence.

Sigstore's keyless signing flow, run inside GitHub Actions with id-token: write permission set, issues a short-lived certificate from Fulcio and records the signing event in Rekor, a transparency log that's public and append-only. Nobody can quietly rewrite history in a log built that way; any tampering after the fact is detectable by design. GitHub's own attest action builds on this, generating SLSA-compliant provenance with very little configuration required, storing the result alongside the artifact where any downstream consumer, including an automated deployment gate, can verify it independently.

The SLSA framework itself has matured past the experimental stage. Version 1.1 is a stable release, and version 1.2 is in active development. The Build Track is solid and ready for production use; the Source Track specifications are still being worked out. GitHub's attest action supports both SPDX and CycloneDX predicates and meets SLSA v1.0 Build Level 2 with no extra work, climbing to Build Level 3 once reusable workflows are added to the pipeline.

None of this comes free. The sources are candid about the scaling costs: large volumes of in-toto and SLSA metadata pile up fast, keys need rotating, verification has to happen across multiple disconnected systems, and artifacts often live far longer than the infrastructure that first attested to them. Teams adopting this need to budget for storage and verification infrastructure as a real line item, not an afterthought bolted onto the generation step.

There's a gap worth naming directly. A compiled JAR, a Docker image, and a Python wheel are none of these the source code. Each is a transformation of it, and risk can slip in during compilation, linking, or packaging that never existed in the source tree at all. Binary lifecycle management treats these transformed artifacts as tracked, governed things in their own right, for their entire useful life, and SLSA provenance is the mechanism that connects a binary back to the source it came from, closing a gap that source-level scanning alone can't see.

CI/CD systems should emit structured metadata at every pipeline stage, using SLSA provenance format or in-toto layouts, with attestations carrying timestamps, the identity of whatever executed the step, and cryptographic hashes of the inputs and outputs. That's an ongoing operational requirement, not a compliance checkbox to satisfy an auditor once a year. It's the forensic record an incident response team reaches for when something breaks in production and nobody can explain why. And on the enforcement side, a tool like Grype can run directly against a generated SBOM, failing the build on any high-severity finding, but the gate should trigger on newly introduced critical vulnerabilities rather than the total accumulated backlog. Gating on the backlog produces alert fatigue and nothing else. Gating on the delta produces an actual decision someone has to make.

Why detecting copied and inlined third-party code in AI output requires a separate SCA layer

Every mechanism described so far assumes a dependency shows up somewhere, whether in a manifest, a lock file, or an import statement. AI models break that assumption in a way that exceeds what package managers were built to catch. A developer who installs a named package leaves a trace in the lock file. A model that inlines a function copied wholesale from a third-party library leaves nothing: no dependency declaration, no version pin, no license record, no SBOM entry. The code is there. The paper trail isn't.

Endor Labs holds a patent addressing exactly this, US 12,430,446 B1, granted September 30, 2025, covering a software composition analysis system built to catch AI-generated code that contains blocks lifted from third-party libraries. The method works by parsing code files with language-specific parsers into function definition blocks, license header blocks, and everything else, then generating a cryptographic hash, a block signature, for each one. That signature gets checked against an index built from ranked third-party libraries, where the ranking itself comes from dependency graph analysis run through a PageRank-style algorithm that weighs which libraries the wider ecosystem actually depends on most.

A match triggers three things at once. It identifies the source file the code came from, pulls any known vulnerabilities and available fixes tied to that source, and checks for license incompatibilities. Because exact hash matching misses code that's been lightly edited or adapted, the system also runs machine learning embedding models to catch near-copies that survive small changes to variable names or formatting.

What this adds to the picture is a second axis of provenance that goes beyond what an SBOM was built to cover. The SBOM tracks declared dependencies, the things a package manager knows about. Block-signature matching tracks undeclared code, the things nobody declared because nobody, human or model, told the system they were there. Together the two approaches cover both the package graph and the actual code sitting inside it.

License exposure compounds the security exposure here, and it's often the sharper of the two risks. Inlined code carries whatever license it originally shipped under, regardless of whether the developer who accepted the AI's suggestion had any idea the code came from somewhere else. AGPL or GPL code, quietly inlined into a proprietary codebase by a model that has no concept of license compatibility, creates a legal exposure that no SBOM, however well-maintained, would ever surface. This is the evidence layer that makes an AI-aware SBOM actually mean something. Without it, the SBOM describes the dependencies everyone agreed to use, while a real and possibly significant share of the codebase's true origin goes completely unrecorded.

Extending the SBOM schema to capture what AI agents actually do at runtime

A conventional SBOM has a ceiling, and it's a low one for agentic workflows. Per Radanliev et al., researchers spanning the University of Oxford, the Alan Turing Institute, Cisco Systems, and the University of Hull, standard SBOMs give a static snapshot of dependencies but can't capture runtime behavior, drift in the environment after deployment, or the context needed to judge whether a given flaw is actually exploitable. Their preprint introduces the agentic AIBOM as a response to that ceiling.

An AIBOM, broadly, extends the traditional SBOM concept to document the AI models themselves. It covers the training data behind them, the code generation tools involved, and the provenance of whatever those tools produced. It's a distinct artifact from the code-level SBOM, describing the system that generated the code rather than the code alone. CycloneDX 1.6 already ships with ratified ML-BOM fields covering training data and architecture decisions. The standard exists. Adoption is the part still catching up.

The Radanliev et al. framework, described in arxiv preprint 2603.10057, builds this out through three cooperating agents. A baseline environment reconstruction agent, using a standardized context-sharing protocol, captures the execution environment exactly as it existed at the moment code ran. A runtime dependency and drift-monitoring agent, using inter-agent communication, tracks dependency changes as they happen during execution rather than only at build time. A third agent, policy-aware and built for exploitability reasoning, using a multi-agent coordination framework, pulls together runtime evidence, how a dependency actually gets used, and whatever mitigations exist in the environment, to produce contextual exploitability assertions using a standardized exploitability-exchange data format. Exploitability comes out as a structured VEX assertion rather than a flat block-or-allow decision, because whether something is actually exploitable depends heavily on the environment it's running in, and VEX is built to hold that nuance instead of flattening it away.

The schema changes needed to support this are additions to CycloneDX and SPDX, not replacements. They capture execution context, how dependencies evolved over the life of a build, and the decisions an agent made along the way, designed to interoperate with tooling that already exists rather than forcing a wholesale migration.

MCP servers deserve a mention here as their own new class of dependency. Heading into 2026, supply chain security increasingly calls for a single governing source of truth that covers open-source libraries, AI model weights, and MCP servers together, as one connected surface rather than three separate ones. A prompt fed into a coding agent is now a real input to the build process, which makes it a real point of attack, not a curiosity.

Discussions at the S3C2 Summit in September 2025 pointed in a similar direction: extending SLSA and GUAC concepts to track how AI models themselves get built and used, recording training data sources, keeping hashes of model weights, and capturing provenance at inference time, treating models, datasets, fine-tuning pipelines, and agent decisions as supply chain artifacts in their own right, subject to the same scrutiny as a compiled binary. Radanliev et al.'s own ablation studies found the agentic AIBOM framework improved runtime dependency capture, reproducibility, and the stability of vulnerability interpretation compared to existing provenance systems, with low additional computational overhead, an early but meaningful signal that this direction is workable at production scale and not just on paper.

Why reproducible build environments are the prerequisite that makes provenance trustworthy

None of the mechanisms above mean much if the build itself can't be reproduced. A provenance attestation is a claim that a specific set of inputs, run through a specific process, produced a specific artifact. If that same build, run again under the same conditions, produces a different result, the attestation is describing a process nobody can actually verify.

That's the quiet dependency sitting underneath every SLSA claim and every signed SBOM discussed so far: the build environment itself has to be pinned down as tightly as the dependency graph is. A pipeline that resolves package versions dynamically, pulls from a floating base image, or lets a compiler version drift between runs can generate a technically valid attestation for a build that nobody could reproduce next week if they needed to check it. The attestation would be signed, timestamped, and logged in Rekor, and it would still be describing a process that isn't stable enough to trust.

Reproducibility is what turns provenance from a paper trail into something a downstream consumer can actually rely on. If two independent builds from the same source, same lock file, and same environment specification support reproducible output, then the attestation attached to that output is verifiable by anyone willing to run the build again and check. If they don't produce identical output, the entire chain of signed claims built on top of that step rests on an assumption nobody can test. Agentic workflows make this harder before they make it easier, because an agent editing a build script or a dependency spec introduces exactly the kind of environmental drift that breaks reproducibility. Locking the environment down first is what makes every layer described above worth trusting.