Securing the Software Supply Chain: SBOMs, Provenance, and Policy as Code

Modern applications are not written from scratch. They are assembled from open source libraries, internal packages, base images, build tools, and third-party services. That assembly process is the software supply chain, and it is now a primary target for attackers. High-profile incidents such as SolarWinds, Log4Shell, and the xz backdoor showed that compromising one dependency or build system can affect thousands of downstream organizations. Securing the supply chain is not a single tool or checkbox. It is a set of engineering practices: inventory, provenance, signing, policy, and continuous verification.

This article presents a practical model for supply chain security that you can implement incrementally. The goal is not perfect security. The goal is to make tampering, impersonation, and vulnerable dependencies much harder to introduce without detection, while giving responders the data they need when something goes wrong.

Why Software Supply Chain Security Matters

Traditional application security focuses on the code your team writes. Supply chain security extends that focus to everything your code depends on and everything that touches the artifact before it reaches production.

• Dependency risk: A single transitive dependency can introduce a critical vulnerability or malicious code. Log4Shell demonstrated how quickly a ubiquitous library can create global exposure.
• Build system risk: If an attacker can modify a build script, CI configuration, or build runner, they can inject code into every artifact without changing source code.
• Distribution risk: Artifacts can be replaced in a registry, package index, or update server. Without signatures, consumers cannot distinguish the real artifact from a tampered one.
• Compliance and customer trust: Regulators and enterprise customers increasingly ask for an SBOM, provenance evidence, and vulnerability disclosure processes.

Attackers follow the path of least resistance. Instead of attacking hardened production systems, they target the developer workstation, package registry, or CI pipeline. That shift makes supply chain security a first-class part of DevSecOps.

The Supply Chain Threat Model

A useful threat model for software supply chains covers source, dependencies, build, artifact storage, and runtime. Each stage has distinct attackers and controls.

Common Attack Vectors

• Typosquatting: Publishing a package with a name similar to a popular library, hoping developers mistype the install command.
• Dependency confusion: Uploading a public package with the same name as an internal private package, then relying on misconfigured resolvers to pull the public malicious version.
• Compromised maintainer: Taking over a maintainer account or social-engineering a maintainer into merging malicious code.
• Build injection: Modifying CI configuration, build scripts, or a reusable workflow to exfiltrate secrets or inject backdoors.
• Artifact tampering: Replacing a container image, binary, or package in a registry after it was built.
• Vulnerable transitive dependency: Shipping a known vulnerable library deep in the dependency graph, often without direct visibility.
• Compromised tooling: A code formatter, linter, test runner, or package manager plugin that runs with developer or CI privileges.

The defenses map directly to these vectors: dependency inventory, isolated builds, least-privilege CI, signing, provenance, and admission control.

The Core Primitives: SBOM, Provenance, Signatures, and Policy

Four primitives form the foundation of a practical supply chain security program.

SBOM: A Bill of Materials for Software

A Software Bill of Materials (SBOM) is a machine-readable inventory of components in a software artifact. It answers the question: what is inside this build? A good SBOM lists direct and transitive dependencies, package names, versions, suppliers, licenses, and cryptographic hashes where available.

The two dominant formats are SPDX and CycloneDX. SPDX has strong license and compliance roots. CycloneDX is designed for security use cases and supports vulnerabilities, services, and attestations. Both can represent container images, binaries, and source dependencies. The choice matters less than consistent generation and consumption across the pipeline.

SBOM generation should happen automatically at build time, not as an afterthought. Tools such as Syft, Trivy, cdxgen, and language-specific plugins can scan source trees, container images, and filesystems. Attach the SBOM to the artifact in a registry or store it in an artifact repository with a clear mapping to the image digest.

Provenance and Attestations

Provenance describes how an artifact was built: which source repository and commit, which build system, which build parameters, and which dependencies were used. Attestations are signed statements about an artifact. The in-toto framework defines a standard way to express supply chain metadata, and SLSA (Supply-chain Levels for Software Artifacts) provides a maturity model for provenance.

SLSA levels help teams reason about build integrity:

• SLSA 1: Build process is documented and provenance is generated.
• SLSA 2: Build service is hosted and generates signed provenance.
• SLSA 3: Build platform is hardened, with strong isolation and non-falsifiable provenance.
• SLSA 4: Two-party review and hermetic, reproducible builds.

Most organizations can realistically target SLSA 2 or 3 for critical services. The important step is to start producing signed provenance and verifying it before deployment.

Signing and Transparency

Signatures bind an identity to an artifact or attestation. Without signatures, provenance and SBOMs can be forged. Sigstore has become a popular open standard for signing, verification, and transparency. It includes Cosign for signing containers and blobs, Fulcio for short-lived certificates tied to OIDC identities, and Rekor for an immutable transparency log.

Keyless signing is attractive because it avoids long-lived private keys. A CI job authenticates to an OIDC provider, obtains a short-lived certificate, signs the artifact, and records the event in Rekor. Verifiers can check both the signature and the identity that produced it. For environments that require traditional keys, hardware-backed keys or KMS-backed keys are still viable.

Policy as Code

Policy as code turns security requirements into executable rules. Instead of documenting that images must be signed, you enforce it. Admission controllers such as OPA Gatekeeper and Kyverno can evaluate Kubernetes resources against policies. Cosign and other verifiers can run in CI or at admission time.

Example policy questions include:

• Is the container image signed by a trusted identity?
• Does the image have an SBOM and provenance attestation attached?
• Was the image built by the approved CI system from the correct repository?
• Are there critical vulnerabilities with a fix available?
• Is there an accepted VEX statement for known vulnerabilities?

Policy should start in audit mode, then move to enforcement for low-risk workloads, and finally become mandatory for production. This gradual approach reduces friction and gives teams time to fix pipelines.

Building a Practical Pipeline

A secure supply chain is a pipeline, not a point solution. The following stages integrate the core primitives into everyday development.

Stage 1: Dependency Inventory and SCA

Use Software Composition Analysis (SCA) to scan manifests and lockfiles for known vulnerabilities and license issues. Generate an SBOM at the same time. Treat the SBOM as a build artifact, not a report. Version it, store it, and link it to the artifact digest.

For containers, scan both the base image and the application layers. Base image choice matters: a minimal distroless or scratch image reduces the attack surface and the number of components to track.

Stage 2: SBOM Generation

Generate SBOMs in the build job after dependencies are resolved. For container images, generate an image SBOM after the final image is built. Use a consistent format, such as CycloneDX JSON, and include hashes. Sign the SBOM or include it in a signed attestation so consumers know it has not been altered.

Stage 3: Artifact Signing

Sign container images, binaries, and packages. Use keyless signing with Sigstore where possible. In CI, the signing step should run in a protected job with minimal permissions. The identity used for signing should map to a specific repository and workflow, not a broad personal account.

Stage 4: Provenance Attestation

Generate provenance that records the source commit, build system, builder identity, and build parameters. For GitHub Actions, the SLSA GitHub generator can produce provenance automatically. For other CI systems, in-toto attestations can be created manually or with a framework. Sign the provenance and attach it to the artifact.

Stage 5: Policy Enforcement at Admission

At deployment time, verify signatures and attestations before the workload is admitted. A Kubernetes admission policy can require that the image is signed by the trusted CI identity and has a valid SLSA provenance attestation. It can also check that the SBOM exists and that no critical vulnerabilities are present without an exception.

Stage 6: Continuous Monitoring and VEX

New vulnerabilities are disclosed every day. An SBOM from last month may not reflect today’s risk. Continuously match stored SBOMs against vulnerability feeds. Use VEX (Vulnerability Exploitability eXchange) statements to record whether a vulnerability actually affects your product. VEX reduces noise by distinguishing vulnerable components from exploitable paths.

Example: A Minimal Policy Check

At a high level, a verification step might look like the following. The exact command depends on your registry and policy engine.

cosign verify-attestation --type slsaprovenance --policy policy.rego ghcr.io/acme/app:1.2.3

A simple Rego policy could require provenance from the approved build system:

package supplychain

default allow = false

allow {
  input.predicate.builder.id == 'https://github.com/actions/runner'
  input.predicate.buildType == 'https://slsa.dev/provenance/v0.2'
}

In production, policies should also verify the source repository, branch, commit, and signer identity. Avoid policies that only check for the presence of an attestation without validating its contents.

Tooling Landscape

Many tools address parts of the problem. A composable toolchain is usually better than a single platform.

• SBOM generation: Syft, Trivy, cdxgen, Microsoft SBOM Tool, and CycloneDX plugins for Maven, Gradle, npm, and Go.
• Vulnerability scanning: Trivy, Grype, Dependency-Check, Snyk, and cloud-native scanners.
• Signing and attestations: Cosign, Sigstore, in-toto, SLSA generators, and Notary Project.
• Policy: OPA Gatekeeper, Kyverno, Conftest, and cosign policy controllers.
• Transparency: Rekor, transparency logs, and immutable artifact stores.
• VEX: OpenVEX, CycloneDX VEX, and vendor security advisories.

The integration layer matters most. If SBOMs are generated but never consumed, they become compliance theater. If signatures are created but not verified, they provide little protection.

Adoption Roadmap

Supply chain security can feel overwhelming. A phased approach keeps momentum and avoids breaking every pipeline at once.

1. Phase 1: Visibility. Generate SBOMs for all production artifacts. Store them centrally and link them to image digests. Start SCA and dependency review for pull requests.
2. Phase 2: Signing. Sign all build artifacts. Verify signatures in CI before publishing. Introduce keyless signing with Sigstore for new pipelines.
3. Phase 3: Provenance. Generate signed provenance for critical services. Require provenance for new workloads. Start with SLSA 2 and improve isolation over time.
4. Phase 4: Enforcement. Use admission control to require signatures and provenance in staging. Expand to production after teams have fixed their pipelines.
5. Phase 5: Operations. Monitor new CVEs against stored SBOMs. Use VEX to prioritize real risk. Practice incident response for supply chain compromises.

Each phase should have clear ownership. Platform teams usually own the build and admission infrastructure. Application teams own dependency updates and remediation. Security teams own policy, threat intelligence, and incident response.

Metrics That Matter

Measure progress with metrics that reflect risk reduction, not just tool adoption.

• SBOM coverage: Percentage of production artifacts with a current SBOM.
• Signature coverage: Percentage of artifacts signed and verified before deployment.
• Provenance coverage: Percentage of critical services with valid provenance attestations.
• Mean time to remediate: Time from vulnerability disclosure to patched deployment for critical findings.
• Policy violations: Number of admission denials and time to resolution.
• Dependency freshness: Percentage of dependencies within supported version ranges.

Track these metrics over time and tie them to incident reviews. A drop in signature coverage before a release is a useful early warning signal.

Common Pitfalls

• Treating SBOM as a compliance checkbox. An SBOM that is never queried during incidents provides little value.
• Signing without verifying. Signatures only help when consumers enforce them.
• Ignoring the build system. A signed artifact from a compromised builder is still compromised.
• Overly broad signing identities. Use workload-specific identities, not personal accounts with long-lived tokens.
• Alert fatigue. Raw vulnerability counts create noise. Use VEX, reachability analysis, and risk-based prioritization.
• No incident playbook. When a dependency is compromised, responders need to query SBOMs, identify affected artifacts, and revoke trust quickly.

Conclusion

Software supply chain security is a natural extension of modern engineering practice. The path is clear: know what is in your software with SBOMs, prove how it was built with provenance, sign artifacts and attestations, enforce policy at admission, and monitor continuously. Start with visibility, add signing, then provenance, and only then enforce. The organizations that treat the supply chain as a first-class part of their delivery pipeline will be far better prepared when the next SolarWinds, Log4Shell, or xz-style incident arrives.

The goal is not to eliminate every dependency or build your own compiler. The goal is to make trust explicit, verifiable, and automated. That is how you turn supply chain security from a vague concern into an operational capability.