On March 29, 2024, a Microsoft engineer named Andres Freund noticed his SSH logins were taking 500 milliseconds longer than usual on a Debian testing box. That five-tenths-of-a-second delay led to the discovery of CVE-2024-3094, a backdoor planted inside the XZ Utils compression library by a contributor who had spent over two years building trust in the project before slipping malicious code into release tarballs. The backdoor was never in the public GitHub source — it was injected during the build process, which is exactly the gap software provenance closes. Software provenance is the verifiable record of where a piece of software came from: which source commit, which build system, which build parameters, and which human or automated process produced the final artifact. Without it, a compiled binary is a black box you're trusting on faith. With it, you can cryptographically prove that what you're running matches what was supposed to be built.
What Is Software Provenance, Exactly?
Software provenance is metadata that answers "how was this artifact built, from what source, and by whom" in a way that can be independently verified rather than just asserted. A provenance record typically includes the source repository and commit hash, the builder identity (e.g., a specific GitHub Actions workflow or Google Cloud Build job), the build command and environment, the input dependencies, and a cryptographic signature binding all of it to the output artifact's hash. The OpenSSF's SLSA framework (Supply chain Levels for Software Artifacts, pronounced "salsa") formalized this into a schema: a SLSA provenance document is a signed, machine-readable attestation that a specific artifact digest — say, a container image's sha256 hash — was produced by a specific build invocation. This is different from a changelog or a commit message; it's closer to a notarized chain of custody that a verifier can check without trusting the vendor's word.
Why Does Software Provenance Matter for Supply Chain Security?
Software provenance matters because it turns "trust the vendor" into "verify the artifact," which is the only way to catch attacks that happen after code review but before deployment. The SolarWinds Orion breach, disclosed in December 2020, is the canonical example: attackers compromised the build pipeline itself, inserting the SUNBURST backdoor into signed updates that shipped to roughly 18,000 customers, including nine federal agencies. Code review of the Orion source repository would have shown nothing wrong — the malicious code was injected during compilation. A build system with cryptographically verified provenance, where the build server's identity and process are attested and checked against an expected policy, would have produced a mismatch between the expected and actual build lineage. Similarly, the 2021 Codecov incident involved attackers modifying a Bash uploader script on Codecov's own GCS bucket for roughly two months (from January 31 to April 1, 2021) before detection, harvesting credentials from thousands of CI environments. Provenance verification at the point of consumption — checking that a script or package matches its attested source — is what closes both gaps.
How Is Software Provenance Different From an SBOM?
A software bill of materials lists what's inside an artifact, while provenance proves how that artifact came to exist — they answer different questions and both are needed. An SBOM in CycloneDX or SPDX format enumerates components: "this container image includes OpenSSL 3.0.13, libcurl 8.6.0, and 214 other packages." It's an inventory, similar to a nutrition label. Provenance, by contrast, is a chain-of-custody record: it tells you that the artifact with digest sha256:4f2a... was built from commit a1b2c3d in a specific repository, using a specific GitHub Actions workflow run, with no untracked modifications. You can have a perfectly accurate SBOM for a backdoored artifact — the XZ Utils backdoor would still show up as "xz-utils 5.6.1" in an SBOM, listing the correct package name and version, because the SBOM doesn't tell you whether the build process was tampered with. NIST's Secure Software Development Framework (SP 800-218) and the NTIA's 2021 minimum elements guidance both treat SBOMs and provenance attestations as complementary, not interchangeable, controls.
What Regulations or Standards Require Software Provenance?
U.S. Executive Order 14028, signed May 12, 2021, is the regulatory root of most current provenance requirements, directing NIST to define secure software development guidance that federal software vendors must attest to. That guidance became NIST SP 800-218 (the Secure Software Development Framework) and the accompanying self-attestation form (CISA's Secure Software Development Attestation Form, finalized in 2023) that software vendors selling to federal agencies must sign, covering build environment integrity and provenance tracking. The EU's Cyber Resilience Act, which entered into force in December 2024 with core obligations phasing in through December 2027, similarly requires manufacturers of "products with digital elements" to maintain records of the software supply chain, including build provenance for critical components. In the open-source ecosystem, npm has required provenance attestations (via Sigstore) as a first-class feature since April 2023, and PyPI added support for Trusted Publishers with attestation in 2023-2024, both letting package consumers verify that a published package matches a specific CI build rather than an arbitrary local npm publish from a maintainer's laptop.
How Do You Actually Verify Software Provenance?
Software provenance is verified by checking a cryptographically signed attestation against the artifact's hash and a policy of what "acceptable" provenance looks like, most commonly using Sigstore and in-toto. The workflow looks like this: a CI system (GitHub Actions, GitLab CI, Google Cloud Build) generates a provenance attestation in the in-toto format at build time, describing the source commit, builder identity, and inputs. That attestation is signed — increasingly using Sigstore's cosign, which issues short-lived certificates tied to an OIDC identity (like a GitHub Actions workflow's OIDC token) instead of requiring maintainers to manage long-lived private keys, and logs the signature to the public Rekor transparency log. A consumer — a CI gate, an admission controller in Kubernetes, or a security platform — then verifies the signature, checks the transparency log entry, and evaluates the attestation against policy: "was this built by the expected repository's release workflow, at SLSA Build Level 3, with no unsigned or unknown inputs?" Google's internal supply chain reportedly runs at SLSA Build Level 3 or above for most production binaries, and Kubernetes' own release process has published SLSA provenance since v1.24 in 2022.
How Do You Implement Provenance Checks in a CI/CD Pipeline?
Implementing provenance in a CI/CD pipeline starts with generating attestations at build time and ends with enforcing verification at deploy time, not just generating documents nobody checks. In practice this means three concrete steps: first, instrument the build job to emit a signed in-toto/SLSA provenance statement for every artifact (GitHub's official actions/attest-build-provenance action, generally available since April 2024, does this for GitHub-hosted runners in a few lines of YAML). Second, publish the SBOM and provenance attestation alongside the artifact — container registries like GHCR and Artifactory support OCI attestation manifests for exactly this. Third, and most often skipped, add a policy gate before deployment (an admission controller, an OPA/Gatekeeper policy, or a CI check) that rejects any artifact lacking a valid, expected provenance chain. A 2023 Sonatype survey of 662 IT professionals found that only about 40% of respondents' organizations had any process to verify open-source component integrity before use — the generation step is increasingly common, but the enforcement step is where most pipelines still leave the door open.
How Safeguard Helps
Safeguard operationalizes provenance so it's enforced, not just collected. Our platform ingests and generates SBOMs across your build pipeline and cross-references every dependency's provenance attestations against SLSA and in-toto policy, flagging artifacts with missing, unsigned, or mismatched build lineage before they reach production. Reachability analysis then narrows that signal to what actually matters — a component with weak provenance but zero reachable call paths in your codebase gets deprioritized, while one that's both unverified and exploitable gets escalated immediately. Griffin AI, Safeguard's detection engine, correlates provenance gaps with known attack patterns (compromised maintainer accounts, anomalous build servers, typosquatted dependency names) to catch novel supply chain compromises rather than relying solely on static rule sets. When a fix is available, Safeguard opens an auto-fix pull request that pins the dependency to a version with verified provenance, so remediation takes minutes instead of a ticket queue.