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.

[leprecha1]

One additional perspective I would like to add to the discussion is that the boundary between the classical software supply chain and the quantum execution stack may itself be a security-relevant transition point.

In classical software supply-chain security, we normally focus on whether source code, dependencies, builds, and artifacts are authentic and traceable. In a quantum workflow, however, the artifact does not simply get deployed and executed. It can go through multiple semantic transformations before execution, for example:

Source / SDK representation → OpenQASM or QIR → transpilation → optimization → hardware-specific representation → execution

This creates an integrity problem that is not only about whether an artifact was modified, but also whether its intended computational semantics were preserved across these transformations.

That distinction may be useful for QS09.

For example, provenance could potentially capture not only where an artifact came from, but also which transformations were applied to it, which toolchain components performed those transformations, and whether the resulting workload still corresponds to the originally approved computation.

So I see the quantum-specific extension of software supply-chain integrity as having three related questions:

1. Origin integrity - Can we trust the quantum artifact entering the toolchain?
2. Transformation integrity - Can we trust that transpilation and optimization preserved the intended computation?
3. Execution integrity - Can we trust that the workload ultimately executed corresponds to the artifact and transformations we approved?

This could allow QS09 to reference existing OWASP guidance for generic dependency, CI/CD, and build-security controls while focusing its own guidance on this quantum-specific chain of trust.

I would be interested to hear whether this three-stage model makes sense to the group.

[larissaoliveira-lgtm]

Hello @leprecha1. I find this proposal particularly relevant because it draws attention to the distinction between the origin of a compromise and the consequences that such a compromise may produce in a quantum workload.

Many of the attack vectors discussed here, compromised dependencies, CI/CD pipelines, build systems, and artifact repositories, are not unique to quantum software. However, their security implications become more specific once these components are responsible for generating, modifying, or delivering artifacts that directly represent a quantum computation. A compromised dependency, for example, may not merely introduce conventional malicious code; it may silently alter circuit generation, parameters, or the representation ultimately delivered to the quantum toolchain.

In such a scenario, the quantum compiler or transpiler may remain fully trusted and behave exactly as intended, while still processing an artifact that was already compromised before entering the transformation and execution stack. This highlights an important security property: a trusted quantum toolchain does not necessarily imply a trustworthy quantum computation if the artifact entering that toolchain has already been compromised.

From this perspective, an interesting conceptual boundary emerges between this proposal and QS09:

Software supply-chain compromise → Quantum artifact compromise → Quantum toolchain → Execution

What appears particularly important is the transition between the conventional software supply chain and the quantum artifact itself. This is the point at which a compromise originating from a largely classical software-engineering environment can propagate into the representation of a quantum computation and subsequently influence its execution. In my view, this boundary helps clarify why quantum software supply-chain security deserves explicit consideration, even when some of its initial attack mechanisms are inherited from traditional software supply chains.

[leprecha1]

Thanks! I think the distinction you raised between the origin of the compromise and its consequence on the quantum workload is particularly important here.

A dependency or CI/CD compromise may originate from a classical software supply-chain attack, but once it affects an artifact representing a quantum computation, the trust problem propagates into the quantum lifecycle. This also connects with the discussions emerging in #14, #16 and #22 around artifact provenance, transformation conformance, dispatch integrity and execution assurance.

I’m starting to see a broader model emerging from these discussions: an end-to-end quantum chain of trust, where different security guarantees are required at each boundary from artifact generation through execution.

I think this perspective could also help us determine whether #39 should remain a standalone risk or whether these trust boundaries would be better incorporated into an expanded QS09.