Provenance answers where an artifact came from and which workflow produced it. Legitimacy answers whether that workflow, branch, and release decision were trustworthy at the time. A package can have strong provenance and still be malicious if the publishing identity was compromised or misused.
How provenance and legitimacy separate two different trust questions
In software supply chain, provenance is about traceability: what artifact was built, from what source, and by which workflow. Legitimacy is about trustworthiness at the moment of publication or release: whether that workflow, branch, maintainer identity, and approval path were valid. The difference matters because a traceable build can still be unsafe if the actor or process behind it was compromised.
Provenance is mainly an evidence question. You are asking whether the artifact can be linked back to a known source state, build system, or signing path, so that consumers can inspect how it was produced. That usually involves build metadata, attestations, signatures, and reproducible or verifiable build records. The more complete the provenance, the easier it is to answer “what made this artifact?” with confidence.
Legitimacy is a governance and authorization question. You are asking whether the release was produced by a workflow that should have been trusted, on a branch that should have been allowed, and under credentials or approvals that were valid at the time. This is where compromise changes the interpretation: a malicious actor can produce a well-formed artifact with excellent provenance, yet the release is still illegitimate if the publishing path was hijacked.
Why the distinction matters in release and consumer decisions
Consumers often treat “has provenance” as if it means “is safe to use,” but those are not the same conclusion. Provenance helps you verify origin and reconstruct the build path; legitimacy helps you decide whether the originator had the right to publish in the first place. A package can pass one test and fail the other, so both are needed before you make a high-confidence trust decision.
The practical consequence is that provenance should never be the only gate for production use. If a maintainer account, CI token, release branch, or signing key is stolen, the attacker can publish artifacts that look authentic and still carry malicious logic. That is why supply-chain review has to cover both artifact lineage and the trust state of the publishing process.
Seen that way, provenance supports verification and forensics, while legitimacy supports access control and release governance. One tells you where the artifact came from; the other tells you whether the path was still worthy of trust when the artifact was created.
What teams should verify before they trust a package or release
Start by checking that the artifact is tied to a specific source revision, build pipeline, and signing or attestation record. Then verify that the release path itself was authorized, meaning the maintainer identity, branch protection, token scope, and approval state were intact at publication time. The strongest result is when provenance and legitimacy reinforce each other rather than answering different questions.
SLSA is useful here because it formalises provenance and build integrity expectations for software artifacts, while OpenSSF provides broader supply-chain guidance and tooling that help teams harden release paths. For release control and secure build practices, NIST SSDF (SP 800-218) is a strong companion reference.
For consumers, the decision rule is simple: if provenance is strong but the publishing identity or workflow was exposed, treat the artifact as suspect until the trust path is explained. For maintainers, the goal is to keep provenance records useful while also shrinking the chance that a compromised release identity can weaponise that same credibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Provenance and build integrity are central to this artifact-traceability distinction. |
| Recommendation — Adopt SLSA-aligned provenance controls to verify source lineage and build integrity before release. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Release trust depends on supply-chain controls around sourced artifacts and build paths. |
| IA-5 — Authenticator Management | Legitimacy can fail when publishing credentials or tokens are stolen or misused. | |
| AC-6 — Least Privilege | Legitimate publishing depends on limiting who can approve or publish artifacts. | |
| Recommendation — Apply SA-12 to govern artifact provenance, build trust, and supplier-controlled release risk. Use IA-5 to rotate and revoke publishing credentials that could validate illegitimate releases. Use AC-6 to restrict release rights so compromised identities cannot publish trusted artifacts. | ||
| OWASP ASVS | V11 — Cryptography | Artifact signing and verification are key mechanisms in provenance assurance. |
| Recommendation — Use V11 to require verifiable signing and validation of build artifacts and release metadata. | ||
Practitioner Guidance
What to verify: Check both the source lineage and the release authority. In practice, that means confirming the source revision, build attestation, signing material, branch rules, and whether the publishing identity or token could have been abused at release time.
Decision rule: If you can only prove where an artifact came from, but not that the release path was trustworthy, do not treat the artifact as cleared for high-trust use. Provenance supports evidence; legitimacy supports trust.
What good looks like: The artifact is traceable to a specific build, the build is reproducible or well-attested, and the publication path is protected by current access controls rather than inherited trust.
Practitioner takeaway: Provenance answers “can I trace this artifact back?”, but legitimacy answers “was the right actor allowed to publish it?”, and both checks are required before supply-chain trust is justified.
Related resources from NHI Mgmt Group
- What is the difference between provenance tracking and artifact verification in software supply chains?
- What is the difference between code provenance and an SBOM for software supply chain security?
- What is the difference between provenance and simple software inventory in supply chain security?
- What is the difference between attack surface management and NHI governance?