What is the difference between release signing and source-code integrity?

Why Release Signing and Source-Code Integrity Solve Different Problems

Release signing answers a question about approval and authenticity at the point of shipment. It tells a consumer, build pipeline, or updater that the artefact came from an authorised release process and has not been altered after signing. Source-code integrity answers a different question: whether the code base remained trustworthy before that release existed at all.

The distinction matters because a signature can only attest to the state of the object being signed. If the build input, repository, dependency, or maintainer account was compromised earlier, the signature may still be perfectly valid while the shipped content is already hostile. That is why provenance and release assurance are complementary controls, not interchangeable ones.

For software supply chain context, SLSA is the clearest external reference point because it separates build provenance and integrity from the act of signing a released artefact. In practice, teams should think in layers: protect the source, protect the build path, then sign the output.

Where Integrity Breaks Before Signing Ever Happens

Source-code integrity fails when an attacker or insider changes the code, build scripts, dependencies, or release metadata upstream and that change is accepted as legitimate. The release may then be signed exactly as intended by the compromised process, which is why downstream verification alone cannot detect every problem. The earlier the tampering occurs, the broader the blast radius.

This is especially visible in repository compromise, malicious commits, credential theft, and maintainer takeover scenarios. PHP Git server compromise 2021 is a useful example of how stolen credentials can turn source control into an attack vector, while XZ Utils backdoor 2024 shows how a trusted maintainer path can be abused before any release artefact is ever verified by consumers.

Teams that only validate release signatures can miss upstream contamination entirely. The right mental model is “what was signed” versus “what was allowed into the signed release in the first place.”

Why Both Controls Matter in a Modern Supply Chain

Release signing gives downstream users a tamper-evident checkpoint at distribution time. Source-code integrity gives upstream builders confidence that the release content still reflects approved, reviewed, and traceable inputs. One control protects consumers from post-release modification, the other protects producers from shipping compromised content with a legitimate signature.

That is why strong programmes pair commit controls, branch protection, review discipline, dependency governance, and build attestation with signing keys and certificate protection. NVIDIA code-signing certificates stolen 2022 illustrates a different but related failure mode: if signing material is stolen, attackers can produce artefacts that look trusted even when the release process itself was bypassed.

In other words, signing without upstream integrity creates false confidence, and integrity without release signing leaves consumers without a trustworthy distribution signal. Mature release engineering treats both as necessary and verifies them independently.

Risk and Threat Considerations

The main risk is assuming that a valid signature means the software was safe to build, review, or deploy. Attackers target the weakest point in the lifecycle, often upstream of signing, because poisoning source, dependencies, or maintainer access can turn later trust mechanisms into a shield for malicious code.

Failure mechanism: An adversary alters source or build inputs before the release is signed, or steals signing material so malicious output can be signed as trusted. The result is a release that passes authenticity checks while still carrying malicious or unauthorised changes.

Impact: Consumers may deploy compromised software with high confidence, incident response becomes harder because the artefact appears legitimate, and revocation or rebuild efforts may arrive too late to prevent downstream exposure.

Practitioner Guidance

What to verify: Confirm that your release process can prove two separate facts, the source history was protected before build time, and the released artefact was signed by an authorised key at publication time. If either proof is missing, do not treat the software as fully trustworthy.

Decision rule: If a control only proves the artefact was signed, treat it as release assurance, not source integrity. If a control only proves the repository or build inputs were clean, treat it as upstream integrity, not distribution trust.

What good looks like: Protected branches, enforced review, immutable build inputs, and tightly controlled signing keys work together so that a valid signature is the final checkpoint, not the only checkpoint. The practical objective is to make upstream tampering difficult and downstream forgery detectable.

Practitioner takeaway: Never use release signing as a substitute for source integrity, because the strongest signature in the world cannot redeem a compromised upstream lifecycle.

Related resources from NHI Mgmt Group

• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between scanning Flutter source code and scanning Flutter release bundles?
• What is the difference between code signing and code integrity checking?
• What is the difference between privilege reduction and secret rotation?