Quantum Supply Chain, SBOMs, and Provenance

A quantum platform has a wider supply chain than most software platforms. It includes Python packages, compiler passes, runtime containers, pulse libraries, firmware, FPGA bitstreams, calibration records, cryogenic components, microwave hardware, vendor APIs, benchmark datasets, and scientific papers that shape algorithm choices. Treating that chain as informal tribal knowledge is operationally unsafe.

The operating goal is not merely to know what software is installed. The goal is to know which artifact shaped which result, under which calibration state, with which governance approval, and with which downstream claim.

This chapter extends standard secure-development ideas into quantum operations. NIST SSDF provides a useful secure-development frame, SLSA emphasizes provenance and build integrity, and SPDX gives a standard representation for software bills of materials. Quantum systems need the same discipline, but expanded to include control artifacts, calibration products, and hardware-dependent execution metadata. [R140]

flowchart LR
    Source[Source repo] --> Build[Build workflow]
    Build --> Image[Runtime image]
    Build --> Compiler[Compiler artifact]
    Compiler --> Circuit[Circuit bundle]
    Image --> Job[Quantum job]
    Circuit --> Job
    Calibration[Calibration snapshot] --> Job
    Job --> Evidence[Evidence package]
    Evidence --> Claim[Bounded claim]

Supply chain objects are operational objects

For quantum operations, the supply chain includes anything that can change an experimental distribution. That includes normal software dependencies, but also less obvious artifacts:

• pulse schedules and pulse templates;
• backend target models;
• transpiler configurations;
• calibration snapshots;
• measurement mitigation matrices;
• decoder versions;
• analog-program specifications;
• cloud-provider target identifiers;
• hardware reservation contracts;
• lab control firmware.

An SBOM for a quantum platform should therefore be closer to an execution bill of materials than a package manifest.

flowchart TB
    EBOM[Execution BOM] --> Software[Software packages]
    EBOM --> Compiler[Compiler and transpiler]
    EBOM --> Runtime[Runtime image]
    EBOM --> Hardware[Hardware target]
    EBOM --> Calibration[Calibration and noise metadata]
    EBOM --> Control[Pulse and control artifacts]
    EBOM --> Data[Input and output datasets]

The quantum artifact hierarchy

A useful hierarchy separates source artifacts, build artifacts, execution artifacts, and evidence artifacts.

flowchart TB
    S[Source artifacts] --> B[Build artifacts]
    B --> E[Execution artifacts]
    E --> R[Result artifacts]
    R --> C[Claim artifacts]

    S --> S1[Algorithms]
    S --> S2[Policies]
    S --> S3[Experiment definitions]
    B --> B1[Images]
    B --> B2[Compiled circuits]
    B --> B3[Pulse bundles]
    E --> E1[Jobs]
    E --> E2[Reservations]
    E --> E3[Calibration snapshots]
    R --> R1[Counts]
    R --> R2[Mitigated estimates]
    C --> C1[Reports]
    C --> C2[Public statements]

Every artifact should answer four questions:

1. Who or what produced it?
2. Which inputs produced it?
3. Which policy approved it?
4. Which results or claims depend on it?

Provenance as a first-class data model

In classical platforms, provenance is often reconstructed after an incident. Quantum platforms need provenance captured at execution time. Calibration drift and stochastic output make after-the-fact reconstruction weaker.

sequenceDiagram
    participant Dev as Developer
    participant CI as Build and test
    participant Registry as Artifact registry
    participant Runtime as Runtime
    participant QPU as QPU
    participant Warehouse as Evidence warehouse

    Dev->>CI: Submit experiment definition
    CI->>CI: Run simulator and policy gates
    CI->>Registry: Publish signed artifact bundle
    Runtime->>Registry: Resolve artifact versions
    Runtime->>QPU: Submit compiled workload
    QPU-->>Runtime: Return shots and metadata
    Runtime->>Warehouse: Store provenance graph

The provenance graph should link the result back to at least:

• commit hash;
• dependency lockfile;
• container digest;
• compiler version;
• backend target model;
• calibration snapshot identifier;
• runtime execution mode;
• shot budget;
• mitigation configuration;
• approval and exception records.

flowchart LR
    Commit[Commit hash] --> Bundle[Experiment bundle]
    Lock[Dependency lockfile] --> Bundle
    Image[Container digest] --> Bundle
    Target[Backend target model] --> Bundle
    Cal[Calibration snapshot] --> Bundle
    Policy[Policy decision] --> Bundle
    Bundle --> JobID[Job identifier]
    JobID --> Result[Result dataset]
    Result --> Report[Report section]

Artifact signing and tamper evidence

Quantum results are easy to overinterpret. Artifact tampering can move a result from valid to invalid without changing the visible output shape. The platform should sign artifacts that influence execution and result interpretation.

flowchart LR
    Artifact[Artifact] --> Hash[Hash]
    Hash --> Sign[Signature]
    Sign --> Registry[Registry]
    Registry --> Verify{Verify before use}
    Verify -- pass --> Execute[Allow execution]
    Verify -- fail --> Quarantine[Block and investigate]

Signing is most important for:

• release images;
• compiler plugins;
• calibration products;
• pulse libraries;
• mitigation code;
• benchmark suites;
• report-generation templates.

Hardware and vendor provenance

The hardware side has a similar shape. Component provenance is not only a procurement concern. It affects reliability, export-control posture, maintenance planning, and safety.

flowchart TB
    Vendor[Vendor shipment] --> Intake[Intake inspection]
    Intake --> Component[Component record]
    Component --> Install[Installation event]
    Install --> Commission[Commissioning run]
    Commission --> Service[Operational service]
    Service --> Retire[Retirement record]

At minimum, the hardware provenance record should include:

• model and serial identifier;
• firmware or embedded-control revision;
• maintenance history;
• compatibility constraints;
• calibration dependencies;
• safety reviews;
• export or data-residency constraints where applicable.

Supply chain gates

The platform should apply gates before artifacts can move between trust zones.

stateDiagram-v2
    [*] --> Draft
    Draft --> Built: CI success
    Built --> Tested: simulator and unit tests
    Tested --> Signed: provenance complete
    Signed --> Approved: policy gate passes
    Approved --> Released
    Built --> Rejected: dependency risk
    Tested --> Rejected: validation failure
    Signed --> Rejected: signature failure
    Released --> Deprecated: replacement available
    Deprecated --> Retired

Recommended gates:

Incident response for artifact defects

A defective artifact does not always cause an outage. It may cause a silent scientific error. That makes rollback insufficient. The platform must also identify affected results.

flowchart TB
    Defect[Artifact defect found] --> Scope[Find dependent jobs]
    Scope --> Classify{Impact class}
    Classify -- execution invalid --> Revoke[Revoke results]
    Classify -- estimate biased --> Reanalyze[Reanalyze with corrected artifact]
    Classify -- no material impact --> Record[Record no-impact rationale]
    Revoke --> Notify[Notify consumers]
    Reanalyze --> Notify
    Record --> Close[Close incident]

Quantum-specific SBOM extension

A standard software SBOM is necessary but incomplete. A quantum execution BOM should add fields for target, calibration, control, and interpretation.

flowchart LR
    SPDX[Software SBOM] --> QBOM[Quantum execution BOM]
    QBOM --> Target[Target profile]
    QBOM --> Cal[Calibration profile]
    QBOM --> Pulse[Pulse profile]
    QBOM --> Mitigation[Mitigation profile]
    QBOM --> Evidence[Evidence profile]

Minimum fields:

quantum_execution_bom:
  workload_id: qexp-2026-04-19-001
  source_commit: 7e4b...
  image_digest: sha256:...
  compiler:
    name: qiskit-transpiler
    version: pinned
    pass_manager_hash: sha256:...
  target:
    provider: vendor-or-lab
    backend_id: qpu-name
    target_model_hash: sha256:...
  calibration:
    snapshot_id: cal-...
    collected_at: 2026-04-19T00:00:00Z
  interpretation:
    mitigation_method: measurement-mitigation
    confidence_policy: approved-policy-id

Operating rule

Do not publish, promote, or automate on a quantum result unless the platform can reconstruct the artifact chain that produced it.

flowchart LR
    Result[Quantum result] --> Reconstruct{Can reconstruct chain?}
    Reconstruct -- yes --> Use[Use with bounded claim]
    Reconstruct -- no --> Hold[Hold as exploratory only]