For the past few years, the cybersecurity industry has rallied around a singular message: we need verifiable proof of where our software comes from. Driven by regulatory pressure and high-profile breaches, frameworks like SLSA (Supply-chain Levels for Software Artifacts) and tools like Sigstore have become the gold standard. We demand SBOMs, we mandate build provenance, and we cryptographically sign our artifacts.
But as we reach peak attestation adoption in 2026, a new, more insidious threat has emerged. Attackers are no longer just trying to sneak malicious code into your repository—they are actively forging the cryptographic proofs that tell you the code is safe.
Welcome to the era of forged software attestations.
The Evolution of the Supply Chain Attack
Historically, software supply chain attacks relied on exploiting the gap between source code and the final artifact. Attackers would compromise a build server, inject malicious code during compilation, and let the pipeline package it up.
To combat this, the industry introduced build provenance—cryptographically signed metadata detailing exactly how an artifact was built, what dependencies were used, and which CI/CD runner executed the job. If the signature checks out, the artifact is trusted.
However, attackers have adapted. If security gates now automatically reject unsigned code, the logical next step is to steal the pen.
How Attestation Forgery Works
Forging an attestation doesn't mean breaking the underlying cryptography (like ECDSA or RSA). Instead, attackers target the identity and infrastructure used to generate the signatures. Here are the three primary vectors we are seeing in the wild:
1. Workload Identity Theft (OIDC Hijacking)
Modern keyless signing relies on OpenID Connect (OIDC) tokens. A CI/CD runner requests an ephemeral token from a provider (like GitHub Actions or GitLab CI), exchanges it for a short-lived signing certificate, signs the artifact, and discards the key. If an attacker achieves Remote Code Execution (RCE) on a runner, they can intercept that OIDC token before it expires and use it to sign a completely different, malicious artifact. To the verification engine, the fake artifact appears to have been legitimately built by your pipeline.
A compromised workload identity allows an attacker to masquerade as a legitimate build process, generating valid-looking Sigstore attestations for malicious software.
2. Provenance Replay Attacks
In a replay attack, a threat actor takes a valid, signed attestation from a legitimate older build and attaches it to a newly compromised artifact. If the verification policies are misconfigured—checking only that the signature is valid and the issuer is trusted, but failing to strictly match the artifact's cryptographic hash (SHA-256) to the attestation subject—the malicious payload slips through.
3. Compromised Build Environments
Attestations prove where and how software was built, but they don't inherently prove the build environment itself wasn't tampered with. If an attacker compromises the build script or a base image used in the pipeline, the resulting artifact will contain malware, but the CI/CD runner will dutifully (and legitimately) sign the malicious output. The attestation is technically valid, but it guarantees the integrity of a poisoned well.
Defending the Cryptographic Truth
As attackers shift their focus from the code to the metadata, security teams must evolve their supply chain defenses. Relying on the mere presence of a signature is no longer enough.
- Enforce Strict Artifact-to-Attestation Binding: Your admission controllers (like Kyverno or OPA Gatekeeper) must be configured to rigidly verify that the hash of the deployed artifact perfectly matches the
subject.digestin the in-toto attestation. - Scope OIDC Tokens Ruthlessly: Limit the audience and permissions of workload identity tokens. Ensure tokens are bound to specific workflows, branches, and environments to minimize the blast radius if a token is intercepted.
- Implement Build Isolation: SLSA Level 3+ requires that builds are isolated. Ensure your CI/CD runners are ephemeral, single-use VMs (not shared containers) to prevent cross-run contamination and token theft.
- Verify the Content, Not Just the Wrapper: An attestation is a wrapper. It must be paired with continuous vulnerability scanning and static analysis. A mathematically verified signature on a vulnerable package is still a vulnerable package.
The Bottom Line
Software attestations are a massive leap forward for supply chain security, but they are not a silver bullet. As we navigate the threat landscape of 2026, we must remember that a signature is only as trustworthy as the environment that generated it. Trust the math, but relentlessly verify the infrastructure behind it.