What has been checked, and what still needs a test

Download and verify the signed sample

The sample audit package (ZIP) contains the exact archived 30 September public CBOM sample, detached verification record, public key, SHA-256 manifest and an offline verifier. Run node verify-sample.mjs after extraction with Node 22 linked to OpenSSL 3.5 or another runtime that supports ML-DSA-65. The verifier checks file digests, signature validity and rejection of a one-byte change. Inspect the verifier source.

The sample is a Qtonic Quantum Corp public API artifact, not a CBOM generated from a new estate scan. Its key and signature are vendor-controlled. Our reproducibility check establishes integrity under that key; it does not establish inventory coverage, source-build parity or independent external attestation. Compare the dated vendor input manifest and artifact limitations.

Owned synthetic lab · 30 September 2026

Tested source candidate, not deployed. We exercised QScout components against one owned Python file and a loopback test service. The source candidate is 03e3b4ff300b6ca8c3b9a18f49a95428b2c8466f. Download the lab packet (ZIP), read its scope, and inspect the offline verifier. Extract the ZIP and run python verify.py with the documented dependencies. The packet retains the first failed native export and a separately signed candidate replay.

Discovery and signed CBOMs/binding manifest. The native scanner found one seeded MD5 use before the harness replaced that file with a SHA-256 version; the rescan found no MD5. Both scans covered one file with zero recorded scan or parse errors. This is classical weak-hash removal, not a post-quantum migration or complete cryptographic inventory: the after CBOM has zero components even though the file contains SHA-256. The original native before CBOM failed the official CycloneDX 1.7 schema. A local candidate exporter produced one-before/zero-after documents that passed strict schema and date-time format checks. A lab-only ML-DSA-65 key signed the exact candidate bytes and rejected one-byte changes. The signed manifest binds separately archived, byte-hashed before and after fixture files bound by the signed manifest; the scanner target path is historical after the file edit. A signature proves byte custody under that lab key, not deployed source identity or scanner completeness. The TLS and workflow summaries, README and ZIP are hash-checked by the packet manifest, not signed by the lab key.

Synthetic closure. A native Jira connector sent real HTTP requests to an owned loopback service. The harness polled ticket status and ran the native rescan, then passed those observations into native closure logic. One closed ticket plus covered clean rescan returned verified_closed; four negative cases stayed nonclosed: open ticket, MD5 still present, zero scan coverage and connector HTTP 503. This is not a customer ticket system or autonomous production remediation.

Separate TLS fixture. An owned Node 22/OpenSSL 3.5 loopback test served TLS 1.3 HTTP requests under X25519, X25519MLKEM768 and MLKEM768 key-share policies. Its OpenSSL trace records the named groups. A classical-only client failed against hybrid-only policy with ERR_SSL_NO_SUITABLE_KEY_SHARE; an X25519 rollback served a request. QScout did not perform this change. The original matrix used a self-signed RSA certificate with client verification disabled. A separately sealed same-port follow-up trusted an owned SAN localhost RSA certificate and kept client verification enabled: 26 of 32 compatible probes returned authenticated HTTP 200, while six received ECONNREFUSED during two intentional close/rebind gaps of about 251–252 ms. Classical-only negotiation against the hybrid policy and an untrusted-CA request both failed without an application response; X25519 rollback on the same port succeeded. Inspect every probe and the sealed protocol. These sampled failures show interruption and recovery in the Node harness, not uptime, uninterrupted migration, QScout actuation, post-quantum authentication or production certificate validation.

Still to prove: a governed product release with source-to-live parity, multi-surface accuracy with independent labels, a complete scan-derived inventory, a consented customer pilot and authorized customer ticket closure, product-driven cryptographic change under service continuity, equal-access peer testing and an outside assessment. The 2026.7 ranking remains the unchanged public-documentation snapshot; this lab supplies no peer superiority result. Read the method and publisher relationship.

Discovery to decision to verified closure

Dated vendor evidence: the archived workflow harness reports live_tenant=false; the published workflow uses outbound dry-run behavior. The separate owned loopback lab exercised a connector and closure logic but did not use a customer tenant.

1. Freeze an owned isolated target, consent, scanner build, input manifest and seeded cryptographic issue before execution.
2. Run the named scanner and retain raw output binding finding, asset, observation time, build and run ID. Record false positives or unsupported inputs.
3. Record who approved a sandbox action, what external system actually accepted it, and its task/receipt ID. A simulated ticket or dry-run is labeled as such.
4. Change the target, rescan it and show closure from new observation; reintroduce the issue to prove reopen and exercise a safe retry path.

Completion test: a verifier can follow the issue from scanner input through action and new raw observation without trusting a slide or self-reported status. The owned lab packet demonstrates a bounded synthetic scan-to-rescan and ticket-status path; an authorized customer-system and product-driven action remain unverified.

Crypto agility under failure

NIST CSWP 39-upd1 frames crypto agility as changing algorithms across systems while retaining security and operation. A C6 remediation score is narrower. A meaningful exercise needs named isolated client/server builds and observed negotiation, compatibility, failure and rollback evidence.

1. Capture classical baseline and a hybrid transition with packet or handshake receipts and service continuity observations.
2. Test an unsupported client, a denied downgrade and a deliberately failed canary. Record actual error modes and blast radius.
3. Restore the approved prior state, demonstrate service recovery and rescan configuration. Attribute each action to QScout, another tool or an operator accurately.

Current status: the owned Node loopback fixture records key-share transition, incompatibility and rollback. It is separate from QScout and from a common-build peer trial. The separate one-port Node follow-up measured six failed probes during two intentional restart gaps; no production continuity or product-superiority claim follows.