How to Integrate ML-DSA Code Signing Into CI/CD in 2026?

Your pipeline can produce an ML-DSA signature and still leave deployment clients unable to verify it: standardization does not establish support across your artifact tools and consumers.
Start with an isolated pipeline, test key handling and the complete signing-to-verification path, then expand only when the intended consumers pass compatibility checks.

This guide is for DevSecOps engineers responsible for software artifact signing, release engineers maintaining publishing infrastructure, and security leads planning a post-quantum migration.
Use it to define what you will sign, where trust begins and ends, and what must be true before a pilot can affect production.

Define the signing boundary before changing the pipeline

ML-DSA is the algorithm name used in NIST’s FIPS 204 standard. That answers which standardized signature scheme you may be implementing. It does not answer whether a particular package format, signing utility, registry, update service, or client can carry and verify that signature.

Write down the exact object your release process will sign. It might be a build artifact, an update package, a container-related object, or a signed statement about an artifact. These are not interchangeable. Signing a package file and signing a statement that refers to a package can create different verification requirements for downstream consumers.

Then map the trust boundary. Identify the component that requests a signature, the service or process that holds or accesses the private key, the release system that publishes the result, and every consumer that must verify it. Include the humans and automation accounts that can change those components. If the signing key is protected but an untrusted job can submit arbitrary content to the signer, the key boundary alone does not establish a trustworthy release.

Keep algorithm selection separate from encoding and packaging. NIST defines three ML-DSA parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87. The parameter-set name is part of the algorithm choice; the signature representation and the way your release system attaches it to an artifact remain separate integration decisions. Record all three in the design rather than writing “ML-DSA supported” as a single undifferentiated requirement. FIPS 204 is the authority for the standardized algorithm and its parameter sets.

Can ML-DSA sign software artifacts?

It can be used as a digital signature scheme, but that does not mean every software artifact format already has a standard place for an ML-DSA signature or every client can validate one. Treat the question as a stack of checks: the cryptographic implementation must expose the algorithm you intend to use; your chosen signature or envelope format must represent the result; and the artifact consumer must understand that representation and trust policy.

The distinction matters when choosing a format. DSSE’s project documentation describes an envelope approach for signing statements, while SLSA provenance documentation describes provenance as information about how an artifact was produced. Neither reference, by itself, proves that a specific client accepts an ML-DSA signature in your intended release flow. Confirm the exact combination of algorithm, envelope or package format, and verifier.

Prepare key ownership and permissions

Before editing pipeline definitions, agree on who owns key generation, storage, authorization, rotation, and revocation. The implementation details depend on your cryptographic library and key-management product. Follow the official documentation for the products you actually select; do not transplant commands or assumptions from an unrelated tool.

For a pilot, record the intended key lifecycle and the operational response to each failure. Decide who can authorize a signing request, who can change that authorization, and how you will prevent routine build logs or configuration files from exposing key material. If signing happens through a separate service or protected environment, document how the pipeline authenticates to it and which requests it will refuse.

The exact secret-handling steps are platform-specific. For workflows using GitHub Actions, consult the official documentation on secrets and check its current behavior against your runner and workflow design. That documentation is not a substitute for reviewing whether a secret is appropriate for your signing-key model. In particular, do not expose credentials in command output, debug traces, artifact bundles, or test logs.

Keep the pilot’s signing authority narrower than its build authority. A build job should not gain the ability to sign arbitrary input merely because it can compile the artifact.

For key custody, also distinguish “the runner can request a signature” from “the runner can read the private key.” Those permissions have different consequences. Choose the model that your selected products support, then test the intended restriction rather than assuming it works because a workflow completes.

Connect signing to build identity and release records

When you add a signing action, link the request to the identity of the build and to the exact artifact digest. A successful signing command alone does not establish which source revision, workflow, or output the signature represents. Your release record should let an investigator follow that chain without relying on a developer’s memory.

Build the pipeline so that the artifact is finalized before signing. If any later stage modifies the signed bytes, the signature should no longer validate; that is useful only if the pipeline makes the relationship clear and does not silently sign one file while publishing another. Capture the digest of the intended artifact, pass that same artifact to the signer, and record the result alongside release metadata.

Where you produce provenance, keep the statement and its signature conceptually distinct. SLSA’s provenance specification is a reference for describing artifact production. Check whether your implementation emits the fields your release process needs, and do not claim a provenance level or guarantee just because a signature is present. The metadata must be accurate, and the verifier must apply a policy that trusts the relevant signer and build identity.

During implementation, review each place where data can cross a boundary:

• Does the signing request include an unambiguous artifact digest?
• Can a job substitute a different file between digest calculation and signing?
• Does the release record identify the build and signer?
• Can operators distinguish a failed signature step from a missing signature?
• Do logs record useful audit details without disclosing private material or credentials?

Keep the integration fail-closed for the artifact class under test. If signing fails or the signature cannot be attached, do not silently publish the artifact as though the new control passed. If the organization needs an exception path, document its approver, scope, and audit record before the pilot begins.

Validate the signature and the receiving tools

Test the complete path with the cryptographic implementation, output format, storage location, and consumer that you plan to use. A library exposing ML-DSA does not prove that your package manager, registry, update client, or deployment agent can read the resulting signature. Confirm support in each project’s official documentation and version notes at the time you deploy.

For example, the OpenSSL 3.6 EVP signature documentation documents an ML-DSA signature interface for that library version. Treat that as evidence about the documented interface, not evidence that every build image or downstream application has the same capability. Pin and test the toolchain you actually ship, and record its version in the pilot results.

How do you test ML-DSA signing and verification in CI/CD?

Build test cases around expected outcomes, not only around a successful signing command. Run the cases in an isolated pipeline with test keys and non-production artifacts. Record the input digest, selected parameter set, implementation and version, format, signer identity, verifier result, and the client used for verification.

At minimum, include these cases:

• Valid artifact: Sign the intended artifact, then verify it with the same supported consumer that will handle a real release.
• Modified artifact: Change the signed bytes after signing. Verification should reject the modified object.
• Wrong key or trust identity: Present a signature that does not match the configured trust policy. The consumer should reject it rather than treating any syntactically valid signature as trusted.
• Wrong or missing metadata: Remove or alter the signature association, algorithm identifier, or required release information. Confirm that the client reports a useful failure.
• Unsupported consumer: Run the artifact through each relevant client and record whether it rejects the signature, ignores it, or fails before reaching verification.

Do not interpret “the verifier returned success” without checking what it verified. Confirm that the verifier consumed the intended artifact, used the intended trust material, and enforced the expected signer policy. A test that verifies a detached signature but never checks how the production client locates that signature leaves a gap in the release path.

Make the pilot a compatibility decision

Choose a non-critical artifact and a limited set of consumers for the pilot. Include the oldest supported client you still expect to encounter, as well as the deployment systems that sit between publication and installation. Confirm behavior in the real release route: storage, download, signature discovery, verification, and the final accept-or-reject decision.

Older clients may not understand the new algorithm or the packaging convention you choose. Do not assume they will fail safely. Depending on the product, a client might reject the artifact, fail to find a signature, or continue through a legacy verification path. Test its behavior directly and decide whether that behavior is acceptable before enabling the new signature in a release channel.

Will older clients verify signatures after migration?

Only if the relevant client version, signature format, and trust configuration support the exact scheme used. Standardization of ML-DSA does not establish compatibility in a client that has not implemented it. Test each consumer against the same artifact and metadata that it will receive in deployment; a result from a command-line verifier does not automatically predict the behavior of an updater or package installer.

If a client cannot verify the new signature, define how it should respond. You might keep that client on the existing release path temporarily, upgrade it before switching the artifact channel, or hold the rollout until verification support is available. Avoid dual-signing by default: it introduces extra key and policy choices, and it can produce false confidence if consumers accept the weaker or unintended path. Document which verifier is authoritative for each consumer.

The NIST NCCoE post-quantum migration FAQ can help frame migration as an inventory and planning task, rather than a one-time algorithm swap. Use it alongside product documentation. It does not certify the support status of your chosen CI/CD platform, library, package format, or client.

Which rollback conditions should a pilot require?

Set rollback conditions before enabling the pilot, and make each condition observable. A reasonable decision framework is:

• Proceed to a wider pilot if the intended artifact is signed, its digest and build identity are recorded, all designated consumers verify it, and access and audit controls behave as designed.
• Pause the rollout if a consumer’s behavior is unknown, verification is inconsistent across environments, the published artifact differs from the signed input, or operators cannot trace a failure to a specific step.
• Return to the established release path if the pilot blocks a required consumer, signing credentials are exposed, verification can be bypassed unexpectedly, or the team cannot revoke or replace trust material according to its plan.

A rollback plan should state what “return” means. It may mean stopping the new release channel, retaining the previous verifier and trust configuration for already published artifacts, or reverting to the previously approved signing procedure. Do not remove old verification capability until you have evidence that supported consumers no longer need it and a separate plan for historical artifacts.

Use this decision list during the release review:

• [ ] The signed object and trust boundary are written down.
• [ ] The chosen library and key-management procedure are supported by their official documentation.
• [ ] Signing credentials are not stored in ordinary pipeline text or exposed in logs.
• [ ] The artifact digest, build identity, and signing request are linked in the release record.
• [ ] Valid, modified, and wrong-trust cases produce the expected consumer behavior.
• [ ] Older supported clients have been tested, and unsupported ones have an explicit disposition.
• [ ] Stop, pause, and rollback triggers have an owner and an operational response.

Expand only when the evidence supports it

Treat the pilot as an infrastructure compatibility exercise, not a demonstration that all software supply-chain components are ready for ML-DSA. Separate the results by layer: algorithm implementation, key custody, pipeline identity, artifact representation, registry or distribution path, and consumer verification. A successful result in one layer cannot stand in for the others.

Keep a record of the exact tool versions and configurations used in testing. Recheck the relevant official documentation when you change a library, CI/CD platform, artifact format, or verifier. The NCCoE migration-to-PQC guidance is a useful reference when you turn a focused signing pilot into a broader migration test plan. It does not replace compatibility testing with your own consumers.

For a macOS-specific build or release path, compare your current runner with a Mac environment only after checking that the required cryptographic library and consumer tools are available there. A shared or short-lived runner can make local reproduction difficult, while a separately managed environment adds access controls, setup work, and another place to keep tool versions aligned. A rented Mac can offer a better fit when you need a Mac build environment for a bounded test, but it does not establish ML-DSA support by itself. Review ZavCloud’s Mac environment options and confirm the required toolchain before relying on that environment.

If you need a temporary place to reproduce a macOS build, first verify the operating-system and library requirements with your team; use the ZavCloud help center or contact ZavCloud to clarify environment access. For broader post-quantum migration planning, start from the NCCoE migration guidance.