Quantum-resistant signing on AWS, Part 1: Build a software supply chain with ML

Adoption of Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is being implemented on AWS to secure the software supply chain against future quantum computing threats. This involves integrating ML-DSA keys in AWS KMS, certificate hierarchies via AWS Private Certificate Authority, and workload identity through IAM Roles Anywhere to establish an end-to-end signing architecture for artifacts like binaries, container images, and Software Bills of Materials (SBOMs). The initiative is driven by converging regulatory deadlines, such as CNSA 2.0 and the EU Cyber Resilience Act (CRA), which mandate quantum-resistant signatures for software integrity.
The architecture is built on five trust pillars: ML-DSA key management in KMS, a public key infrastructure in AWS Private CA, quantum-resistant workload identity via IAM Roles Anywhere, artifact signing, and SBOM integrity attestation. The process involves establishing a root of trust, issuing certificates to build agents, signing artifacts using the established hierarchy, and implementing verification controls. The signing process for large artifacts is handled by external computation of message representatives (mu) with OpenSSL before calling KMS, while SBOMs are bound to artifacts using in-toto Statements. Workload identity for external build agents leverages ML-DSA certificates via IAM Roles Anywhere, replacing classical signature dependencies.

* CNSA 2.0 requires US National Security Systems (NSS) to support and prefer quantum-resistant signatures for software and firmware, with exclusive use mandated by 2030.
* The EU Cyber Resilience Act (CRA) takes full effect in December 2027, requiring verifiable software integrity throughout a product’s lifecycle.
* AWS provides services like KMS, Private CA, and IAM Roles Anywhere to construct an ML-DSA signing architecture.
* The architecture involves five trust pillars: AWS KMS for key management, AWS Private CA for PKI, Quantum-resistant workload identity via IAM Roles Anywhere, artifact signing, and SBOM integrity attestation.
* ML-DSA is designed to resist attacks from both classical and quantum computers.
* Artifacts are signed using ML-DSA keys managed in HSMs within AWS KMS.
* Build agents authenticate via IAM Roles Anywhere using ML-DSA certificates.
* SBOMs are protected by wrapping the inventory in an in-toto Statement, which is then signed with the code-signing key.
* Artifact signing for large files often uses the EXTERNALMU method or RAW content submission to AWS KMS.
* The process requires setting up a CA hierarchy (ML-DSA-87 root and ML-DSA-65 subordinate) in AWS Private CA.

The narrative pivots on shifting the threat from data confidentiality (harvest now, decrypt later) to software integrity (forge later). The focus is not merely implementing a new cryptographic primitive but establishing a complete, verifiable chain of trust across an entire development lifecycle. This moves security enforcement upstream, demanding that ephemeral build agents also adopt quantum-resistant identity mechanisms via IAM Roles Anywhere.
The pattern observed is the necessity of bridging high-level policy mandates (CNSA 2.0, CRA) with low-level cryptographic implementation details (ML-DSA parameters like ML-DSA-87/65). The implication is that achieving resilience requires layered controls: strong cryptography for the signatures themselves, robust PKI management to establish trust boundaries, and strict enforcement mechanisms (like SCPs mentioned in Part 2) to prevent deviation from the quantum-resistant standard.
The mechanism for signing SBOMs via in-toto Statements demonstrates a pattern of binding artifact metadata directly into the cryptographic proof, moving beyond simple file integrity checks. The risk lies in the complexity of managing this chain—the potential for configuration drift in trust stores or failure to implement verification correctly introduces new systemic vulnerabilities that are harder to detect than simple signature forgery. A critical question is whether the investment in this complex infrastructure will be sufficient to overcome human and organizational inertia in maintaining the rigor of the signing pipeline, especially given the complexity introduced by managing disparate trust stores across environments. What mechanisms exist to ensure the integrity of the certificate revocation processes when dealing with these extended lifetimes?