Code Signing & Supply Chain Security
Protect software distribution — from classical code signing to post-quantum ML-DSA package integrity.
Why Code Signing Matters
Code signing is the cryptographic mechanism that guarantees software integrity and publisher authenticity. Every operating system, package manager, and app store relies on digital signatures to ensure that binaries have not been tampered with after publication.
“A compromised signing key is a skeleton key to every machine that trusts it.”
— Lessons from the SolarWinds supply chain attack (2020)
Attackers injected malicious code into the Orion build pipeline. The trojanized update was signed with a legitimate certificate and deployed to ~18,000 organizations.
A cascading supply chain attack: a compromised upstream dependency led to trojanized 3CX desktop clients signed with valid certificates.
Attackers modified a CI/CD script without signature verification, exfiltrating environment variables from thousands of CI pipelines.
These attacks exploited trust in code signing infrastructure. Post-quantum code signing must protect not only against today's threats but also against attacks where adversaries collect signed artifacts to forge signatures once quantum computers become available.
Supply Chain Risk & the Quantum Amplifier
The attacks above are symptoms of deeper structural problems in modern . As software composition grows more complex, the attack surface expands — and quantum computing threatens to break the cryptographic foundations that hold it together.
The average enterprise application pulls in 200–500 transitive dependencies. Each dependency is a link in the trust chain — and each link is only as strong as its maintainer’s signing practices.
You audit your direct dependencies, but do you audit their dependencies? A malicious package five levels deep in the dependency tree can execute arbitrary code in your application. The 3CX attack exploited exactly this pattern.
Build systems, artifact registries, and deployment pipelines are high-value targets. The Codecov bash uploader attack demonstrates that unsigned CI scripts can be silently replaced. Every step from source code to deployed binary is an attack surface.
An SBOM documents what goes into a build, but build provenance answers how it was built and who built it. Without cryptographically signed provenance, an attacker can substitute a tampered artifact that passes all hash checks.
Frameworks like SLSA and in-toto provide structured approaches to supply chain verification — defining security levels based on how much of the build pipeline is cryptographically attested. Their guarantees depend entirely on the strength of the underlying signatures.
“Today, a supply chain attacker must steal a signing key. Tomorrow, a quantum-capable adversary can forge any signature without stealing anything.”
Today's supply chain attacks require compromising a specific publisher's signing key. A quantum attacker running could derive any publisher's private key from their public certificate — no infiltration, no social engineering, no insider threat required.
Adversaries can harvest signed binaries and code signing certificates today. Once quantum computers arrive, they could forge new signatures that chain to existing certificates, or create fake artifacts that appear legitimately signed by any publisher. This is the threat applied to code integrity.
A quantum-compromised key would let an attacker sign software as any publisher in that CA's trust hierarchy. Unlike a stolen intermediate key (scoped to one publisher), breaking the Root CA's algorithm affects the entire ecosystem simultaneously.
A stolen signing key compromises one publisher. A quantum break of or compromises every publisher simultaneously — every code signing certificate using that algorithm becomes forgeable. This is a systemic, not isolated, risk.
SCADA controllers, medical devices, avionics, and industrial infrastructure deployed today with classical signatures will still be operating 15–25 years from now. These systems cannot be easily patched and will be running in a post-quantum threat environment. Their classical signatures will offer zero protection against firmware forgery.
This is why PQC migration for code signing is not just about upgrading algorithms — it requires rethinking the entire supply chain trust model, from to signature verification to certificate chain management.
Classical vs PQC Code Signing
Classical code signing relies on and , both of which are vulnerable to on a cryptographically relevant quantum computer. has standardized () and () as PQC replacements for digital signatures.
| Algorithm | Public Key (bytes) | Signature (bytes) | Quantum Safe |
|---|---|---|---|
| RSA-2048 | 256 | 256 | No |
| RSA-4096 | 512 | 512 | No |
| ECDSA P-256 | 64 | 64 | No |
| Ed25519 | 32 | 64 | No |
| Ed448 | 57 | 114 | No |
| ML-DSA-44 | 1,312 | 2,420 | Yes |
| ML-DSA-65 | 1,952 | 3,309 | Yes |
| ML-DSA-87 | 2,592 | 4,627 | Yes |
| SLH-DSA-SHA2-128s | 32 | 7,856 | Yes |
PQC signatures are 38–123x larger than ECDSA. For code signing this is acceptable — signatures are verified once per install, and bandwidth is not the primary constraint.
Code Signing Certificate Chains
Code signing certificates form a trust chain from a down to the signing certificate. The chain establishes that a trusted authority vouches for the identity of the software publisher.
Self-signed trust anchor. Installed in OS/browser trust stores. Uses strongest algorithm (ML-DSA-87).
Signed by Root. Issues end-entity certificates. Uses ML-DSA-65 for balance of security and size.
End-entity cert with Extended Key Usage: Code Signing (OID 1.3.6.1.5.5.7.3.3). Short validity (1 year). Uses ML-DSA-44.
Code signing certificates expire, but signed software must remain valid long after. Timestamping (RFC 3161) proves the signature was created while the certificate was still valid. PQC timestamping requires PQC-capable — a critical dependency for migration.
Package Manager Signing
Every major package manager uses code signing to verify package authenticity. Migration to PQC varies widely — RPM is leading with hybrid ML-DSA-87+Ed448 support in RHEL 10, while most others rely on upstream Sigstore PQC adoption.
| Package Manager | Current Signing | PQC Status |
|---|---|---|
| RPM (Red Hat) | RSA/SHA-256 | ML-DSA-87+Ed448 hybrid (RHEL 10) |
| APK (Alpine) | RSA-2048 | No PQC roadmap |
| dpkg (Debian) | RSA/SHA-256 | ML-DSA planned (Debian 14) |
| npm | ECDSA P-256 (Sigstore) | Via Sigstore PQC |
| PyPI | ECDSA P-256 (Sigstore) | Via Sigstore PQC |
| Maven Central | RSA/SHA-256 | No PQC roadmap |
Hybrid signing (also called composite signing) attaches both a classical and PQC signature to the same artifact. This provides backward compatibility — older tools verify the classical signature, while PQC-aware tools verify both. Red Hat's RPM implementation uses ML-DSA-87+Ed448 composite signatures per the IETF composite signatures draft.
Sigstore & Keyless Signing
is an open-source project that eliminates the need for long-term signing key management. Instead of distributing and protecting private keys, developers authenticate with their existing identity (GitHub, Google) and receive short-lived certificates. All signatures are recorded in a public transparency log.
Developer authenticates via OIDC (GitHub, Google, Microsoft)
Short-lived ML-DSA-65 keypair created (valid ~20 minutes)
Fulcio CA issues X.509 cert binding identity to ephemeral public key
Artifact hash signed with ephemeral private key
Signature + cert recorded in Rekor transparency log (immutable append-only)
Ephemeral private key destroyed — no long-term key management needed
Verifier checks Rekor log entry, cert chain, and signature — no keys to distribute
No long-term private keys to manage, rotate, or protect. Identity-based trust replaces key-based trust. This dramatically simplifies PQC migration — only the Sigstore infrastructure needs to upgrade, not every individual developer.
Sigstore's architecture centralizes cryptographic operations in (CA) and (transparency log). Upgrading these two services to ML-DSA automatically provides PQC protection to all downstream consumers (npm, PyPI, etc.).
Secure Boot & Firmware Signing
Every platform depends on a chain of trust that starts at an immutable and extends through bootloaders, the OS kernel, and runtime firmware. Each link in the chain verifies a cryptographic signature before passing execution to the next stage. If any signature fails, the boot process halts.
Firmware signing is a critical PQC migration target because firmware keys have 10–20 year lifetimes, and devices deployed today will still be in the field when cryptographically relevant quantum computers arrive. An attacker who harvests firmware update signatures today could forge malicious firmware updates in the future.
Immutable hardware anchor. Public key burned into OTP fuses or stored in TPM NVRAM. If compromised, the entire chain collapses.
UEFI firmware verifies the bootloader signature against keys in the Secure Boot database before allowing execution.
Kernel signature verified. Signed drivers loaded into protected memory. Measured boot extends TPM PCR registers for remote attestation.
Device firmware verified before execution. Over-the-air updates require re-verification against the trust chain before flashing.
The NSA's guidance mandates stateful hash-based signatures ( or ) for firmware and software signing in National Security Systems — ahead of for general use.
Compact signatures (2.5 KB) and tiny public keys (56 bytes) — ideal for hardware-constrained boot ROM. Fast verification (~0.1 ms). CNSA 2.0 compliant. Security derives solely from hash functions (minimal cryptographic assumptions). Trade-off: requires a monotonic state counter managed in an HSM or TPM.
Fully stateless — no counter, no state management burden. Simpler operations for environments where maintaining state is impractical (distributed build systems, CI/CD pipelines). Trade-off: larger signatures (3.3 KB) and public keys (1.9 KB). Not mandated by CNSA 2.0 for firmware signing.
For a deep dive into LMS/XMSS parameter selection, Merkle tree mechanics, and the state management challenge, see the Stateful Hash Signatures module.
Related Resources
Sign binaries, build certificate chains, explore Sigstore keyless signing, and verify secure boot trust chains.