Why one shape
Every scanner — code, dependency, TLS, and in Enterprise also cloud posture and runtime telemetry — normalizes its output to one schema before it crosses a service boundary. Most of what either product can do downstream follows from that.
That is why the findings list, risk scoring, dashboards, graph analysis, governance, and reports all speak the same language regardless of where a finding came from — and why a finding produced by the CLI is legible to the tenant that ingests it.
The schema
{
"findingId": "uuid-v7",
"organizationId": "uuid",
"projectId": "uuid",
"scanId": "uuid",
"ruleId": "GO_RSA_GENERATE_KEY",
"algorithm": "RSA",
"keySize": 2048,
"severity": "high",
"filePath": "internal/auth/token.go",
"lineNumber": 42,
"evidence": "rsa.GenerateKey(rand.Reader, 2048)",
"serviceId": "uuid",
"exposure": "external",
"environment": "prod",
"owner": "team-platform",
"usageType": "signing",
"confidence": 0.95,
"recommendation": "Migrate to ML-DSA-65 (Dilithium-3) for new signatures...",
"status": "open",
"createdDate": "2026-05-12T08:00:00Z",
"lastSeenDate": "2026-05-12T08:00:00Z"
}| Field group | Fields | Question answered |
|---|---|---|
| Identity | findingId, organizationId, projectId, scanId, ruleId | Which finding, in whose tenant, from which run and rule? |
| What | algorithm, keySize, usageType, evidence, language | What cryptography was found, and how is it used? |
| Where | filePath + lineNumber, serviceId, environment, exposure | Where does it live, and how reachable is it? |
| Assessment | severity, confidence, quantum-safety classification, recommendation | How bad is it, how sure are we, and what replaces it? |
| Lifecycle | status, owner, createdDate, lastSeenDate | Who owns it, and where is it in triage? |
Quantum-safety classification
Severity describes how weak the cryptography is. The quantum-safety classification describes what kind of work fixing it implies. They are deliberately different axes, and every finding carries both.
| Classification | What lands here | The work it implies |
|---|---|---|
vulnerable | Public-key cryptography broken by Shor: RSA, DSA, ECDSA, EdDSA, ECDH, DH | A real PQC migration — swap to ML-KEM or ML-DSA, or a hybrid. This is the migration backlog. |
classically_broken | Hashes, ciphers, and RNGs already broken today: MD5, SHA-1, RC4, DES, 3DES | Real remediation, but not a public-key PQC migration. Do not let it inflate the migration estimate. |
grover_weakened | Symmetric parameters halved in effective strength, for example AES-128 | Parameter increase, not algorithm replacement. |
hybrid | A classical primitive combined with a PQC one, for example X25519 + ML-KEM-768 | Nothing. This is the recommended transition state. |
quantum_safe | A NIST PQC primitive already in use: ML-KEM, ML-DSA, SLH-DSA | Nothing. This is the column you want to grow. |
unknown | Quantum safety could not be determined from the evidence | A human look. Not safe, not proven unsafe. |
Findings carry no source code
Two consequences worth knowing. The finding detail page renders a representative code sample for the language and algorithm rather than a live read of your file — open path:line in your editor for the real code. And when results are submitted to a workspace, what travels is findings metadata: algorithm, path, line, severity. Never your repository.
SARIF export
RelixQ emits SARIF 2.1.0 with --format sarif. The output carries security-severity, tags, per-rule help text, and stable fingerprints, and uploads directly to GitHub Code Scanning and most other AppSec tooling.
relixq scan /path/to/repo --format sarif > relixq.sarifStable fingerprints are what make baselines and base-versus-head diffs work: a finding is matched by rule plus file plus code snippet, so it survives line-number drift from unrelated edits. See the release gate.
Related pages
Post-quantum concepts
The cryptography and threat model RelixQ is built on: what Shor and Grover break, why harvest-now-decrypt-later is a present-day problem, the Mosca inequality, and the NIST algorithms that replace what breaks.
Scans, findings and reports
The day-to-day working loop: run a scan, read the live progress stream, filter and triage findings, save views, and export evidence.