Software Supply Chain Security for Open Source Dependencies
The dependency graph is not merely a technical artifact of the build system. It's an attack surface, and its topology determines what is reachable. Direct dependencies are only the first layer. Transitive dependencies, the dependencies of your dependencies, extend the graph far beyond what most engineering teams actively monitor or even enumerate. Log4Shell made this concrete. The affected library was a transitive dependency invisible to the vast majority of affected teams until exploitation was already underway. You didn't install it yourself. Something you installed did.
Several attack vectors account for most documented incidents in this space. Dependency confusion exploits the precedence logic of package resolvers. An attacker publishes a malicious package to a public registry under the same name as a private internal package, and the resolver fetches the public version instead. Typosquatting registers package names one or two characters removed from widely-used libraries, capturing installation attempts from developers who mistype. Maintainer account compromise follows the XZ Utils pattern, where access is earned through years of sustained, legitimate-seeming engagement before the malicious change is introduced. Build system compromise injects malicious code not into the source repository but into the pipeline itself, as SolarWinds demonstrated.
The reason conventional security tooling struggles with all of these is the same reason they're so effective. The malicious artifact arrives as a legitimate, requested package. It passes firewall inspection. It satisfies endpoint controls. The attack exploits the trust model of package registries and CI/CD systems, not a network-layer vulnerability. Perimeter-style security is structurally irrelevant here, and that's a hard truth for organizations that have spent heavily on perimeter controls.
Modern CI/CD pipelines compound this by design. They're highly automated, composed of many interconnected components, and often lack clear identity boundaries between stages. Artifacts flow through multiple systems before reaching production, and each handoff is an integrity checkpoint that, in most organizations, goes unverified. Wiz's 2025 State of Code Security Report found that 61% of organizations have secrets exposed in public repositories. If secrets management is still unresolved, the question of cryptographic artifact verification is even further from being answered.
What an SBOM actually contains and why the inventory matters before anything else
A Software Bill of Materials is a formal, machine-readable inventory of every component in a software product, including direct and transitive dependencies, their versions, provenance, and associated metadata. It's not a one-time document. It is most operationally valuable when generated at image build time, capturing the full dependency tree including operating system packages, because that is the only moment when the complete artifact composition is knowable with precision. Generate it later, from a running system, and you will miss ephemeral build dependencies. The picture is already incomplete.
Two formats dominate the current landscape. SPDX, the Software Package Data Exchange, emphasizes license metadata, provenance, and rich extensibility, making it well-suited to legal and compliance workflows. CycloneDX is more operationally focused and more widely adopted in security tooling pipelines. Both are machine-readable; the choice between them typically depends on downstream tooling requirements and the regulatory context in which the SBOM will be consumed.
When Log4Shell surfaced, organizations that had SBOMs identified affected applications within minutes. Organizations without them spent days or weeks manually tracing which systems had pulled in the affected library. Spending days during an active exploitation campaign is not a measurement of inconvenience. It is a measurement of exposure window. That gap is what makes SBOM generation a security decision rather than a documentation exercise. Beyond vulnerability triage, SBOMs support license and IP compliance tracking across the full dependency tree, provenance tracing through forks and backports, and risk-informed decisions at acquisition and deployment.
Here is the honest limitation. An inventory without exploitability context generates alert fatigue. A long list of CVEs with no signal about which ones are reachable in a specific application's execution context is a burden, not an asset. SBOMs gain real operational leverage when paired with provenance attestations and cryptographic signatures. Emerging approaches integrating runtime telemetry and machine-learning-assisted triage are beginning to address the signal-to-noise problem, and extended BOM types for AI models, data pipelines, and firmware are developing as the artifact landscape broadens.
The workflow implication is simple, even if the organizational will to implement it is not. SBOM generation belongs in the CI/CD pipeline, as a required stage, not in a security team's quarterly review cycle.
Proving where software came from: provenance attestations and the SLSA framework
An SBOM tells you what is present. It doesn't tell you whether the artifact you received matches what was actually built from the declared source. That is a different question, and it is the question provenance attestation answers. Was this artifact built from this source repository, by this build system, at this time, through this pipeline? The technical substrate is the in-toto attestation framework, a signed document associating cryptographically verifiable metadata with a software artifact.
SLSA, the Supply-chain Levels for Software Artifacts framework, is the structured approach the industry has coalesced around for defining and enforcing provenance requirements. Maintained by the Open Source Security Foundation, SLSA defines increasingly strict requirements for how software is built and how provenance is generated, protected, and verified. The current stable release, SLSA v1.2, published in November 2025, introduced a Source Track that extends provenance requirements to the repository level, not just the build pipeline. This matters because it begins to address the XZ Utils class of problem, where the compromise occurred in the source before the build ever ran. A SLSA-compliant pipeline would have attested the build faithfully, and the attested code would still have been malicious. That's not a flaw in SLSA; it's a reminder of what provenance actually proves.
The levels define a clear progression. Each successive level adds controls over build environment isolation, the identity of the builder, and the verifiability of outputs. The practical significance is that this creates a defensible, auditable record of how an artifact came to exist.
Provenance controls are increasingly platform-native rather than add-on. GitHub Artifact Attestations provide SLSA Build Level 3 capabilities as a built-in feature. npm trusted publishing auto-generates provenance attestations for packages released through its pipeline. The shift since 2025 is meaningful. SLSA compliance is something platforms can emit by default, not something teams must architect from scratch. That matters enormously for adoption. The controls that are hardest to implement are the ones most likely to get skipped.
Verification tooling exists and is actively maintained. The slsa-verifier tool checks cryptographic signatures and matches expected builder identity and source repository. The remaining operational challenges are real: large volumes of attestation metadata, key rotation overhead across long-lived artifacts, and the discipline required to actually verify attestations at deployment rather than merely generate them at build time. Combining SLSA with structured threat modeling, such as STRIDE, and the NIST Secure Software Development Framework produces a strategy grounded in both threat awareness and policy, rather than a compliance checklist that gets checked once and filed.
Why reproducible environments are a supply chain control, not just a developer convenience
Most teams treat environment reproducibility as a developer experience problem. It is, more precisely, a security problem, and the data makes clear how far short most builds fall. A study of 5,298 Docker builds found that only 6.4% of rebuilt images matched the original set of installed package versions exactly, and bitwise identity between rebuilds was virtually never achieved. The causes are consistent: nondeterministic build steps involving timestamps and cache state, failure to pin transitive dependencies alongside direct ones, and package repository evolution over time.
The security failure mode this creates is specific and exploitable. When developer, CI, and production environments diverge, the SBOM and provenance data generated in one environment may not accurately describe what is actually running in another. An attacker who can influence a dependency version through package repository evolution can cause a different artifact to be built from the same declared source. This is not a theoretical attack path. It's a direct consequence of treating environment definitions as approximations rather than specifications.
What the fix requires is a package management approach that treats each build as a function of its declared inputs, with no implicit reliance on ambient system state. Lock files must pin exact versions, including transitive dependencies, not just direct ones. The same environment definition must work across operating systems and architectures, because an environment that behaves differently on a developer's laptop than on a CI runner is an environment that can't be attested with any confidence. Every change to environment definitions must have a clear record and owner. These aren't novel engineering ideas; they're discipline applied consistently.
The connection to SLSA closes the argument. An environment that can be reconstructed exactly from a version-controlled definition is one that can be audited, compared, and attested. Treating environment definitions as security artifacts, subject to the same rigor as source code, closes a gap that most organizations have quietly left open, often because no one was assigned to own it.
The regulatory and compliance landscape organizations are now navigating
The regulatory environment has moved decisively toward mandatory supply chain controls. U.S. Executive Order 14028, signed in May 2021, established the first major mandatory SBOM requirement for software sold to federal agencies. CISA released a draft updated SBOM guide on August 22, 2025, building on the 2021 NTIA Minimum Elements document to incorporate real-world implementation lessons and address emerging contexts including SaaS products and AI systems.
The EU Cyber Resilience Act raises the commercial stakes considerably. It mandates third-party supplier assessments, continuous software monitoring, vulnerability scanning, and transparent SBOMs for products with digital elements sold in the EU market. Non-compliance penalties reach up to 15 million euros or 2.5% of global annual revenue, whichever is higher. The CRA applies to any organization selling covered products in the EU, regardless of where that organization is headquartered. Geography is no longer a shield.
Executive alignment is following regulatory pressure, though the gap between stated priority and implemented control remains wide. The World Economic Forum's Global Cybersecurity Outlook 2025 found that 78% of CISOs and 87% of CEOs cite improving security posture and mitigating cyber risk as primary motivations for adopting new regulatory frameworks. Gartner projected that by 2025, 60% of organizations building or procuring critical infrastructure software would mandate SBOMs, up from less than 20% in 2022. SBOM generation is transitioning from a differentiator in vendor assessments to a baseline expectation.
What compliance frameworks don't resolve is equally important to understand. Mandating SBOM generation does not specify where in the workflow generation occurs or how currency is maintained. An organization that generates an SBOM once at release and submits it to satisfy a procurement requirement hasn't meaningfully improved its vulnerability response posture. A checked box is not an integrated incident response capability. It's not a live comparison against current vulnerability feeds. It will not help anyone respond faster than an adversary can exploit a disclosed CVE.
Building the workflow: where SBOM generation, provenance, and environment controls connect
The architectural principle that holds this together is straightforward. Security controls belong at the point of creation, not the point of audit. An SBOM generated at image build time captures the full dependency tree accurately, because the build is the moment of composition. A provenance attestation signed at build time creates an unforgeable cryptographic link between source, build environment, and artifact. A reproducible environment definition ensures that the build is reconstructible and that the attestation remains meaningful when the artifact is deployed, re-deployed, or compared against a later build. These three controls are interdependent; weakening any one of them degrades the others.
The CI/CD pipeline is the natural integration point. Environment definitions, pinned to exact versions including transitive dependencies, should be version-controlled and treated as first-class security artifacts. SBOM generation should be a required pipeline stage that runs before any artifact is promoted, not an optional scan that runs if someone remembers. Provenance attestations should be generated and signed at build time, with verification enforced at deployment. The pipeline enforces these steps as gates, not suggestions.
This integration changes what incident response actually looks like. When a new critical CVE is disclosed, an organization with this workflow can query its SBOM inventory across all production artifacts, identify which ones contain the affected component, cross-reference provenance records to confirm build lineage, and prioritize remediation based on actual exposure rather than theoretical presence. The difference between hours and weeks of response time is not primarily a tooling difference. It's a workflow architecture difference.
The tools exist and are maturing. The frameworks, SLSA for provenance, SPDX and CycloneDX for SBOM format, in-toto for attestation, are stable and supported. The regulatory requirements are set and tightening. The threat data on trajectory is not ambiguous. What remains is the organizational decision to treat supply chain security as a design constraint on the development workflow rather than a remediation activity performed after the fact. Every team I know that has built this workflow knew what to build long before they built it. We've just not seen enough of them actually build it.
