Why is a signed artifact not enough to prove software trust?

Why a signature is only one piece of software trust

A signature can tell you that a key was used to assert authorship or approval, but it does not by itself tell you whether the software was produced by the intended build process, from the intended source, or under the intended controls. Trust in software depends on more than cryptographic authenticity. It also depends on provenance, reproducibility, policy enforcement, and the ability to detect whether the signing path itself was compromised.

The practical problem is that “signed” often gets mistaken for “trusted.” Those are not the same thing. A valid signature may confirm integrity after signing, yet a malicious or tampered build can still be signed if the attacker gains access to the signing identity, abuses an approved workflow, or injects code before the signing step. That is why provenance and enforcement matter as much as the signature itself.

What a signature proves, and what it does not

A signature is a verification mechanism, not a complete trust model. It proves that the artifact has not changed since signing and that the signing key was available to produce the signature. It does not prove the artifact was built from clean inputs, reviewed correctly, or assembled in a trusted environment. In other words, the signature answers “who signed this artifact?” more than “why should I trust this artifact?”

That distinction matters because software supply-chain trust is about the whole path from source code to released binary. If the build pipeline, dependency chain, or signing workflow is compromised, the resulting artifact can still be signed and still be harmful. This is why supply-chain controls focus on provenance, builder identity, build isolation, attestation, and policy checks alongside signature validation.

Why provenance and enforcement change the trust decision

Provenance shows where the artifact came from, how it was built, and which inputs were used. Enforcement makes sure only artifacts that satisfy those conditions are allowed into production. Together, they turn a signature from a simple integrity marker into part of a verifiable trust chain. Without them, you have authentication of an artifact, but not trustworthy origin or trustworthy construction.

In practice, this means teams should treat signing as a release control, not a substitute for build assurance. A signer can be legitimate while the release process is still unsafe. If a compromised CI runner, stolen signing credential, or abused release workflow can produce a signed package, the signature becomes evidence of access, not evidence of safety. That is why signed artifact should be checked against provenance metadata and release policy, not admitted on signature alone.

For a concrete supply-chain standard, SLSA is built around this exact gap: it requires stronger assurances about how the artifact was built, not just whether it was signed.

Risk and Threat Considerations

Signed artifacts create a false sense of security when organisations stop at signature validation. The main risk is that an attacker does not need to break the signature algorithm, only the signing path, build workflow, or release permissions. Once that path is compromised, the attacker can ship malicious software that appears legitimate to downstream systems and operators.

Failure mechanism: A valid signing key, approved release workflow, or trusted build environment is abused to sign an artifact that was not produced under the expected controls, so downstream consumers accept malicious code as authentic.

Impact: The result can be supply-chain compromise, broad downstream deployment of malicious software, delayed detection, and loss of confidence in the release pipeline, especially when signature checks are used as the sole admission control.

Practitioner Guidance

What to verify: Verify that your trust decision includes the source, build, and signing path, not just the signature. A good rule is that a signed artifact should be accompanied by provenance that identifies what was built, by which workflow, from which inputs, and under what policy.

Decision rule: If an artifact is signed but lacks trusted provenance or policy enforcement, treat it as untrusted for production use. Signature validation alone is acceptable only for low-consequence verification, not for release approval.

What good looks like: The build system can produce attestations that are checked automatically, the signing step is tightly controlled, and deployment policy rejects artifacts that do not match the expected pipeline and source lineage.

Practitioner takeaway: A signature should confirm that an artifact was approved by a trusted key, but production trust should come from the combination of provenance, enforced release policy, and protection of the signing path.

Related resources from NHI Mgmt Group

• What breaks when organisations trust signed software updates and endpoint tools without enough control?
• How should security teams prove continuous software security over a product’s lifecycle?
• How do security teams know if an MCP artifact is trustworthy enough to admit?
• Should teams rely on signature validation alone for artifact trust?