QuantBOM SDK

Certify a quantum software release straight from your Qrisp / Qiskit / Cirq / Braket / PennyLane pipeline. Evidence is collected locally (your source never leaves the machine) and sent to the QuantBOM service, which returns a signed, independently-verifiable CRA certificate — also mirrored to ./.quantbom/<release>/.

QuantBOM is a SecQDevOps MOD-08 service.

Install

pip install "quantbom[quantum]"     # Qiskit + OpenQASM3 evidence collection
# pip install "quantbom[quantum,qrisp]"   # also collect from Qrisp circuits
# pip install "quantbom[quantum,cirq]"    # Cirq   — likewise [braket], [pennylane], [cudaq] (Linux only)
# pip install "quantbom[quantum,ibm]"     # real IBM Runtime execution evidence
# pip install "quantbom[quantum,qir]"     # also emit QIR (QDK) and check it against the program (QNT-07)
# pip install "quantbom[signing]"         # sign your evidence (quantbom keygen / --sign) and verify certificates offline
# Each frontend extra pins the version range the conformance suite holds for
# (harness_manifest.json `requires`); `quantbom actions --framework <name>` shows
# the recorded run, or that conformance is still pending.

The core install is a lightweight, stdlib-only client; the quantum extra adds the toolchain needed to build the evidence (QBOM).

Use

Set your API key (generate it in the QuantBOM dashboard):

export QUANTBOM_API_KEY=qb_live_...
export QUANTBOM_API_URL=https://certify.zortenet.eu   # default

Post-run call

import quantbom
result = quantbom.certify(my_circuit, release="portfolio-opt@1.2.3")
print(result["overall_status"], result["certificate"]["certificate_id"])

Decorator — certifies the circuit a function returns:

@quantbom.certified(release="vqe@2.1")
def build(): ...   # returns a qiskit/qrisp circuit

Qiskit primitive wrapper — certify transparently on .run():

sampler = quantbom.wrap(SamplerV2(mode=backend), release="vqe@2.1")
job = sampler.run([circuit])   # certifies, then runs as normal

Sign your evidence — the certificate's authorship claim (CRA-SIGN-01) rests on your signature, not the service's. One key per organisation:

pip install "quantbom[signing]"
quantbom keygen                                   # ~/.quantbom/signing.key (0600) + signing.pub — back it up
quantbom certify --qpy circuit.qpy --release my-app@1.0 --sign

In Python: quantbom.certify(circuit, release=..., sign=True). The SDK signs the collected evidence (Ed25519, in-toto/DSSE) before upload; the service verifies it, countersigns what it received, and the certificate names both key ids. Without --sign the release is NON_COMPLIANT: CRA-SIGN-01 rests on the producer's signature, the service's countersignature is a receipt and never substitutes, and the certificate says in words that the producer did not sign. --key FILE or QUANTBOM_SIGNING_KEY point at a key elsewhere; in CI, store the key as a secret and pass it to the quantbom-certify action's signing-key input.

Verify a certificate without trusting us — for the auditor, the customer, or your future self. Needs only the wheel, never the service code:

pip install "quantbom[signing]"
quantbom keys --pin                        # fetch the service's signing keys once; pin them
quantbom verify .quantbom/my-app@1.0        # the mirror, a collect bundle, or a zip of either

It re-hashes every artifact against the QBOM, verifies the producer's attestation and the service's receipt, recomputes the CSNAP's and the certificate's reproducibility hashes and bindings, and checks the certificate signature against a key that is anchored (pinned from /v1/keys, or given with --keys / --service-key). What it does not do, it says: the 24 controls are not re-run (that needs the gate, verify_bundle.py in the repository). Verdicts: VERIFIED (exit 0), FAILED, or UNANCHORED when every check passed but nothing was pinned.

CLI / CI

quantbom certify --qpy circuit.qpy --release my-app@1.0 --mode gate --sign
quantbom certify --qasm3 program.qasm3 --release my-app@1.0
quantbom certify --demo --release smoke-test     # needs the [qrisp] extra

# any supported framework, straight from your code (module:attr or file.py:attr;
# a function is called, an object such as a PennyLane QNode is passed as is)
quantbom certify --entry my_pkg.circuits:build --release my-app@1.0 --expect 10=1.0

--mode gate exits non-zero on a non-compliant release (use it to fail CI); --mode report (default) never fails your pipeline. --expect outcomes are read in your framework's own bit order (--expected-order qiskit to override). For Qrisp that depends on what you hand over: a QuantumCircuit reads like run() (qubit 0 rightmost), a QuantumSession like get_measurement() and a Jasp program like measure() (qubit 0 leftmost) — declare what Qrisp shows you.

Adding evidence from other modules — collect, add, then certify the bundle:

quantbom collect --entry my_pkg.circuits:build --release my-app@1.0 --out bundle/
quantbom attest tests         --bundle bundle/ --suite quantum-security-suite --outcome passed --passed 42
quantbom attest vulns         --bundle bundle/ --policy-url https://example.org/security --contact mailto:security@example.org
quantbom attest constant-time --bundle bundle/ --tool dudect --target kyber_decaps --measurements timings.csv
quantbom attest crypto        --bundle bundle/ --cbom cbom.cdx.json
quantbom sign --bundle bundle/                    # last, so the signature covers it all
quantbom certify --bundle bundle/ --release my-app@1.0

The four attest commands are the partner-module evidence the gate otherwise reports as N-A: a MOD-05 security test report (MOD05-TEST-01), a VEX/VDR and a coordinated-disclosure policy (CRA-VULN-01, CRA-VDP-01), a constant-time proof from dudect / ctgrind / Binsec-Rel (CRA-ESR-06), and a CBOM PQC-readiness assessment (CRA-CRYPTO-01). Each writes a hash-bound document into the bundle; the same bytes the repository scripts write.

In Python: quantbom.collect(...), then quantbom.attest.tests(bundle, ...), .vulnerability_handling(...), .constant_time(...), .crypto(...), then quantbom.certify(bundle="bundle", release=..., sign=True).

What can the harness do for me?

quantbom actions --framework cirq          # every action, its status for Cirq, how to turn it on
quantbom actions --requirement CRA-II-3    # which actions produce evidence for this requirement

Answered offline from the index shipped in the package — the same answer the service gives at GET /v1/harness.

Behaviour

• Non-intrusive & fail-soft. If the service is unreachable or credits are exhausted, a warning is logged and your quantum run continues. Certifying is additive (unless you opt into gate mode).
• Privacy by design. Only the QBOM/evidence (hashes, metrics, backend binding) is uploaded — not your program source.
• Local mirror. Every result is written to ./.quantbom/<release>/ (the QBOM as the gate ran on it, CSNAP, certificate, attestation, the service's receipt and public keys, verification) so you keep your own audit bundle and can re-verify it offline with quantbom verify.