What is Code Signing

Code signing is the process of applying a digital signature to software (executables, libraries, scripts, packages, firmware, containers) to prove two things: the software was published by a known entity (authenticity), and it hasn’t been modified since signing (integrity). Operating systems, package managers, and security tools check these signatures before allowing software to run, install, or update. Without a valid signature, Windows shows SmartScreen warnings, macOS blocks execution, and enterprise policies reject the software entirely.

Why it matters

• Trust decision — operating systems use code signatures to decide whether software is trustworthy. Unsigned software triggers warnings or is blocked outright (macOS Gatekeeper, Windows SmartScreen, Android app signing).
• Tamper detection — if a single byte of the signed software is modified (malware injection, supply chain attack, corruption), the signature becomes invalid. The modification is detectable before execution.
• Publisher accountability — the signature ties software to a specific publisher’s identity (verified by a CA). If malware is signed, the certificate can be revoked and the publisher identified.
• Update integrity — software update mechanisms verify that updates are signed by the same publisher as the original installation. Prevents attackers from pushing malicious updates.
• Supply chain defense — in a world of dependencies and build pipelines, code signing at each stage creates a verifiable chain from source code to deployed artifact.

How it works

1. Publisher obtains code signing certificate — applies to a CA (DigiCert, Sectigo, etc.) with identity verification (organization validation for standard, extended validation for EV).
2. Software is built — the final artifact (executable, package, container image) is produced by the build system.
3. Hash computed — a cryptographic hash (SHA-256) of the software is calculated.
4. Hash signed — the hash is encrypted with the publisher’s private key, producing the digital signature.
5. Signature attached — the signature and the signing certificate (with chain) are embedded in or attached to the software.
6. Timestamp applied — a trusted timestamp authority signs the signature with a timestamp, proving when the signing occurred.
7. Verification — when a user runs the software, the OS/runtime verifies: signature is valid, certificate chains to a trusted root, certificate was valid at signing time (via timestamp), and certificate isn’t revoked.

In real systems

Windows Authenticode:

# Sign an executable
signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 ^
  /f code-signing.pfx /p password MyApp.exe

# Verify signature
signtool verify /pa /v MyApp.exe

macOS code signing:

# Sign an application bundle
codesign --sign "Developer ID Application: My Company (TEAMID)" \
  --timestamp --options runtime MyApp.app

# Verify
codesign --verify --deep --strict MyApp.app

# Notarize (Apple's additional verification)
xcrun notarytool submit MyApp.zip --apple-id dev@example.com --wait

Java JAR signing:

# Sign a JAR file
jarsigner -keystore keystore.jks -tsa http://timestamp.digicert.com \
  -digestalg SHA-256 -sigalg SHA256withRSA myapp.jar "myalias"

# Verify
jarsigner -verify -verbose myapp.jar

Linux package signing (RPM/DEB):

# Sign RPM package
rpm --addsign mypackage.rpm

# Sign DEB package
dpkg-sig --sign builder mypackage.deb

# Users verify via GPG key trust (added to apt/yum keyring)

Where it breaks

Signing key compromise — an attacker obtains the code signing private key (stolen from build server, leaked from developer machine, extracted from poorly secured HSM). They can now sign malware that appears to come from the legitimate publisher. The certificate must be revoked immediately, but software signed before revocation remains “valid” unless the timestamp is checked against revocation date. This happened to SolarWinds (2020), ASUS (2019), and numerous others.

No timestamp — software is signed without a timestamp. When the signing certificate expires (1-3 years), the signature becomes unverifiable. Users see “signature expired” warnings and can’t install the software. With a timestamp, the signature remains valid forever (it proves the signing happened while the certificate was valid). Always timestamp. There’s no reason not to — timestamp services are free.

Signing too early in the pipeline — software is signed, then a post-signing step modifies the artifact (adds metadata, repackages, compresses differently). The signature is now invalid because the content changed after signing. Code signing must be the absolute last step before distribution — nothing can touch the artifact afterward.

Operational insight

The highest-value attack in software supply chains isn’t exploiting a vulnerability — it’s compromising a code signing key. A vulnerability affects one version of one product. A compromised signing key lets attackers sign unlimited malware that passes all trust checks on every customer’s system. This is why code signing keys should be stored in HSMs (FIPS 140-2 Level 3), accessed only by the build pipeline (not individual developers), and protected with multi-person authorization for any signing operation. The signing key is more valuable than the source code — treat it accordingly.

Related topics

• Code Signing Certificates
• Code Signing in CI/CD Pipelines
• Digital Signatures
• Software Supply Chain Security
• What are Hardware Security Modules