PQC for Software Supply Chain Security: Signatures, Attestations, and SBOMs

Quick answer: Software supply chain security runs on a stack of signed objects, artifact signatures, SLSA provenance attestations, in-toto statements, transparency log entries, and every one of them is only as trustworthy as the signature algorithm underneath it. Keyless signing tools built on Sigstore’s Fulcio and Rekor already carry a known, publicly acknowledged migration cost: the Sigstore team has stated that the industry-wide shift to post-quantum cryptography will introduce breaking client changes, which is part of why they have kept the public Rekor instance on v1 rather than defaulting to v2. An SBOM and a CBOM answer different questions here: an SBOM tells you what is inside an artifact, a CBOM tells you what cryptography is protecting the signatures and attestations wrapped around it, and a complete post-quantum supply chain story needs both.

Supply chain security tooling, SLSA provenance, in-toto attestations, Sigstore-based signing, transparency logs, has matured quickly over the past several years specifically to answer “can I trust where this artifact came from.” Almost none of that maturity has yet accounted for what happens when the signatures underneath all of it need to move to post-quantum algorithms. This guide connects the two.

Key Takeaways

• Every layer of modern supply chain security, artifact signatures, SLSA provenance, in-toto attestations, transparency log entries, is itself a signed object that inherits whatever algorithm risk its signing key carries.
• Sigstore’s own team has publicly stated that post-quantum migration will introduce breaking changes for verifying clients, a concrete signal that this transition is neither trivial nor fully solved in current tooling.
• Keyless signing through Fulcio’s short-lived, OIDC-issued certificates changes the migration shape compared to long-lived key management, but does not eliminate the need for the underlying signature algorithm to become post-quantum capable.
• An SBOM and a Cryptography Bill of Materials answer complementary questions: what components an artifact contains versus what cryptography protects the trust claims wrapped around it.
• Transparency logs add a durability requirement beyond a single signature: entries recorded years ago need to remain independently verifiable even as the signing algorithms protecting them are eventually deprecated.

The Signed Object Stack

Modern software supply chain security is built from several distinct layers of signed data, each with its own trust model:

• Artifact signatures: the direct signature over a binary, container image, or package, proving it has not been altered since signing.
• SLSA provenance attestations: signed statements describing how an artifact was built, including the build environment, source repository, and dependency digests, structured using in-toto attestations wrapped in a DSSE (Dave’s Simple Signing Envelope) signature format.
• Transparency log entries: Sigstore’s Rekor log records signing events in an append-only, cryptographically verifiable ledger, so consumers can verify a signature was actually logged rather than trusting a claim in isolation.

Every one of these layers is a digital signature at its core, which means every one of them needs its own path to post-quantum algorithm support, and none of them automatically inherit post-quantum protection just because the artifact signature at the bottom of the stack does.

Keyless Signing and the PQC Transition

Sigstore’s keyless signing model, where Fulcio issues a short-lived certificate tied to an OIDC identity instead of relying on a long-lived signing key, was designed to eliminate long-term key management risk. It does not, however, remove the underlying signature algorithm from the migration equation: Fulcio’s certificate issuance and the artifact signature it enables still depend on the signing algorithm being used, and that algorithm needs a post-quantum path the same as any long-lived key would.

The Sigstore project has been explicit about the scale of this challenge. In discussing why the public Rekor instance has stayed on v1 rather than defaulting to the newer v2 architecture, the team specifically cited the coming post-quantum transition as a source of breaking changes for verifying clients, distinct from the v1-to-v2 infrastructure changes themselves. That is a direct, current signal from the team building this tooling that post-quantum migration for keyless signing infrastructure is a real, acknowledged, and not yet fully resolved engineering problem, not a solved footnote.

Attestations and Provenance: Signed Claims, Same Risk

SLSA provenance attestations and in-toto statements are structured, signed claims about how an artifact was built, and DSSE, the envelope format both use, is signature-algorithm-agnostic at the format level: it wraps a payload and a signature, without dictating which algorithm produced that signature. That is a genuine advantage for post-quantum migration, since it means the attestation format itself does not need to change to accommodate ML-DSA or SLH-DSA signatures, only the signing and verification tooling underneath it does.

The practical implication: as Sigstore, in-toto tooling, and related signing clients add post-quantum algorithm support, attestations and provenance records can migrate without requiring a new attestation schema, provided the verification tooling your organization depends on is updated in step. That verification tooling dependency is exactly the kind of hidden compatibility requirement worth inventorying now rather than discovering during an incident.

Transparency Log Durability

Transparency logs add a requirement that a simple artifact signature does not carry on its own: entries recorded today need to remain independently verifiable for as long as the artifacts they cover remain in use, potentially years after the signing algorithm that created them has been deprecated. A Rekor entry from 2024, signed under classical algorithms, has to remain checkable against the log’s own integrity guarantees even after the broader ecosystem has moved to post-quantum signing for new entries. This is the transparency-log equivalent of the code-signing timestamping problem covered in our PQC code signing timestamping guide: durability of the proof matters as much as the strength of the algorithm that created it.

SBOM and CBOM: Complementary, Not Redundant

A Software Bill of Materials answers “what components does this artifact contain,” useful for vulnerability management and license compliance, but it says nothing about the cryptography protecting the artifact’s own signatures and attestations. A Cryptography Bill of Materials answers the complementary question: which algorithms sign this artifact, which algorithms protect its provenance attestations, and which of those algorithms are quantum-vulnerable and need a migration path. For a complete post-quantum-aware supply chain security posture, an organization needs both: the SBOM to know what is inside the artifact, and the CBOM to know what is protecting the claims made about it.

What We’d Actually Recommend

Inventory every signed layer in your supply chain security stack separately, artifact signatures, provenance attestations, transparency log entries, since each has its own algorithm dependency and migration timeline, not a single unified one. Track your signing tooling’s post-quantum roadmap directly, given Sigstore’s own acknowledgment that breaking client changes are coming, rather than assuming keyless signing insulates you from the migration. Build a CBOM alongside your existing SBOM practice, since vulnerability management and cryptographic migration are genuinely separate concerns that happen to both start with an inventory.

How Encryption Consulting Can Help

CBOM Secure is built specifically for the gap this guide describes: it maps the cryptography protecting your artifact signatures, provenance attestations, and signing pipelines as a distinct inventory from your SBOM, so the algorithm dependencies underneath your supply chain security stack are visible and trackable as post-quantum tooling matures across Sigstore, SLSA, and related ecosystems.

Our PQC Advisory Services build that inventory into a migration plan covering every signed layer in your stack, not just the artifact signature at the bottom. Where code and firmware signing infrastructure itself is involved, CertSecure Manager and our CodeSign Secure platform bring HSM-backed post-quantum signing into the same CI/CD pipelines your provenance and attestation tooling already runs in.

The Whole Stack Needs a Migration Path

Supply chain security tooling has spent years building a layered stack of signed trust claims, and every layer of that stack carries the same algorithm risk as a plain code-signing certificate, whether or not it looks like one. Sigstore’s own team saying the post-quantum transition will break clients is a useful, concrete reminder that this is unfinished infrastructure work across the ecosystem, not a solved problem waiting for adoption. Building a CBOM alongside your SBOM, and tracking each signed layer’s migration path separately, is what turns “our supply chain is quantum-vulnerable somewhere” into an actual, addressable plan.

Frequently Asked Questions

Does Sigstore’s keyless signing eliminate post-quantum migration risk?

No. Keyless signing removes long-lived key management risk, but the signature algorithm used by Fulcio-issued certificates and the resulting artifact signatures still needs its own post-quantum migration path. Sigstore’s own team has acknowledged the transition will introduce breaking changes for verifying clients.

Do SLSA attestations need a new format to support post-quantum signatures?

No. The DSSE envelope format used by SLSA provenance and in-toto attestations is signature-algorithm-agnostic, so post-quantum signatures can be adopted without changing the attestation schema itself, provided the signing and verification tooling is updated.

What is the difference between an SBOM and a CBOM in this context?

An SBOM inventories the components inside an artifact, useful for vulnerability and license management. A CBOM inventories the cryptography protecting the artifact’s own signatures and attestations, which is what a post-quantum migration plan actually needs to track.

Why does transparency log durability matter for PQC migration?

Transparency log entries need to remain independently verifiable for as long as the artifacts they cover are in use, which can extend well past the point when the algorithm that originally signed them is deprecated. This mirrors the timestamping durability problem in code signing.

Which layer of the supply chain security stack should be migrated to post-quantum algorithms first?

There is no universal answer; it depends on which layer carries the highest-value trust claim in your specific environment. What matters is treating each layer, artifact signatures, provenance attestations, and transparency log entries, as a separate inventory item with its own migration timeline rather than assuming one covers the others.