QAST: Quantum Exposure Assessment

Where scans and findings tell you where quantum-vulnerable cryptography lives, QAST answers the question your board actually asks:

QAST finds those flows, ranks them, projects how an adversary would reach your most valuable data, optionally verifies your PQC readiness on the wire with your signed consent, and drives the findings through remediation, retest, and a release gate. The threat model itself is explained in Post-quantum concepts.

Every QAST page carries this stance as a visible callout, every generated report is machine-linted for it before it renders, and attack-path likelihoods are explicitly labeled prioritization signals — never probabilities of decryption.

Every exposure lands in exactly one of three buckets. They are deliberately disjoint so a modeled future risk can never be confused with a real present-day break.

Within HNDL at risk, QAST assigns a relevance level from four axes: the crypto quantum status, the data confidentiality horizon, its harvestability, and the Mosca verdict. Two rules keep the register honest in both directions:

• Not harvestable implies never HNDL-relevant. If a passive collector cannot capture the traffic, there is nothing to harvest — no matter how vulnerable the algorithm.
• The anchor rule. Internet-exposed plus a long or indefinite horizon plus high data sensitivity implies critical, always. This is the textbook HNDL case and it never gets averaged away.

Conversely, a harvestable flow whose Mosca window has already closed is downgraded to low residual relevance rather than inflated.

Route: .../quantum. The landing tab is the HNDL Exposure Register — your ranked worklist. A rollup strip summarizes the latest passive run: total exposures, HNDL-critical count, broken-now count, at-risk count, and projected attack paths.

Each exposure is a card ranked by score impact — the points it is costing your RelixQ Score — showing:

• The flow — the vulnerable algorithm, the data asset it protects, the owning service, and a plain-language rationale.
• Bucket — Broken now / HNDL at risk / Quantum OK, colour-coded.
• HNDL relevance — none to critical, from the four-axis lattice.
• Harvestability — Internet-exposed, Partner-exposed, Internal only, or Not harvestable.
• The Mosca chip — the actual X + Y > Z arithmetic with the computed exposure window in years, and a marker whenever the CRQC timeline is contested.
• Evidence link — a deep link to the underlying finding, so every row reconciles to scanner evidence you can inspect.

An empty register is shown honestly as "No HNDL-relevant exposures in the latest passive run" — never padded with placeholder risk.

Route: .../quantum/attack-paths. This tab answers "so what?" for each exposure: if an adversary harvested at this endpoint, what could they eventually reach? Each entry is a ranked projection — harvestable endpoint → service → finding → crown-jewel data asset — computed over the readiness graph.

Two numbers accompany each path: business impact and likelihood. The likelihood is explicitly labeled a prioritization signal — it ranks which path deserves attention first; it is not a probability that decryption occurs. Every path lists its preconditions, always including the modeled-CRQC precondition verbatim, highlighted so the theoretical prerequisite is impossible to miss.

Route: .../quantum/data-assets. The Mosca X term is a business fact, not a scanner fact — only you know how long your data must stay secret. This tab is where you declare it.

The horizon is tunable from 0 to 75 years; changing the classification snaps it to that class default. The table shows the resulting band — Indefinite / Long 10y+ / Medium 3–10y / Short <3y / None — and the long and indefinite bands are what the anchor rule keys on. Each asset also carries a high-sensitivity flag and an owner. Bulk import accepts pasted CSV in the form name,classification,horizonYears,owner,highSensitivity.

Route: .../quantum/rules-of-engagement. Everything described so far is passive. Before QAST will send a single byte at your infrastructure, a Rules of Engagement document must be authored and signed. This is a hard gate: active runs are refused until the signature verifies, and the orchestrator re-asserts the gate server-side before any probe starts.

Signatory

Name and role of the person accepting responsibility, plus a validity window. Probes outside the window are refused.

Scope allowlist and exclusions

Targets by host, IP, CIDR, URL, or ARN, each tagged prod / staging / test. Each allow entry requires a per-target authority attestation. Exclusions override allows, and at least one attested target is required before signing. The probe worker re-checks the resolved IP, the SNI, and any redirect at connect time, so a DNS change after signing cannot silently widen the scope.

Rate and concurrency caps

You request values and the system clamps them to non-overridable ceilings of 5 connections per second and 4 concurrent, audit-logging any clamp.

Blackout windows

Periods — change freezes, for example — during which active runs are refused.

Safe word and emergency contacts

A kill-switch phrase that halts a running probe instantly, plus who to call.

Signing computes a server-side HMAC over the immutable fields. Editing any of those fields invalidates the signature and re-closes the gate — there is no way to sign one scope and quietly probe another.

Route: .../quantum/active. With a valid signed RoE in effect, this tab runs consent-gated, read-only TLS 1.3 and SSH negotiation observation against your in-scope endpoints. The start button is disabled until the gate is open, and the gate badge tells you exactly what is blocking. Runs move through queued → gating → probing → completed, or failed / halted / refused.

Each probed endpoint gets a precisely worded observation. The distinction between the middle two matters more than anything else on this page:

The probe reports posture — which groups were offered, selected, accepted, or downgraded — and never anything more. No application payloads are sent, nothing is mutated, and a halt request via the safe word stops the run immediately.

Route: .../quantum/remediation. QAST findings become work items on a board running a ten-state lifecycle: open → assigned → in progress → fixed (pending verification) → verified fixed, with branches for waiting vendor, exception requested → exception approved → accepted risk, and reopened.

Items are created from findings — individually or from the exposure register — and each tracks an owner, a due date, its quantum-status bucket, the target control, linked findings and assets, and an external ticket.

Items whose fix regressed are flagged prominently and pushed back through reopened.

Route: .../quantum/report. The report assembles the full deliverable, structured along PTES, NIST SP 800-115, and OWASP WSTG conventions, and rendered through three lenses:

The three buckets are visibly separated in every lens, each with its epistemic tagline — Broken now: "Proven — reproducible local-sandbox break on a golden fixture"; HNDL at risk: "Modeled — dated Mosca exposure window, no break executed"; Quantum OK: "Informational." Every finding carries an exploitability label (proven / modeled / theoretical) with a one-line rationale.

Break-proof evidence shows its verifier command, cited qubit and time estimates with sources, and whether it was executed in a local sandbox or modeled. You can download JSON (the evidence artifact) or Markdown (the human-readable transcript); durable, scheduled deliverables are generated server-side as asynchronous report jobs.

A break proof is reproducible evidence that a primitive you are using is classically broken — established mathematics, demonstrated safely, never on your data.

• Golden-fixture proofs — for example a pre-factored RSA-512 modulus whose factors are verified locally. The product ships no live factoring and touches no customer infrastructure.
• Structural-weakness demos — for example the RC4 keystream bias, reproduced on locally generated keystreams. No key or plaintext recovery.
• Modeled quantum cost — published Shor and Grover resource estimates applied to your specific key sizes, clearly labeled as modeled, with assumptions and citations attached.

Route: .../quantum/retest. Fixing is half the job; proving the fix held is the other half. The retest tab runs each remediation item through an open → fixed → verified state machine and lets you trigger a re-run against the same scope. It verifies fixes, detects regressions — a finding flipping verified → open is highlighted here and on the remediation board — and feeds the release gate.

Route: .../quantum/lab. The PQC Compatibility Lab is the read-only bench view of your estate handshake compatibility: one row per target showing the negotiated group, whether hybrid PQC is supported, whether classical was accepted, whether a downgrade was accepted, and the handshake duration and size — the practical cost of turning hybrid on, since ML-KEM key shares make handshakes bigger.

# Start a run. Passive is the default.
relixq pentest run --project <id>

# --active is refused outright (HTTP 403, no override flag) without a signed, verifying RoE
relixq pentest run --project <id> --active

# Fetch the server-generated report
relixq pentest report --project <id> --run <id> --download -o qast-report.md

# Re-run a prior assessment to verify remediation
relixq pentest retest --project <id> --run <id>

# The CI release gate
relixq pentest gate --run <id> --base-run <id> --mode block

Flags and exit codes are in the Enterprise CLI reference; gate wiring is in Release gates.

The canonical scenario is a project holding patient-genome data with a measured 30-year confidentiality horizon, served over a public TLS endpoint whose key establishment is RSA-2048, with corroborating findings from four independent sources: source code, SBOM, TLS probe, and cloud KMS.

1. 01

   Classification

   The TLS flow is classified HNDL at risk / critical via the anchor rule — Internet-exposed plus indefinite horizon plus high sensitivity.

2. 02

   Exposure window

   A positive Mosca window is computed: X=30 plus Y exceeds Z by a wide margin, dated and marked contested.

3. 03

   Score impact

   The exposure becomes the top RelixQ Score driver, deep-linked from the score hero.

4. 04

   Reachability

   The attack-path projection traces the harvestable endpoint through to the genome store.

5. 05

   Enforcement

   The release gate fails until the transport migrates to hybrid PQC — at which point the endpoint re-classifies to Quantum OK and the gate passes.

At no point does anything get decrypted. The whole chain is exposure, reachability, and posture.