Skip to main content
RelixQ
Menu

Compliance evidence: what RelixQ produces

Which artifact answers which requirement, what RelixQ emits, and where the evidence boundary sits. For the mandates and deadlines themselves, see Post-quantum concepts.

Findings format
SARIF 2.1.0
CBOM
CycloneDX 1.6
SIEM schema
OCSF
Browse the Developer Guide

Formats consumed and emitted

FormatDirectionSupport
SARIF 2.1.0Emitted--format sarif, with security-severity, tags, per-rule help, stable fingerprints — plus report jobs
CycloneDX (SBOM in)ConsumedFull SBOM ingest, plus manifest analysis
SPDXConsumedYes
CycloneDX 1.6 (CBOM out)EmittedDeterministic, per project
OCSFEmittedThe SIEM export normalization
OpenTelemetryBothExport out, OTLP traces in for runtime correlation
JSON Schema 2020-12EmittedThe finding contract
OIDC / SAML 2.0 / SCIM 2.0ConsumedYes

What RelixQ names as a migration target

A generic scanner tells you an algorithm is weak. RelixQ goes one step further and carries a concrete replacement on the finding itself, so the output is a migration backlog rather than a list of complaints.

What the finding saysHow it is carried
Quantum-safety classification — vulnerable, classically_broken, grover_weakened, hybrid, quantum_safe, unknownOn every finding
A named NIST replacement primitive — ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205)A structured migrationTarget field, plus hybrid guidance and vertical context from the curated Rule Pack
Hybrid transition posture — whether a TLS endpoint already negotiates a post-quantum hybrid grouprelixq scan tls reports certificate and protocol postureEndpoint posture, the no_pqc_hybrid issue, and the PQC Compatibility Lab
Migration order — what to fix first, and what it unblocksThe Crypto-Agility Scorecard (how expensive the change is)Score drivers, next-best actions, and blast-radius ranking over the readiness graph

Mapping a mandate requirement to a RelixQ artifact

Most post-quantum mandates ask for the same handful of things in different words: an inventory, an assessment, a plan, evidence of decisions, and evidence that controls keep operating. This table maps those recurring requirements to the artifact that satisfies them and where to get it. The deadlines themselves — CNSA 2.0, NIST IR 8547, BSI, NIS2, DORA — are covered in Post-quantum concepts.

RequirementWhat RelixQ gives youWhere
A cryptographic inventoryA deduplicated CycloneDX CBOM with per-component evidence, deterministic so you can hash and diff it across releasesEnterprise — Inventory and CBOM
Identify quantum-vulnerable algorithms and key sizesAlgorithm-aware findings with key size, usage, and a quantum-safety classification on each oneDetection coverage
Demonstrate crypto-agilityThe Crypto-Agility Scorecard, a 0–100 measure of how mechanically expensive an algorithm swap isThe scorecard API
A prioritized migration planRanked score drivers, next-best actions with estimated uplift, blast-radius ordering, and the PQC readiness breakdownEnterprise — RelixQ Score
A risk assessment of what is actually exposedThe QAST assessment report — HNDL exposure register, dated Mosca windows, attack paths, and retest status, in an Auditor lensEnterprise — QAST
Evidence of risk-acceptance decisionsTTL-bounded exceptions with named approvers and expiry, on a verifiable hash-chained audit trailEnterprise — Governance
Evidence that a control keeps operatingScheduled scans, release-gate decisions with their conditions, and a CI gate evidence bundle per runRelease gates
Transport and certificate postureTLS versions, cipher suites, certificate key and signature algorithms, expiry windows, and PQC hybrid supportrelixq scan tls; TLS posture
Feed findings into existing GRC or SIEM toolingSARIF 2.1.0 per scan; OCSF-normalized security findings streamed to your SIEMIntegrations

Why the honesty stance matters for audit

Every generated Enterprise report — PDF included — passes an honesty lint before it renders. If generation would ever produce text claiming a decryption or an executed exploit, the job fails rather than ship the claim.

That constraint is what makes the output usable as evidence. Every finding carries an exploitability label — proven, modeled, or theoretical — with a rationale. Break proofs cite their verifier command and their published cost estimates. Mosca verdicts are dated and carry a contested-Z marker. An auditor can tell exactly which claims rest on executed evidence and which rest on a labeled model.

Related pages