Quantum Secure Software Factory — Operating Quantum Computers

The secure software factory is the production line for quantum platform code, SDK wrappers, compiler passes, runtime plugins, notebooks promoted to services, firmware-adjacent control code, evidence validators, and policy bundles. The Secure Software Development Framework provides a vocabulary for practices that reduce released vulnerabilities, mitigate exploitation impact, and address root causes [R244]. The quantum software factory adds scientific and physical-system controls to that baseline.

Diagram loads as you read

Quantum Secure Software Factory · Figure 1

View diagram source

flowchart LR
    Source[Source and notebook intake] --> Build[Reproducible build]
    Build --> Scan[Security and dependency scan]
    Scan --> QuantumTest[Quantum regression tests]
    QuantumTest --> Policy[Policy simulation]
    Policy --> Sign[Sign artifact]
    Sign --> Registry[Artifact registry]
    Registry --> Release[Progressive release]

Factory lanes

Lane	Examples	Required gates
application	workload services, chemistry pipelines, optimization workflows	unit tests, simulator tests, evidence tests
compiler	pass plugins, target adapters, decomposition libraries	equivalence tests, target regression, performance envelope
runtime	broker adapters, provider clients, queue handlers	contract tests, failure injection, quota tests
control	calibration tooling, pulse registry, firmware-adjacent code	hardware safety review, rollback test
data	warehouse transforms, evidence validators, dashboards	schema tests, lineage tests, retention checks
policy	OPA bundles, admission rules, access maps	simulation, exception tests, signed release

Diagram loads as you read

Factory lanes · Figure 2

View diagram source

flowchart TB
    Factory[Secure software factory] --> App[Application lane]
    Factory --> Compiler[Compiler lane]
    Factory --> Runtime[Runtime lane]
    Factory --> Control[Control lane]
    Factory --> Data[Data lane]
    Factory --> Policy[Policy lane]

Quantum-specific gates

Classical security gates are necessary but insufficient. A dependency scan cannot tell whether a compiler optimization invalidates a benchmark, whether mitigation defaults changed a scientific claim, or whether a calibration selector routes to a stale baseline.

Diagram loads as you read

Quantum-specific gates · Figure 3

View diagram source

flowchart LR
    Security[Security gate] --> Dependency[Dependency risk]
    Quantum[Quantum gate] --> Semantics[Circuit semantics]
    Quantum --> Evidence[Evidence completeness]
    Quantum --> Calibration[Calibration compatibility]
    Quantum --> Statistics[Statistical validity]
    Dependency --> ReleaseDecision[Release decision]
    Semantics --> ReleaseDecision
    Evidence --> ReleaseDecision
    Calibration --> ReleaseDecision
    Statistics --> ReleaseDecision

Artifact promotion

Diagram loads as you read

Artifact promotion · Figure 4

View diagram source

stateDiagram-v2
    [*] --> Research
    Research --> Candidate
    Candidate --> Staged
    Staged --> Canary
    Canary --> Production
    Candidate --> Rejected
    Canary --> RolledBack
    RolledBack --> Candidate

Supply-chain intake

Secure-by-demand practice means customers should ask suppliers for security evidence, not just trust claims [R245]. Internal quantum platforms should apply the same stance to external SDKs, provider clients, simulators, plugin libraries, and notebooks imported from research repositories.

Intake question	Evidence
Who maintains it?	owner, project health, support channel
What depends on it?	SBOM and dependency graph
How is it built?	build provenance and reproducibility note
How is it tested?	security, simulator, and provider-contract tests
How is it updated?	advisory watch and patch SLA
How is it removed?	migration plan and sunset owner

Diagram loads as you read

Supply-chain intake · Figure 5

View diagram source

flowchart TB
    Intake[Third-party intake] --> Identity[Publisher identity]
    Intake --> SBOM[SBOM]
    Intake --> Provenance[Build provenance]
    Intake --> License[License review]
    Intake --> Security[Security score]
    Intake --> Quantum[Quantum compatibility]
    Quantum --> Decision{Admit?}
    Security --> Decision
    Provenance --> Decision

Operator handoff

Every promoted artifact needs an operations handoff.

Diagram loads as you read

Operator handoff · Figure 6

View diagram source

sequenceDiagram
    participant Dev as Developer
    participant Factory as Software factory
    participant Ops as Quantum ops
    participant Evidence as Evidence store
    Dev->>Factory: Submit release candidate
    Factory->>Factory: Build, test, scan, sign
    Factory->>Ops: Handoff package
    Ops->>Evidence: Validate runbook and rollback evidence
    Evidence-->>Ops: Accept or reject
    Ops-->>Factory: Promote or block

Operating rule

A quantum platform should not have a privileged path from research code to production execution. Research code can move fast; production code must leave evidence.