The post-quantum deadlines are closer than your roadmap thinks — so I built a CBOM scanner

oleg-vdv — Fri, 17 Jul 2026 00:55:53 +0000

Three regulatory clocks are already ticking:

US: EO 14412 / CNSA 2.0 requires post-quantum cryptography for new national-security acquisitions from 2027 — and explicitly names the "cryptographic bill of materials" (CBOM).
UK: NCSC wants full cryptographic discovery and a migration plan by 2028.
EU: member states start transitioning from the end of 2026.

Yet when an auditor asks the first, most basic question — "where exactly does your codebase use RSA?" — almost nobody can answer. Not because it's hard conceptually, but because nobody ever had a reason to keep an inventory of their cryptography. Now there's a reason.

What "harvest now, decrypt later" actually means

Even if a cryptographically relevant quantum computer is a decade away, traffic recorded today can be decrypted then. If your secrets have a shelf life of more than a few years (medical records, financial data, government contracts), classical key exchange is already a liability. That's the logic behind the deadlines — they don't wait for the quantum computer to exist.

One command, three artifacts

I wanted the discovery step to cost one command instead of one consulting engagement:

npx @proofbyte/pqc-radar scan . --cbom cbom.json --report report.md --sarif findings.sarif

This walks the repository and flags quantum-vulnerable cryptography — RSA, ECC/ECDH, DH, DSA, Curve25519, legacy hashes, weak TLS configs — across Java, Python, JavaScript/TypeScript, Go, C#, Rust, Ruby, PHP, C/C++ and nginx/Apache configs. Out come three artifacts:

cbom.json — a CycloneDX 1.6 CBOM: the machine-readable inventory the mandates ask for;
report.md — a human-readable report: every finding with file:line and its ML-KEM (FIPS 203) / ML-DSA (FIPS 204) migration target;
findings.sarif — SARIF 2.1.0, so findings land straight in GitHub code scanning.

It's fast enough to live in CI: hashicorp/vault (4,827 files) scans in about 9 seconds; a weekly corpus workflow re-scans five well-known OSS projects to catch regressions.

Checking live endpoints, not just code

Code is half the story — the other half is what your servers actually negotiate:

npx @proofbyte/pqc-radar scan-tls your-api.example.com github.com

One TLS handshake per host (no payload sent) reports the protocol, cipher, key-exchange group and certificate key — and whether the endpoint already speaks hybrid post-quantum key exchange (X25519+ML-KEM-768). One honesty detail I'm proud of: when the local TLS stack can't name the negotiated group (older OpenSSL builds can't name hybrid groups), the result is reported as inconclusive, not as a finding. Unknown ≠ vulnerable.

What the v0 honestly can't do

Detection is line-pattern based. That makes it fast, broad and dependency-free, but:

it will miss dynamically constructed crypto calls;
unusual code can false-positive;
absence of findings is not proof of absence — the report says so explicitly.

A deep AST engine (integrating PQCA CBOMkit, which covers Java and Python) is the next milestone. There's also a fun war story: the very first regression test caught the scanner's regexes matching their own source code — the fix was masking pattern literals with character-class tricks (RSA_generate_ke[y]), and a permanent guard test asserting the repo only ever flags its own fixtures.

Security posture

This is a tool you're supposed to run on code you can't share, so: fully offline (the scan command makes zero network calls), zero runtime dependencies, read-only, symlinks not followed. scan-tls is the single network feature and touches only endpoints you name. It's MIT-licensed — read the source rather than trusting this paragraph.

Try it

npx @proofbyte/pqc-radar scan .

GitHub: https://github.com/oleg-vdv/proofbyte (issues and PRs welcome — especially new language patterns with fixtures)
CI one-liner: uses: oleg-vdv/proofbyte@v1

I'd genuinely like to hear from anyone whose org has already been asked for a CBOM — by whom, and what format they accepted.