Software provenance is gaining new importance as organizations look for ways to secure their supply chains against tampering and comply with emerging standards like SLSA. In a recent blog post, HashiCorp highlighted how its HCP Packer service captures build metadata and SBOMs to support Supply-chain Levels for Software Artifacts (SLSA) Level 1 compliance.
Attacks such as SolarWinds and CodeCov showed how a compromised build process can allow malicious code to reach thousands of downstream users . Regulators have responded: in the U.S., Executive Order 14028 requires federal software suppliers to provide verifiable provenance, while Europe’s Cyber Resilience Act imposes similar obligations.
For practitioners, the implications are clear: Being able to prove exactly how software was built is becoming essential.
Two open source projects have shaped how the industry approaches provenance: Sigstore provides cryptographic signing and transparency infrastructure designed for broad ecosystem adoption. The model has gained traction across major ecosystems such as npm, PyPI, and Kubernetes, where provenance verification is now increasingly automated.
in-toto takes a different approach: it secures the entire pipeline by generating signed attestations for each step, verifying ‘who did what, when’ across builds, tests, and releases . Its layout model defines the expected steps and trusted actors, making tampering visible if any stage is skipped or altered.
HashiCorp’s Packer has long included metadata capture – recording details such as CLI and plugin versions, commit SHAs, and CI/CD pipeline context. More recently it added SBOM generation. What has changed is the positioning: HashiCorp is now presenting these features as a core provenance capability, emphasizing that HCP Packer can give teams a start on compliance out of the box.
Packer is not alone in this space. GitHub has introduced artifact attestations and SBOM generation as part of its Actions platform, allowing teams to generate signed provenance aligned with the SLSA specification. Red Hat’s Konflux, a Kubernetes-based build service, issues in-toto attestations as part of its pipelines, tying them to policy enforcement for a full trust chain.
This positioning highlights how vendors are still reliant on OSS tools to traverse the levels of the SLSA framework. Higher levels require stronger guarantees. Level 2 demands signed, tamper-resistant provenance, where Sigstore’s signing and transparency log are a natural fit. Levels 3 and 4 add verified source control and isolated build environments, where in-toto’s attestations help ensure every pipeline step follows policy.
Despite growing support, adoption isn’t trivial. Provenance formats are still evolving, and SBOMs often differ sharply depending on the tool or stage of generation, complicating comparison and verification. In addition, a qualitative study analyzing 1,523 GitHub issues across 233 repositories found that practitioners face significant barriers when adopting the SLSA framework—including “complex implementation” and “unclear communication” of requirements and processes
For engineering teams, the benefits are practical as well as regulatory. Provenance provides a clearer picture of the build process, helping with debugging, incident response, and audit preparation.
Provenance is increasingly being built in as a standard feature rather than an add-on. Open source projects like Sigstore and in-toto continue to define common practices, while vendors are integrating provenance into their platforms to make it easier to adopt. The level of assurance still varies, but usage is broadening across the software supply chain.
