{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidpcw5chibf37nxii65qpadgpabut2scg25dqopow7prjovi4mhrm",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpuowvzjhqh2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreigcycxflxcucd65zcusg4pj43bviab7wj3ocpynpl3glaz7jna4ue"
    },
    "mimeType": "image/webp",
    "size": 61024
  },
  "path": "/brandonsellam/add-a-post-quantum-readiness-gate-to-your-ci-in-5-lines-2bg3",
  "publishedAt": "2026-07-05T03:00:33.000Z",
  "site": "https://dev.to",
  "tags": [
    "security",
    "cryptography",
    "devops",
    "github",
    "https://throndar.ai/cbom",
    "github.com/brandonjsellam-Releone/verify-pqc",
    "throndar.ai/evidence",
    "repo"
  ],
  "textContent": "Your codebase almost certainly relies on RSA and elliptic-curve cryptography — TLS, JWTs, SSH keys, signed tokens. All of it is breakable by a large enough quantum computer (Shor's algorithm), and \"harvest now, decrypt later\" means data you encrypt _today_ can be captured today and decrypted later. Regulators noticed: **CNSA 2.0** (US federal + suppliers), **DORA** (EU financial entities, applies from Jan 2025), and **NIS2** now mandate strict cryptographic risk management — which in practice means knowing where your quantum-vulnerable crypto lives, a _cryptographic bill of materials_ (CBOM).\n\nMost teams can't answer \"where is our RSA/ECC?\" off the top of their head. Here's how to make CI answer it for you, on every push, for free.\n\n##  What we're building\n\nA GitHub Action that scans your repo, grades its post-quantum readiness **A–F** , writes a **CycloneDX 1.6 CBOM** , and — if you want — **fails the build** when classically-broken crypto (MD5, RC4, 3DES, deprecated TLS) shows up.\n\n##  Step 1 — try it in your browser first (30 seconds, nothing uploaded)\n\nBefore touching CI, paste a `package.json` / `requirements.txt` / cipher list into the in-browser scanner and see your grade. It runs entirely client-side — no upload: **https://throndar.ai/cbom**\n\n##  Step 2 — add it to CI (the 5 lines)\n\n\n    # .github/workflows/pqc-readiness.yml\n    name: PQC readiness\n    on: [push, pull_request]\n    jobs:\n      scan:\n        runs-on: ubuntu-latest\n        steps:\n          - uses: actions/checkout@v4\n          - uses: brandonjsellam-Releone/pq-readiness-scorecard@v1\n            with:\n              path: .\n\n\nThat's it. The Action is self-contained and dependency-free — no `npm install`, no setup step. On the next push it prints a scorecard to the job summary:\n\n\n\n    Post-Quantum Readiness Scorecard: D  (52/100) — Quantum-vulnerable — migrate\n    3 files · broken-classical 0 · quantum-broken 4 · weakened 1 · resistant 0\n\n\n##  Step 3 — see findings in the Security tab (SARIF)\n\nThe Action emits SARIF 2.1.0. Upload it and every finding shows up as a code-scanning alert:\n\n\n\n          - id: pqc\n            uses: brandonjsellam-Releone/pq-readiness-scorecard@v1\n          - uses: github/codeql-action/upload-sarif@v3\n            if: always()\n            with:\n              sarif_file: ${{ steps.pqc.outputs.sarif-file }}\n\n\nYou also get `cbom.cdx.json` (the CycloneDX CBOM) as a build artifact — feed it to any SBOM/CBOM tooling.\n\n##  Step 4 — fail the build on broken crypto\n\nGrading is nice; a gate is better. Fail the build when anything classically-broken appears:\n\n\n\n            with:\n              fail-on: broken-classical        # or: broken-classical,quantum-broken\n              # min-grade: B                    # optional: fail below grade B\n\n\nNow a PR that adds `hashlib.md5()` or `TLSv1.0` goes red before it merges.\n\n##  Which findings do you fix first? (harvest-now-decrypt-later)\n\nNot every quantum-vulnerable finding is equally urgent. **Key establishment** — ECDH, Diffie-Hellman, RSA key transport (RSA-OAEP, static-RSA TLS) — is the most time-critical: an adversary can record your encrypted traffic **today** and decrypt it later once a quantum computer exists (\"harvest now, decrypt later\"). Signatures are less urgent — forging one needs a quantum computer _at signing time_ , not retroactively. The scanner tags the harvest-now findings and puts them first in the migration plan, so you don't waste the early budget on the wrong things.\n\n##  What it actually detects\n\n  * **Quantum-broken (Shor):** RSA, ECDSA, ECDH, finite-field DH, EC curves, RSA/ECDSA JWTs, SSH RSA/ECDSA keys.\n  * **Hardcoded JWTs:** it decodes the token **header** (base64url segment only — never the payload, so no secrets end up in a finding) and classifies the `alg`: `RS256`/`ES256`/`PS256` → Shor-broken, `HS256` → Grover-weakened, `alg:none` → critical unsigned.\n  * **Quantum-weakened (Grover):** AES-128/192 (Grover's quadratic speedup reduces effective security — enough to prefer AES-256); SHA-256 (collision resistance drops to ~2^85). SHA-384/512 stay fine.\n  * **Classically broken (fix today):** MD5, SHA-1, RC4, 3DES, Blowfish, deprecated TLS, NTLM, WEP.\n  * **Quantum-resistant:** ML-KEM, ML-DSA, SLH-DSA (the NIST FIPS 203/204/205 standards), AES-256, SHA-384, SHA-512, ChaCha20 (256-bit).\n  * **Broken PQ candidates:** it also flags SIKE/SIDH (broken by Castryck–Decru in 2022) and GeMSS — so a team that _thinks_ it migrated to post-quantum isn't left trusting something already broken.\n\n\n\nIt reads inline code, declared crypto libraries, numeric OIDs in certs/ASN.1, and base64/PEM key blobs.\n\n##  Honest caveats (read these)\n\nIt's a **lexical** scan: findings are **leads to verify, not a complete inventory** , and it is **not a certification**. Algorithm names denote the public standards they're based on — not a CMVP/FIPS-140 validation. It won't fake a clean bill of health: a scan that examines zero files _refuses to grade_ rather than reporting \"A\". The scanner is open-source (MIT) — read it and re-run every finding yourself: github.com/brandonjsellam-Releone/verify-pqc. (Falcon, if you see it flagged, is FN-DSA for the forthcoming FIPS 206 — in development, not yet standardized.)\n\n##  If your grade is bad\n\nStart with **Phase 1** : rip out the classically-broken stuff (MD5/SHA-1/RC4/3DES, old TLS) — that's exploitable _today_ , quantum or not. Then plan the quantum-broken key-establishment (the harvest-now items) and signatures toward the NIST PQC standards, running classical+PQC in hybrid during the transition.\n\nIf you need a signed, auditor-ready version of this — an **Evidence Pack** with an executive summary, the grade, the findings, the CBOM, and a prioritized migration plan, cryptographically signed so your auditors can verify it hasn't been altered — that's at throndar.ai/evidence. But the free Action above is enough to answer the question every regulator is about to ask: _where is our quantum-vulnerable cryptography, and what's the plan?_\n\n_Built by TRELYAN Inc. The scanner and CLI are MIT. Feedback — especially false positives/negatives on real repos — is genuinely wanted: open an issue on the repo._",
  "title": "Add a post-quantum readiness gate to your CI in 5 lines"
}