Securing the Software Supply Chain: SBOMs, Sigstore, and Reproducible Builds

Modern applications are rarely written from scratch. They are assembled from open-source libraries, internal packages, container base images, infrastructure-as-code modules, and build-time tools. That assembly line is the software supply chain, and it has become one of the most attractive attack surfaces in technology. A single compromised dependency or build runner can inject malicious code into thousands of downstream products.

High-profile incidents such as SolarWinds, Log4Shell, and the attempted xz utils backdoor showed that scanning for known vulnerabilities is not enough. You also need to know what is inside your software, how it was built, who built it, and whether the resulting artifact can be independently verified. This article covers three practical pillars for improving supply chain security: SBOMs, provenance and attestation with Sigstore, and reproducible builds.

Why the Software Supply Chain Is an Attack Surface

The supply chain includes everything that touches code before it reaches production: source repositories, dependency managers, CI/CD runners, build caches, artifact registries, signing systems, and deployment controllers. Attackers can target the weakest link, which is often a transitive dependency maintained by a volunteer or a CI job with excessive permissions.

• Dependency confusion: Attackers publish malicious packages with names that match internal packages, hoping build systems resolve the public package first.
• Typosquatting: A package named similarly to a popular library catches developers who mistype an install command.
• Compromised maintainer accounts: A stolen npm, PyPI, or GitHub token can publish a malicious version of a trusted package.
• Build system compromise: If an attacker controls a CI runner, they can inject code during the build phase without changing source code.
• Mutable artifacts: Tags such as latest can be reassigned, so the image or package you tested may not be the one deployed later.
• Weak verification: Many organizations deploy artifacts without checking signatures, provenance, or build policy.

A strong supply chain strategy reduces these risks by making artifacts verifiable and tamper-evident. It does not rely on trust in a registry or a network boundary.

The Three Pillars: Visibility, Provenance, and Reproducibility

Supply chain security is often framed as compliance, but the engineering goals are clearer:

• Visibility: Know every component in your software, including transitive dependencies. This is where SBOMs help.
• Provenance: Prove how an artifact was built, from which source commit, by which builder, and with which parameters. This is where attestations and Sigstore help.
• Reproducibility: Independently rebuild the same artifact from source and compare the result. This is the strongest verification, because it detects tampering even in the build environment.

These pillars reinforce each other. SBOMs tell you what to investigate when a new vulnerability appears. Provenance tells you whether an artifact came from your expected pipeline. Reproducibility lets you verify that the published binary matches the source and build definition.

SBOMs: A Bill of Materials for Software

A Software Bill of Materials is a machine-readable inventory of components, versions, licenses, and relationships in a software artifact. It answers questions such as: Does this container include Log4j? Which services use a vulnerable version of OpenSSL? What transitive dependency pulled in a risky package?

There are two dominant SBOM formats:

• SPDX: An ISO standard with strong license and file-level metadata. Common in compliance and open-source governance.
• CycloneDX: A security-focused format with support for vulnerabilities, services, and VEX. Popular in DevSecOps tooling.
• SWID: A tagging standard useful for software identification, though less common for full dependency graphs.

SBOMs can be generated at different stages. Source-level SBOMs analyze manifests and lockfiles. Build-level SBOMs capture what actually entered the build. Container SBOMs inspect image layers and installed packages. Runtime SBOMs observe loaded libraries, but they are harder to produce consistently.

Useful tooling includes Syft, Trivy, cdxgen, and the SPDX SBOM Generator. The key is to generate SBOMs automatically in CI, attach them to the artifact, sign them, and store them in a queryable system such as Dependency-Track or a security data lake.

An SBOM is not a vulnerability scanner, and it is not a silver bullet. It becomes valuable when combined with vulnerability data, VEX statements, and policy checks. For example, when a new CVE drops, you can query your SBOM store to find affected artifacts in minutes instead of days.

Provenance and Attestation: Proving How an Artifact Was Built

Provenance is a signed statement about how an artifact was produced. It typically includes the source repository, commit SHA, build system, build parameters, dependencies, and the identity of the builder. The SLSA framework, pronounced salsa, provides a common vocabulary for supply chain integrity levels.

• SLSA Level 1: Build process is documented and provenance is available, but not necessarily signed.
• SLSA Level 2: Provenance is signed by the build service, and the build runs on a hosted platform.
• SLSA Level 3: Build runs in an isolated, ephemeral environment with strong identity and non-falsifiable provenance.
• SLSA Level 4: Build is hermetic and reproducible, with two-party review and strong isolation.

In practice, many teams start at Level 2 or 3 using hosted CI systems. The provenance is generated as an in-toto attestation, a signed JSON document that describes a step in the supply chain. The attestation can then be verified before deployment.

Sigstore has become the default toolkit for signing and verifying software artifacts. It includes:

• Cosign: A CLI for signing container images, blobs, and attestations.
• Fulcio: A certificate authority that issues short-lived signing certificates based on OIDC identity.
• Rekor: An immutable transparency log that records signing events.

Keyless signing with Sigstore avoids long-lived private keys. The build system authenticates with an OIDC provider such as GitHub Actions, Google, or Microsoft. Fulcio issues a short-lived certificate bound to that identity, Cosign signs the artifact, and Rekor records the signature. Verifiers can check the signature, the certificate identity, and the transparency log entry.

A typical flow looks like this:

• The CI job builds a container image and pushes it by digest.
• Cosign signs the image using keyless OIDC identity.
• The build system generates an SBOM and a SLSA provenance attestation.
• Cosign attaches both attestations to the image.
• At deploy time, an admission controller such as Kyverno, OPA Gatekeeper, or Sigstore policy-controller verifies the signature and attestations against policy.

Policy can require that the image was built by a specific repository, from a specific branch, with a signed SBOM, and without critical vulnerabilities that have no VEX exception. This shifts trust from network location to cryptographic verification.

Reproducible Builds: Trust but Verify

Reproducible builds mean that anyone can rebuild the same source code with the same build environment and get a bit-for-bit identical artifact. This is a high bar, but it provides the strongest guarantee: if the published binary matches the independently rebuilt binary, you know the build process did not inject anything.

Reproducibility is difficult because builds are sensitive to timestamps, file ordering, absolute paths, random seeds, compiler versions, locale settings, and dependency resolution. Common sources of non-determinism include:

• Timestamps: Embedded build dates or file modification times. The SOURCE_DATE_EPOCH environment variable helps normalize them.
• Build paths: Absolute paths in debug symbols or generated code. Use remap or strip flags.
• Filesystem ordering: Directory traversal order can vary. Sort inputs explicitly.
• Randomness: Non-deterministic build scripts, UUIDs, or hash seed randomization.
• Floating dependencies: Unpinned versions in lockfiles or dynamic dependency resolution.

Tools and ecosystems have made progress. Debian has a reproducible builds project with thousands of verified packages. Nix and Bazel emphasize hermetic, deterministic builds. Container builds can be made more reproducible by pinning base images by digest, avoiding apt-get upgrade, sorting layers, and using tools such as BuildKit with reproducible flags.

You do not need full reproducibility on day one. Start by making builds deterministic enough to compare, then track the percentage of artifacts that can be independently rebuilt. Even partial reproducibility catches many tampering scenarios.

Putting It Together: A Reference Pipeline

A practical supply chain security pipeline combines all three pillars. Here is a reference flow that works with common CI/CD systems:

• 1. Pin dependencies: Use lockfiles with hashes, dependency review, and private package allowlists. Block unknown registries.
• 2. Isolate the build: Use ephemeral runners, least-privilege tokens, and network egress rules. Do not expose signing keys to build jobs.
• 3. Generate an SBOM: Create CycloneDX or SPDX SBOMs in CI. Sign the SBOM with Cosign and attach it to the artifact.
• 4. Produce provenance: Use a SLSA-compatible generator to create a signed in-toto attestation with source and build metadata.
• 5. Sign the artifact: Sign container images and binaries by digest using keyless Sigstore. Record the signature in Rekor.
• 6. Store immutably: Push artifacts to a registry that supports immutable tags, and always deploy by digest.
• 7. Verify at admission: Use Kyverno, Gatekeeper, or Sigstore policy-controller to require valid signatures, provenance, and SBOM attestations.
• 8. Monitor continuously: Re-scan SBOMs as new vulnerabilities appear. Use VEX to suppress false positives. Monitor Rekor for unexpected signing events.

This pipeline does not require a complete platform replacement. It can be adopted incrementally. The most important step is to stop trusting mutable tags and start verifying signatures and provenance at deploy time.

Tooling Landscape

The supply chain ecosystem is maturing quickly. A practical toolkit might include:

• SBOM generation: Syft, Trivy, cdxgen, SPDX SBOM Generator.
• Signing and attestation: Sigstore Cosign, Fulcio, Rekor, in-toto, SLSA generators.
• Policy enforcement: Kyverno, OPA Gatekeeper, Sigstore policy-controller, Connaisseur.
• Reproducible builds: Nix, Bazel, Debian reproducible builds tooling, reproducible-builds.org.
• Vulnerability correlation: Grype, Trivy, Dependency-Track, OSV, VEX tooling.

Choose tools that integrate with your existing CI/CD and registry. Avoid adding a separate security pipeline that developers bypass. The best controls are embedded in the path to production.

Common Pitfalls and How to Avoid Them

• SBOM theater: Generating SBOMs but never using them. Avoid this by integrating SBOM queries into incident response and policy gates.
• Unsigned attestations: An attestation without a signature is just a claim. Sign everything and verify signatures.
• Verification only in production: Catch issues in staging and CI as well. The earlier you verify, the cheaper the fix.
• Ignoring the build environment: A clean source tree does not help if the CI runner is compromised. Harden runners and use ephemeral environments.
• Long-lived signing keys: Keys leak. Prefer keyless signing with short-lived certificates and transparency logs.
• No VEX: Vulnerability scanners produce false positives. VEX statements let you document exploitability and reduce noise.
• Mutable base images: A base image tag can change. Pin by digest and rebuild regularly.
• Overly broad policies: Blocking every low-severity issue creates fatigue. Start with critical, exploitable, and reachable vulnerabilities.

Measuring Success

Supply chain security is a program, not a one-time project. Track metrics that show real risk reduction:

• Percentage of artifacts with a signed SBOM.
• Percentage of artifacts with SLSA provenance at Level 2 or higher.
• Percentage of deployments that pass signature and attestation verification.
• Mean time to identify affected artifacts when a new vulnerability is announced.
• Number of policy violations blocked before production.
• Percentage of container images pinned by digest.
• Number of reproducible builds verified independently.

Report these metrics to engineering and leadership. They turn supply chain security from a vague compliance requirement into an engineering capability.

Conclusion

The software supply chain is too large and too dynamic to secure with manual reviews and perimeter defenses. SBOMs give you visibility, Sigstore and SLSA give you provenance and cryptographic verification, and reproducible builds give you the ability to independently confirm that an artifact matches its source. Start with SBOM generation and keyless signing, then add provenance verification at admission, and gradually improve build reproducibility. Each step reduces the blast radius of the next supply chain attack.