Proposal: Insecure Quantum Software Supply Chain as a Candidate Risk

[leprecha1]

Summary

This PR proposes Insecure Quantum Software Supply Chain as a candidate risk for consideration in the OWASP Top 10 for Quantum Security Risks.

The proposal addresses integrity and provenance across the broader quantum software development lifecycle, including dependencies, SDKs, build systems, CI/CD pipelines, quantum artifacts, package and artifact repositories, signing, provenance, and deployment.

Relationship to QS09

QS09:2026 - Toolchain and Compiler Compromise focuses on compromise within the quantum transformation and execution stack, including transpilers, compilers, schedulers, and hardware configuration.

This proposal focuses on the broader software supply chain before and around that toolchain.

QS09 asks whether the quantum transformation and execution toolchain can be trusted. This candidate risk asks whether the software and artifacts entering that toolchain can be trusted in the first place.

A trusted quantum compiler cannot compensate for a compromised dependency, build process, CI/CD pipeline, or artifact delivered to it.

The intention is not to duplicate QS09, but to submit end-to-end quantum software supply-chain integrity and provenance for community consideration as a distinct risk area.

Why this matters

Quantum applications increasingly rely on classical software-development infrastructure before workloads reach quantum execution environments. Compromise of dependencies, build pipelines, artifact repositories, or generated circuit artifacts can therefore alter a quantum workload without requiring compromise of the quantum compiler itself.

The proposal is grounded in established software supply-chain practices such as SLSA, in-toto, Sigstore, and NIST SSDF, together with emerging quantum software engineering research.

Feedback, scope adjustments, and suggestions are welcome.

[galoisField7]

Hello @leprecha1, I think this is an interesting proposal and highlights an important class of risks. In particular, I like the emphasis on integrity throughout the quantum software lifecycle.

One question I have is whether this is best represented as a standalone Top 10 entry or whether it would strengthen QS09.

Many of the examples described here (dependency compromise, CI/CD tampering, artifact substitution, missing, etc.) are well-established software supply-chain risks that also apply to classical systems. The quantum-specific aspects seem to emerge later in the pipeline, around the generation, transformation and execution of quantum workloads.

During our last meeting, we also discussed being careful not to duplicate guidance that already exists elsewhere in the OWASP ecosystem, but instead to complement it where quantum technologies introduce genuinely new risks or significantly change existing ones.

With that in mind, would it make sense to use QS09 to focus on quantum-specific toolchain and workload integrity, while relying on existing OWASP software supply-chain guidance for the more general CI/CD, dependency, and build pipeline aspects?

In other words, the distinction could be:

• Generic software supply-chain risks => existing OWASP software supply-chain guidance
• Quantum-specific transformation and execution integrity (e.g. source => OpenQASM/QIR => transpiler => execution) => QS09

That would avoid introducing a Top 10 entry for risks that largely remain the same when the quantum component is removed, while still highlighting the genuinely new attack surface introduced by quantum development workflows.

Curious what others think.

[leprecha1]

Thanks, this makes a lot of sense, and I agree with the distinction.

My original intention was to highlight the integrity and provenance gap across the broader quantum software lifecycle, but I agree that CI/CD compromise, dependency attacks, and build-system tampering are fundamentally software supply-chain risks and already have established guidance elsewhere in the OWASP ecosystem.

I think the stronger direction would be to use this proposal to expand QS09 around quantum-specific toolchain, artifact, and workload integrity, while referencing existing OWASP supply-chain guidance for the generic controls rather than duplicating it.

One area I would still like to preserve from this proposal is the trust boundary around quantum artifacts. For example, the integrity and provenance of OpenQASM/QIR and other intermediate representations as they move through generation, transformation, transpilation, and execution. This is where I think the classical supply-chain problem starts acquiring quantum-specific characteristics.

So perhaps the resulting scope could be something like:

Source / classical build pipeline → quantum artifact generation → OpenQASM/QIR → transpilation / optimization → execution

with existing OWASP guidance covering the classical supply-chain portion, and QS09 focusing specifically on integrity from the quantum artifact boundary onward.

I'm happy to rework the PR in that direction and contribute the changes directly to QS09 if the group agrees.