I scanned popular open source projects for quantum-vulnerable crypto. Here's what I found.

PostQuant — Wed, 04 Mar 2026 19:13:54 +0000

NIST is deprecating RSA, ECC, and other classical cryptographic algorithms by 2030 and disallowing them entirely by 2035. The reason: quantum computers will eventually break them.

I wanted to know how exposed my own projects were. So I built PostQuant

(https://github.com/postquantdev/postquant), a CLI that scans TLS endpoints and source code for quantum-vulnerable cryptography and gives you a letter grade.

Then I pointed it at some popular open source projects. The results were interesting.

The Scan Results

Frameworks

Project	Language	Grade	Critical Findings	What It Found
Django	Python	D+	2	MD5 in auth hashers, SHA-1 in file uploads
Spring Boot	Java	D+	—	RSA in OAuth2
Node.js	JS	D+	—	Various classical crypto in core
Go stdlib	Go	F	161	Classical crypto throughout standard library
FastAPI	Python	A	0	Clean
Express	JS	A	0	Clean
Gin	Go	A	0	Clean

npm Packages

Package	Grade	Raw Findings	After Context Analysis
uuid	A	4 critical	4 low
express-session	A	2 critical	2 low
node-forge	C+	4 critical	4 critical
pg	D+	4 critical	4 critical
ssh2	D+	18 critical	12 critical

Python Packages

Package	Grade	Raw Findings	After Context Analysis
requests	A	5 critical	3 low
boto3	A	1 critical	1 informational
django	D+	2 critical	2 critical
paramiko	D-	10 critical	10 critical

Why Context Matters

This is the part I'm most proud of. A naive scanner just greps for algorithm names and flags everything as critical. But not all crypto usage is equal.

Take MD5. The uuid package uses MD5 to generate RFC 4122 checksums. That's not a security function. It's a deterministic ID generator. Flagging it as critical is noise.

But Django's auth/hashers.py also uses MD5. For password hashing. That's a real vulnerability.

PostQuant reads the surrounding code to tell the difference. Variable names like password and authenticate signal real security usage. Variable names like checksum and digest signal non-security usage. Same algorithm, different context, different grade.

# With context analysis (default)
npx postquant analyze ./node_modules/uuid
# Result: A (4 findings adjusted from critical to low)

# Without context analysis
npx postquant analyze ./node_modules/uuid --no-context
# Result: D+ (4 critical findings)

How to Scan Your Own Code

No signup, no config:

# Scan source code
npx postquant analyze .

# Scan a TLS endpoint
npx postquant scan yoursite.com

# Show everything including low-risk findings
npx postquant analyze . --show-all

It supports Python, JavaScript/TypeScript, Go, and Java. 54 detection patterns.

Add It to CI/CD

name: PostQuant Scan
on: [push, pull_request]
jobs:
  quantum-check:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - run: npx postquant analyze . --format sarif > postquant.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: postquant.sarif

Findings show up in GitHub's Security tab alongside CodeQL results.

Why Now

"Quantum computers are decades away" is the common response. Maybe. But:

NIST has already published the replacement standards (ML-KEM, ML-DSA, SLH-DSA)
The deprecation timeline is set: 2030 deprecate, 2035 disallow
"Harvest now, decrypt later" attacks mean data encrypted today with RSA can be stored and cracked later
Migration takes years for large codebases

The question isn't whether to migrate. It's whether you know what needs migrating.

PostQuant on GitHub — MIT licensed, contributions welcome.

DEV Community: PostQuant