Why do provenance attestations not fully solve supply chain compromise?

Why This Matters for Security Teams

Provenance attestations are valuable, but they only answer one narrow question: which build pipeline produced an artifact. They do not, by themselves, prove that the source change was approved, the workflow trigger was legitimate, or the runner was uncompromised. In supply chain security, that distinction matters because attackers often target repository trust, branch protections, and CI/CD permissions rather than the signing step itself.

Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research on the Reviewdog GitHub Action supply chain attack shows the same pattern repeatedly: a valid workflow can still be driven by a malicious or over-privileged identity. That means provenance can become a false comfort if teams treat it as a substitute for source integrity, workflow integrity, and runtime trust. In practice, many security teams encounter attestation failures only after a trusted pipeline has already distributed a malicious build.

How It Works in Practice

To understand the gap, it helps to separate artifact integrity from control-plane integrity. Provenance says, “this package came from this workflow, on this runner, at this time.” It does not say, “the commit was safe,” “the maintainer intended this change,” or “the workflow could not be abused.” Attackers exploit that gap by compromising the repository, altering a workflow file, weakening branch protections, stealing a maintainer token, or injecting a malicious dependency into a legitimate build path.

Practical defence usually layers several controls together:

• Signed commits and protected branches to raise the cost of unauthorised source changes.
• Workflow pinning, restricted triggers, and least-privilege CI identities to reduce abuse of build automation.
• Ephemeral credentials and short-lived secrets so a stolen token has limited reuse value.
• Policy checks on attestation metadata so the build is rejected if the expected repo, branch, runner, or signer does not match policy.
• Independent review of dependencies and actions, especially where third-party automation can inherit broad access.

This is why provenance is best treated as one signal inside a broader trust model, not a final verdict. NHIMG’s analysis of the Mastra npm Supply Chain Attack shows how quickly malicious packages can move through trusted delivery paths once an attacker gains a foothold. The same issue is reflected in NHI guidance and in the Anthropic report on an AI-orchestrated cyber espionage campaign, where automation amplified attack speed and reach.

These controls tend to break down when CI/CD runners, maintainer accounts, or workflow secrets are reused across projects because the provenance record can remain valid even after the trust boundary has already been violated.

Common Variations and Edge Cases

Tighter attestation requirements often increase build overhead and operational friction, so organisations have to balance stronger assurance against developer velocity. Best practice is evolving here, and there is no universal standard for how much provenance is enough on its own.

One common edge case is the “trusted workflow, untrusted input” problem. A repository may have a signed, attested build, yet still consume a compromised dependency, a poisoned test fixture, or a malicious codegen output. Another is fork-based contribution models, where the attestation may be real but the triggering context is not equivalent to a maintainer-approved release. Teams also need to account for identity drift in automation: when build systems, bots, or release agents hold long-lived credentials, a valid attestation may simply prove that a compromised identity successfully completed the pipeline.

For that reason, security teams should pair provenance with source review, protected release paths, workload identity controls, and runtime policy enforcement. NHIMG’s State of Secrets Sprawl 2026 research reinforces how often exposure persists after detection, which makes post-build trust checks insufficient on their own. In mature environments, provenance is a verification layer, not the trust anchor. In high-churn CI/CD systems with many third-party actions and reused runners, that distinction becomes operationally critical.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why do signed releases not eliminate supply-chain risk after maintainer compromise?
• What fails when package provenance is trusted too much in a supply chain compromise?
• Why do developer workstations increase the blast radius of supply-chain malware?