Your SBOM covers roughly 0% of the logic an LLM wrote into your codebase last sprint. That gap is not a tooling limitation you can patch around. It is a structural blind spot that your current compliance posture treats as if it does not exist.
Last quarter, a principal engineer at a Series C fintech walked into an SOC 2 Type II audit with what she believed was a complete software bill of materials. The auditors asked about provenance for a payments reconciliation module. She could show them every declared dependency, every pinned version, every CVE scan result. What she could not show them was where the core reconciliation logic itself came from, because a developer had scaffolded it with GitHub Copilot in an afternoon and nobody had recorded that fact anywhere. The auditors noted the gap. The finding did not kill the audit, but it opened a conversation that took three months and two rounds of remediation to close. That conversation is coming for most engineering organizations. Most of them are not ready.
What a SBOM Actually Tracks, and What It Misses
A software bill of materials is an inventory of ingredients. The dominant formats, SPDX and CycloneDX, are designed around the idea that software is composed of discrete, named, versioned components with known authors and license terms. Tools like syft, cdxgen, and trivy generate SBOMs by scanning package manifests, lock files, and container layers. That model works well when your code is assembled from packages that live in npm, PyPI, Maven, or similar registries.
AI-generated code does not live in any registry. It has no package name, no version, no SPDX identifier, and no CVE entry. When a developer asks Claude or GPT-4o to write a JWT validation routine and pastes the output into the codebase, that logic is invisible to every SBOM tool on the market. syft will not find it. trivy will not flag it. Your dependency graph will not show it. From a compliance artifact perspective, that code might as well have materialized from nothing.
The distinction matters because SBOM tools are architecturally blind to this class of content, not just operationally unaware of it. They were not designed to track origin claims for arbitrary logic, only for declared components. Expecting them to solve the AI provenance problem is like expecting a cargo manifest to tell you whether the goods inside were built ethically.
The Three Provenance Properties AI Code Cannot Satisfy
Traditional supply-chain compliance rests on three properties for any piece of code in a production system: attribution (who wrote it), integrity (that it has not been tampered with), and license clarity (what terms govern its use). AI-generated code fails all three in ways that are not obvious until an auditor or acquirer asks directly.
Attribution is the first casualty. A commit from a developer does not tell you whether that developer wrote the function or prompted an LLM for it. Git blame names the committer, not the author in any meaningful sense. Some teams are starting to add commit conventions or PR labels, but these are voluntary and inconsistent. There is no standard metadata field in any major VCS for recording AI involvement, and no enforcement mechanism even if there were.
Integrity breaks differently. With an open-source dependency, you can pin a hash, verify the artifact against a known registry, and reproduce the build. With AI-generated code, the generation event is typically not recorded. You cannot replay it. You cannot prove that the function a developer committed matches what the model actually produced, because nobody captured the prompt, the model version, the temperature setting, or the sampled output at generation time. The code exists. Its origin does not.
License clarity is arguably the most legally fraught. LLMs are trained on code with a range of licenses, some of which have attribution or copyleft requirements. Whether any specific model output constitutes a derivative work under copyright law is an unsettled question, but it is a question that acquirers, enterprise buyers, and regulators are beginning to ask. If you cannot say which parts of your codebase were AI-generated, you cannot credibly assess your exposure.
This is not a theoretical risk. M&A due diligence checklists at several major acquirers now explicitly ask about AI code generation practices and whether generated code has been reviewed and attested. The question moved from legal curiosity to deal-table line item faster than most engineering leaders expected.
Why Your Current Controls Do Not Close the Gap
The natural response from most security-focused engineering leaders is to point at existing controls and argue that they compensate. Code review catches bad logic. Static analysis catches known vulnerability patterns. Dependency scanning covers the supply chain. This argument is partially correct and mostly beside the point.
Code review is a quality and correctness control, not a provenance control. A reviewer who approves a function is attesting that the logic looks sound, not that they know where it came from or have verified its compliance properties. These are different questions. A well-written JWT validator that was generated by an LLM from a prompt that included a snippet of copyleft-licensed reference code is not made safe by passing review.
Static analysis tools like semgrep and Snyk Code can catch known vulnerability patterns in AI-generated code the same way they catch them in human-written code. That is useful. But they cannot tell you that a piece of code is AI-generated, cannot assess its license implications, and cannot give you an attestation trail that says a qualified human reviewed it with awareness of its origin.
The gap is a control plane problem. You have controls that operate on code as text. You do not have a control that operates on code as attested output with a recorded origin story.
What Code-Origin Attestation Actually Looks Like
The path forward is not to make SBOM tools smarter about AI output, though that will come. The more immediate answer is to build an AI code assurance layer that sits alongside your existing supply-chain tooling and answers the question SBOMs were never designed to answer: where did this logic come from, and has a qualified human verified it with that knowledge?
In practice, this means three things operating together. First, generation-time capture: if your team uses AI coding assistants, the tooling should record that a generation event occurred, which model produced it, and a hash of the output. This does not require storing prompts in production systems. It requires a lightweight attestation artifact that can be attached to the commit. Second, review-time attestation: the PR review process should surface any AI-generated changes explicitly, so reviewers are not guessing. A reviewer who knows they are looking at LLM output applies different scrutiny than one who assumes the function came from a colleague. Third, release-gate verification: before code ships, an automated system should confirm that AI-generated changes have a corresponding attestation record and that the review process was satisfied.
This is the model OpenThunder is built around: verification that AI-assisted changes have been reviewed against your architecture, security requirements, and intent before they reach production. The AI code assurance verification layer is not a replacement for your SBOM. It is the missing complement to it, covering the class of code your SBOM cannot see by design.
Some teams try to approximate this with PR templates and manual labeling conventions. That approach works at a team of five and breaks at a team of fifty. The enforcement has to be structural, not cultural, because cultural controls erode under sprint pressure.
The Compliance Timeline Is Shorter Than You Think
FDA's software guidance for medical devices already references traceability to design intent for all software of unknown provenance. The EU Cyber Resilience Act, taking effect in phases through 2027, requires manufacturers to document the components and development practices behind connected products. NIST's SSDF includes attestation requirements that, when applied literally to AI-generated code, create obligations most organizations are not currently meeting.
None of these regulations name LLMs specifically yet. They do not need to. The underlying obligation, that you can demonstrate provenance and intentionality for the code you ship, applies regardless of how the code was produced. Regulators who encounter AI-generated code in a covered system will not be confused about whether the requirement applies. They will ask whether you have an attestation. The answer at most companies right now is no.
Acquirers are moving faster than regulators. A SBOM gap in due diligence can reprice a deal or trigger escrow requirements. An AI provenance gap is newer but following the same trajectory. The engineering leaders who build attestation practices now will have a clean answer when the question arrives. The ones who wait will be doing remediation under time pressure.
The SBOM was the right tool for the dependency-inventory era. AI-generated code is a different era, and it needs a different instrument.
See what OpenThunder verifies
OpenThunder independently verifies AI-assisted changes against your architecture, security, and intent before they ship, giving your team the attestation layer that SBOMs were never built to provide. Try it here.
The code your SBOM cannot see is not a corner case. It is becoming the majority of new logic, and the compliance posture that ignores it is one audit away from becoming a crisis.