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.
