What is the difference between code signing and code integrity checking?

Code signing is the act of attaching a digital signature that proves who published the software and that it has not changed since signing. Code integrity checking is the verification step performed by the recipient to confirm the signature and detect tampering. One creates trust, the other validates it before execution or distribution.

How code signing and code integrity checking differ

code signing is the publisher’s act. A signing key is used to attach a digital signature to software, giving recipients a way to verify origin and confirm the package has not changed since it was signed. code integrity checking is the receiver’s act. It verifies that signature, or another integrity signal, before trust is granted for execution, update, or distribution.

The difference matters because the two steps answer different questions. Signing says, “this software was issued by a party that controls the signing key.” Integrity checking says, “this copy still matches what was signed, and I am willing to trust it now.” In practice, code signing creates an evidence trail; integrity checking enforces the policy at install time, load time, or release time.

That separation is why signed software can still be blocked, and why unsigned software can still be checked for tampering through other mechanisms. Signature presence alone does not guarantee safety, and integrity verification alone does not prove authorship unless the trust chain points to a trusted signer. Machine Identity, PKI and Certificate Lifecycle Guide is a useful companion when you need the certificate and key-management context behind signing.

Where trust is created, and where it is tested

Code signing belongs to the supply-side of the trust relationship. The developer, build system, or release pipeline uses a private signing key to bind identity to a binary, package, script, driver, or container artifact. That signature is useful only if the signing key is protected and the certificate chain is trusted by the verifier.

Code integrity checking belongs to the consume-side. A loader, package manager, device policy, operating system, or deployment gate checks whether the artifact is authentic and unchanged. The check may happen before execution, after download, during update validation, or continuously at runtime depending on the platform and control objective. SLSA is relevant here because build provenance and artifact integrity are often the broader control goal behind signing and verification.

In other words, signing answers “who vouches for this artifact?”, while integrity checking answers “should this environment accept it right now?” Those are complementary controls, not substitutes.

Signed software can still be dangerous if the signer is compromised, the build pipeline is poisoned, or the artifact is signed after malicious changes. Integrity checking can still fail if the verifier trusts the wrong root, ignores revocation, or accepts an outdated signature policy. SolarWinds supply chain compromise is a clear reminder that a trusted build path can be abused even when downstream trust signals look legitimate.

Why practitioners should treat them as separate controls

Operationally, the distinction helps teams place the right control at the right point in the lifecycle. Signing is about issuance discipline, key protection, and provenance. Integrity checking is about enforcement, admission control, and tamper detection. If you blur them together, it becomes easy to assume that a signed artifact is automatically safe to deploy, or that a checksum alone gives the same assurance as a verified signature.

For software delivery teams, the practical question is whether the verifier can reliably reject altered or untrusted artifacts without breaking legitimate updates. For security teams, the practical question is whether the signing key, certificate chain, revocation path, and verification policy are all aligned. Cryptographic Key Management Guide is the right internal reference when the control issue is not the signature itself but the lifecycle of the signing keys behind it.

At scale, the biggest failure mode is over-trust. Organisations often sign too many artifacts, protect signing keys inconsistently, or skip verification because it is inconvenient in build and deployment flows. The result is that code signing becomes a branding exercise instead of a control, while integrity checking becomes a checkbox instead of an enforcement step.

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 CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	Artifact provenance and integrity are central to the signing-versus-verification distinction.
Recommendation — Adopt SLSA-aligned provenance checks to verify build origin and artifact integrity before release.
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	Integrity checking is an explicit control concern for detecting tampering before use.
	SC-12 — Cryptographic Key Establishment and Management	Code signing depends on protecting the keys that create trusted signatures.
Recommendation — Implement integrity verification gates that block altered software from execution or deployment. Protect signing keys with strong lifecycle controls and restricted administrative access.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Code signing relies on cryptographic mechanisms to bind origin and integrity to software.
Recommendation — Define cryptographic signing rules and verify that signed artifacts are accepted only under approved policy.
CIS Controls v8	CIS-16 — Application Software Security	Software integrity checks and signed-build practices fit application security hardening.
Recommendation — Require integrity validation in build and deployment pipelines for all software releases.

Practitioner Guidance

What to verify: Confirm that the verifier checks the full chain of trust, not just that a signature exists. The useful question is whether the artifact is both signed by a trusted source and still identical to the signed version at the point of use.

Decision rule: If the workflow accepts software from outside the immediate build step, require integrity verification before execution or release. If the signing key is exposed or the build system is suspect, treat the signature as potentially compromised and escalate to provenance review.

What good looks like: Signed artifacts are produced from controlled build pipelines, verification is enforced automatically, and failures block deployment rather than generating warnings that teams can ignore. The control should be visible in release logs and reproducible in incident response.

Practitioner takeaway: Code signing establishes trust at creation, but code integrity checking decides whether that trust is still deserved when the software is actually used.