A SBOM Is an Ingredient List. Most Organizations Are Missing Half the Ingredients.

A Software Bill of Materials is exactly what it sounds like: a structured inventory of every component in a software application, including names, versions, suppliers, dependency relationships, and cryptographic hashes. In theory, it gives you complete visibility into what your software is made of.

In practice, standard SBOM implementations capture direct dependencies, the packages your team explicitly declared in a manifest file. They routinely miss transitive dependencies: the packages your packages depend on, and the packages those packages depend on.

98% of applications include open source software components. Those components don’t arrive alone. Every package carries its own dependency tree with it, and those trees run deep. The majority of open source components in a typical application are transitive: packages pulled in by your direct dependencies, not chosen by your team [kusari; The Hidden Risk in Your Software: Understanding Transitive Dependencies]. Most of your actual attack surface exists below the line of what standard SBOM tools surface by default.

When a vulnerability lands in a component three layers down, your scanner may never connect it to your application. Your SBOM won’t flag it. Your team won’t know it’s there until something breaks.

Transitive Dependencies Are Where Attacks Actually Live

The SolarWinds campaign in 2020 didn’t target SolarWinds’ primary products directly. It targeted the build pipeline, the infrastructure that produced the software those products depended on. The payload was delivered through a component that had every reason to be trusted.

That’s the geometry of modern software supply chain attacks. Attackers don’t go through the front door. They go through a dependency that your team approved six months ago and hasn’t touched since.

Hidden dependencies create compounding risk in 3 specific ways:

They expand your attack surface invisibly. A team that approves Package A has no visibility into what Package A pulls in. If that transitive dependency is compromised, outdated, or maliciously crafted, the risk is real regardless of whether it appears in your SBOM.

They make incident response slower. When a critical CVE is disclosed, the first question is: are we affected? With incomplete dependency mapping, the answer requires manual archaeology across every application, every environment, and every package manager. That process takes days. According to Edgescan’s 2026 Vulnerability Statistics Report, the average for mean time to remediate critical CVEs lags upwards of 54 days and is largely driven by how long it takes teams to understand what they’re even dealing with.

They create compliance gaps that regulators are increasingly equipped to find. The EU Cyber Resilience Act and current SEC regulations both require documented evidence of open source oversight. “We didn’t know that package was in our stack” is not a defense. Incomplete transitive dependency tracking is, by definition, incomplete due diligence.

Component Variants Break the CVE Model

Here’s a problem most teams haven’t fully reckoned with: two applications can run the same version of the same package and have completely different security profiles.

Component variants or, different builds or configurations of nominally identical packages, exist everywhere in production environments. A Python package distributed as a source distribution and as a compiled wheel may have different dependency footprints, different compilation flags, and different vulnerability characteristics. Standard CVE databases track vulnerabilities by package name and version number. They don’t distinguish between variants.

This creates systematic false negatives in vulnerability reporting. A scanner confirms your version of a package is clean. It may be technically correct about the version number while being completely wrong about the actual artifact running in your environment.

Custom patches make this worse. Organizations regularly apply vendor-specific modifications to open source components. Those modifications rarely get captured in standard vulnerability tracking, which means the component your scanner evaluates and the component your application actually runs may not be the same thing.

The only way to close this gap is provenance at the build level: a documented, verifiable record of exactly what was compiled, from which source code, in which environment, with which dependencies, at which point in time. That’s not something most SBOM generators produce. It’s something that has to be built into the process from the point of origin.

AI Code Generators Have Changed the Math on Dependency Risk

Manual dependency management was already operating at the edge of what human teams could handle. AI code assistants have moved the problem well past that edge.

When an AI coding assistant suggests an import, it draws from training data that may be months or years out of date. It may suggest a package that was legitimate when the model was trained and has since been compromised. It may suggest a package that doesn’t exist at all, such as a hallucination that a malicious actor has already registered in anticipation of exactly this scenario such as, the Hugging Faces Spaces platform breach. It may suggest a package that exists and is clean today but has no active maintainer and a growing CVE backlog.

The volume is the real problem. AI agents don’t sleep, don’t take PTO, and don’t stop to evaluate whether the dependency they just pulled is actively maintained or has an open critical vulnerability. In a mid-sized development organization, the rate of dependency introduction through AI-assisted coding is effectively impossible to vet manually.

Scanning the output catches some of this. It doesn’t catch it fast enough, and it doesn’t catch all of it. Governance has to happen at the point where the dependency is introduced, not after it’s already in your build.

What “Complete” SBOM Coverage Actually Requires

An SBOM that supports genuine security governance needs to capture more than what’s in your manifest file. Practically, that means:

Full transitive dependency resolution. Every dependency of every dependency, traced to its actual depth, not just the first layer of imports. This includes OS-level libraries and shared system dependencies that sit below the language runtime layer.

Build-level provenance. Not just what component, but where it came from, how it was built, what environment it was built in, and a cryptographic record that can prove the artifact hasn’t been modified in transit. SLSA Level 3 is the current framework benchmark for what this looks like in practice.

Continuous updates. A point-in-time SBOM generated at deployment is stale the moment a new CVE is disclosed. Meaningful coverage requires SBOM generation integrated into CI/CD pipelines with continuous monitoring against vulnerability feeds, not quarterly audits.

Coverage of AI-generated dependency requests. If your AI coding assistants are pulling from public registries, your SBOM process needs to govern that layer specifically. Unvetted AI-introduced dependencies are the fastest-growing source of new exposure in the current development environment.

Variant-level tracking. Not just the package version, but the specific build artifact: its hash, its build environment, its compilation flags, and any patches applied on top of the upstream source.

The Regulatory Reality Has Changed the Stakes

Three years ago, a CISO who could produce a partial SBOM and evidence of a scanning program had a reasonable defense posture in most regulatory conversations. That’s no longer true.

SEC cybersecurity disclosure rules require written policies governing third-party risk management and material incident notification: frameworks that legal and compliance teams broadly interpret to include open source dependency oversight.  The EU Cyber Resilience Act places the burden on manufacturers to demonstrate due diligence and secure-by-design practices at the point of origin, with Phase 1 mandatory reporting to ENISA taking effect September 2026. “We had a scanner” is not a sufficient answer to either framework.

What regulators, auditors, and boards are asking for is documented due diligence: evidence that you knew what was in your environment, that you had a governance process for what entered it, and that you had a remediation commitment with defined timelines when things went wrong.

That’s a provenance and governance question, not a scanning question. The distinction matters because the two approaches produce fundamentally different artifacts. A scanner produces a report. A provenance-based governance model produces an immutable, verifiable audit trail.

The Gap Between Finding Risk and Managing It

Every security team in a modern development organization is already using some form of software composition analysis. The gap isn’t detection. Most teams can find vulnerabilities. The gap is the 54 day window between finding them and closing them, and the structural reasons that window exists.

Remediation at scale requires more than a vulnerability report and a ticket in the queue. It requires knowing exactly which component is affected and in exactly which applications. It requires the ability to rebuild and redistribute a patched version without breaking dependent builds. It requires someone who owns the fix and a timeline they’re accountable to.

For most organizations, that represents multiple engineering hours per CVE in research, testing, and deployment time, multiplied across however many vulnerabilities are in the backlog at any given moment. At AI-generated code volume, that math doesn’t close.

The organizations that are managing this effectively have moved from scan-and-pray to curate-and-govern: a model where open source enters through a controlled, vetted source, is continuously monitored against new vulnerability disclosures, and is remediated automatically when community-approved fixes are available, governed by defined SLAs rather than backlog priority.

That’s the posture that produces the audit trail regulators are looking for, the velocity security teams need to operate at, and the documented due diligence that protects the organization and the security leader personally when something goes wrong.

ActiveState and the Curate-and-Govern Model

ActiveState was built specifically for the problem described above. We provide the world’s largest library of built-from-source, continuously remediated open source software: 79 million vetted components across 12 major language ecosystems, including all transitive and OS-level dependencies, with full SLSA Level 3 build-level provenance on every artifact.

Every component in our library is scanned for CVEs and malware before it reaches your environment. When a community-approved fix is available, we rebuild the affected component from source and redistribute it automatically, governed by contractual SLAs: 5 business days for critical CVEs, 10 for highs, 30 for all others, against an industry average that lags upwards of 50 days.

Our Curated Catalogs integrate natively into the artifact repositories and AI coding assistants your teams already use. When an AI agent requests a dependency, it draws from your governed catalog rather than a public registry. The governance is embedded at the point of consumption, which is the only place it can realistically keep pace with AI-generated code volume.

If your current SBOM process doesn’t cover transitive dependencies, doesn’t provide build-level provenance, and doesn’t include a defined remediation commitment, you’re managing a liability. We can help you close that gap.

Talk to us about what complete open source software security looks like for your environment.