Code Signing & Supply Chain Security
Protect software distribution — from classical code signing to post-quantum ML-DSA package integrity.
Why this matters: A forged signature on a software update is a supply-chain compromise at scale — code signing is one of the few PQC migrations where the attacker doesn't need to break today's crypto, just tomorrow's.
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 harvest-now-decrypt-later 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 software supply chains. 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 Shor's algorithm 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 harvest-now-decrypt-later threat applied to code integrity.
A quantum-compromised Root CA 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 ECDSA or RSA 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 build provenance to signature verification to certificate chain management.
Classical vs PQC Code Signing
Classical code signing relies on RSA and ECDSA, both of which are vulnerable to Shor's algorithm on a cryptographically relevant quantum computer. NIST has standardized ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) 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 Root CA 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 Time Stamping Authorities (TSAs) — 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 PQC signing uses OpenPGP v6 (RFC 9580, via Sequoia) with the RPM v6 package format.
Sigstore & Keyless Signing
Sigstore 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)
Ephemeral ECDSA P-256 keypair created (valid ~20 minutes); ML-DSA is a proposed future upgrade
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 Fulcio (CA) and Rekor (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 root of trust 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 CNSA 2.0 guidance mandates stateful hash-based signatures (LMS/HSS or XMSS) for firmware and software signing in National Security Systems — ahead of ML-DSA 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.
Products shown here are a representative selection — not an exhaustive list. For the full vendor landscape with PQC readiness status, visit the Tools & Products tab in this module or browse the Migrate catalog →
Check off all sections and mark this reading done.
Related modules
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.