AWS guide details quantum-resistant software supply-chain signing with ML-DSA

Oct 12, 2026 · Original article ↗

Summary

AWS explains how to build an ML-DSA signing pipeline using KMS, Private CA and IAM Roles Anywhere, covering binaries, container images and SBOMs, with deployment verification and algorithm-policy controls.

Key points

The architecture combines HSM-protected AWS KMS signing keys, AWS Private CA certificate hierarchies and IAM Roles Anywhere authentication for external build agents.
For large artifacts, the guide computes a 64-byte ML-DSA message representative externally and submits it using EXTERNAL_MU, avoiding the KMS 4,096-byte message limit.
Signed in-toto Statements bind SBOMs to artifact digests; verification must check both the signature and the subject digest to prevent SBOM substitution.
Deployment verification checks certificate trust, code-signing purpose, expected signer and artifact signatures. Custom verification code is required for the demonstrated ML-DSA OCI referrer format.
Production recommendations include separate workload and code-signing CAs, hardware-backed agent keys, certificate revocation checks and protected trust stores; the walkthrough omits revocation checks.
An example service control policy blocks creation of non-ML-DSA signing keys, but additional controls are needed to restrict parameter sets and existing keys.
The examples use ML-DSA-65 for commercial code signing; the article states that CNSA 2.0 alignment requires ML-DSA-87 for all signing keys and certificates.

Article Details

Defense Focus: Protect software supply-chain integrity against potential future quantum signature forgery through ML-DSA artifact signing, workload authentication, deployment verification, and algorithm-policy enforcement.
Detection Methods: Verify the signing certificate chain, Code Signing extended key usage, expected signer subject, and artifact signature before deployment; stop on any failed check.
Verify signed in-toto SBOM Statements and compare their subject digest against the independently resolved image digest or computed binary digest.
Inspect container signature referrers and accept an image only when at least one signature verifies against a certificate chaining to the trusted store; do not depend on referrer ordering.
Query organization-wide signing audit logs and correlate signing principals and timestamps with deployment events.
Audit trust-store changes to detect unauthorized root certificate additions.
Check certificate revocation status using a distributed CRL or an OCSP responder.
Data Sources: kms:Sign and kms:Verify API audit events
Organization trail logs and deployment events
System-level trust-store audit logs
Artifact signatures, signing certificates, and trusted certificate chains
OCI signature referrers and signed SBOM attestations
Independently resolved image manifest digests and computed binary digests
Certificate revocation lists or OCSP responses
Certificate authority audit reports listing issued and revoked certificates
Rule Types: JSON service control policies restricting signing-key creation
JSON IAM trust and permissions policies
Shell-based certificate, signature, and digest validation checks
Kubernetes validating admission webhook checks
Gatekeeper constraints calling a custom external data provider
Defensive Actions: Generate and protect ML-DSA signing keys in HSMs, and establish a trusted root, subordinate CA, and code-signing certificate hierarchy.
Sign binaries, image manifest digests, and SBOM Statements; include the artifact digest inside the signed Statement to prevent SBOM substitution.
Use EXTERNAL_MU for variable-sized artifacts rather than relying on the 4,096-byte RAW input limit.
Protect artifacts and signatures with object locking or versioning and restricted write access.
Distribute trusted CA certificates to every verifier, restrict trust-store writes, and configure revocation checking in production.
Reject deployment when signatures are missing or invalid, signer identity or certificate purpose is unexpected, or the SBOM subject does not match the deployed artifact.
Use separate subordinate CAs for workload identity and code signing in production.
Restrict build-agent role assumption to the intended trust anchor and certificate subject, and grant signing permissions only on the required key.
Protect external build-agent private keys with hardware-backed storage or an encrypted credential store and use short-lived credentials.
Enforce approved ML-DSA parameter sets through layered policies; the example family-only guardrail does not exclude ML-DSA-44 or restrict existing keys.
For CNSA 2.0 alignment, use ML-DSA-87 for all signing keys and certificates rather than the commercial ML-DSA-65 examples.
Plan certificate renewal, re-signing, or trusted timestamping for artifacts that must remain verifiable beyond certificate expiry.
Create a retained organization audit trail with appropriate storage lifecycle policies and access controls; the 90-day event history is not a substitute.

Vendors

Amazon Web ServicesAmazon Web Services (AWS) provides the building blocks to construct a quantum-resistant software supply chain today using production-ready, generally available services.

Products

Amazon AthenaUse an organization trail and query its logs with Amazon Athena to analyze signing activity across accounts and correlate it with your deployment events.Amazon Elastic Container Registry (ECR)Signatures are stored alongside artifacts in Amazon Simple Storage Service (Amazon S3) or Amazon Elastic Container Registry (Amazon ECR).Amazon S3Signatures are stored alongside artifacts in Amazon Simple Storage Service (Amazon S3) or Amazon Elastic Container Registry (Amazon ECR).AWS CloudTrailRestrict write access to trust stores and audit changes through AWS CloudTrail or your system-level audit logs.AWS KMSto combine Module-Lattice-Based Digital Signature Algorithm (ML-DSA) keys in AWS Key Management Service (AWS KMS), ML-DSA certificate hierarchies in AWS Private Certificate Authority, and ML-DSA trust anchors in AWS AWS OrganizationsUse an AWS Organizations Service control policy (SCP) to block creation of traditional signing keys in security-critical accounts, forcing all new signing workloads to use ML-DSA:AWS Private CAAWS KMS, AWS Private CA, and AWS IAM Roles Anywhere all support ML-DSA, making it possible to address the forge-later threat across your supply chain today without additional tooling.IAM Roles AnywhereAWS KMS, AWS Private CA, and AWS IAM Roles Anywhere all support ML-DSA, making it possible to address the forge-later threat across your supply chain today without additional tooling.Kubernetesother half is giving the systems and people that deploy your artifacts, such as deployment pipelines, Kubernetes admission controllers, and engineers installing a package, a concrete way to verify those signatures

Tools

Amazon Inspector SBOM GeneratorAmazon Inspector SBOM Generator (Sbomgen), or another tool that produces a CycloneDX JSON SBOM, for the SBOM example.AWS CLIAWS Command Line Interface (AWS CLI) v2 configured with appropriate credentials.aws_signing_helperIAM Roles Anywhere credential helper (aws_signing_helper) v1.8.0 or later, the first release that supports ML-DSA keys and certificates, for workload authentication.jqjq, for constructing and parsing the in-toto Statements used for SBOM attestation and for parsing ORAS output.Open Policy Agent (OPA) Gatekeeperadmission webhook (see Dynamic Admission Control in the Kubernetes documentation), or use Open Policy Agent (OPA) Gatekeeper, an admission webhook that enforces policies evaluated by the OPA policy engine, and OpenSSLOpenSSL 3.5 or later (required for ML-DSA signature verification and mu computation).ORAS CLIORAS CLI v1.2 or later (for attaching Open Container Initiative (OCI) referrer artifacts to container images).