Trivy found 243 findings in TerraGoat — Bridgecrew's reference IaC repository.
243 findings. That's a lot of work.
Zero of those findings were cryptographic.
pq-audit found 4 that Trivy missed entirely.
This isn't a post about Trivy being bad. It's about a structural gap in how security tooling models risk — and why cryptographic lifetime is the blind spot that nobody is talking about yet.
The gap nobody talks about
Most security scanners operate on a binary: a configuration is correct or it isn't.
A CVE is present or it isn't. A secret is exposed or it isn't.
They don't model time.
Cryptographic algorithms have a lifecycle. MD5 was broken in 2004. SHA-1 was brokenin 2017. TLS 1.0 is deprecated. These are already compromised — BROKEN_NOW.
But there's a second category that gets almost no tooling attention: algorithms thatare cryptographically sound today but will be broken by quantum computers. ECDSA, RSA-2048, secp256k1 — every blockchain transaction, every TLS handshake, every JWT signed with ES256K. SNDL_VULNERABLE: Store-Now-Decrypt-Later.
The threat isn't theoretical. Sophisticated actors are already harvesting encrypted data today to decrypt when Cryptographically Relevant Quantum Computers (CRQCs) arrive — estimated 2030-2035 by most threat intelligence.
NIST made this official in 2024. FIPS 203 (ML-KEM / Kyber), FIPS 204
(ML-DSA / Dilithium), FIPS 205 (SLH-DSA / SPHINCS+) are the replacements.
CNSA 2.0 mandates migration by 2027 for US government systems.
DORA Art. 9 and NIS2 include cryptographic risk management requirements now.
Your current scanner tells you nothing about any of this.
Two risk tiers that matter
pq-audit classifies every finding into one of two tiers:
🔴 BROKEN_NOW — already compromised today. Fix immediately.
- TLS 1.0 / TLS 1.1
- MD5, SHA-1
- DES, 3DES, RC4
- RSA ≤ 1024 bits
- SSH with deprecated MACs (hmac-md5, hmac-sha1)
🟡 SNDL_VULNERABLE — safe today, broken by quantum computers.
- RSA-2048 (key exchange, certificates, signatures)
- ECDSA / ECDH on standard curves (P-256, P-384, secp256k1)
- DH < 3072 bits
- JWT ES256 / ES256K
- ECDH key exchanges in TLS
The migration path: BROKEN_NOW is urgent. SNDL_VULNERABLE is strategic — but the window to start is now, not when the CRQC arrives.
What pq-audit actually audits: 10 layers
No other open-source tool audits cryptographic posture across all 10 of these layers:
| Layer | What it scans |
|---|---|
| 1. CRYPTO | Weak primitives: MD5, SHA-1, RSA≤2048, DES, RC4, deprecated ECDH curves |
| 2. CODE | Source code patterns (Python, Go, Java, JS/TS) — hardcoded weak crypto |
| 3. SYSTEM | TLS versions, SSH config, x509 certificate analysis |
| 4. DEPS | pip/npm/cargo packages with known weak crypto dependencies |
| 5. DOCKER | Container images with outdated crypto libraries |
| 6. NETWORK | FTP, Telnet, HTTP, SMBv1, LDAP, SNMPv1, legacy protocol exposure |
| 7. SOFTWARE | Digital signatures (.exe, .dll, .docm, .pdf — Authenticode, macros) |
| 8. CLOUD | IaC (Terraform, Kubernetes YAML) with weak crypto posture |
| 9. LINK | URL phishing + email header analysis (SPF/DKIM/DMARC, DKIM-RSA-SHA1) |
| 10. WEB3 | ECDSA in Solidity, ecrecover() off-chain, JWT ES256K, JSON-RPC endpoints, CBOM generation |
Compare this to existing tools:
| Tool | Scope |
|---|---|
| Cryptosense | Code only |
| testssl.sh | TLS/certs only |
| Checkov / tfsec | IaC only |
| TLS Observatory | TLS only |
| pq-audit | All 10 layers — holistic |
The triage problem
243 findings from Trivy is a lot of noise. Security teams don't fix everything — they triage. The problem with crypto findings is that false positives are expensive: you can't tell if a "SHA-1 usage" is in production-critical signing code or in a comment inside a test fixture.
pq-audit includes an optional RAG-based triage pipeline:
Finding → RAG semantic search (context from similar findings)
→ Local LLM analysis (Ollama — nothing leaves your env)
→ Classification: CONFIRMED | FALSE_POSITIVE | NEEDS_REVIEW
This runs entirely offline. No data leaves your machine. The model uses your own knowledge base to contextualize findings, reducing noise before you spend time investigating.
Output format:
{
"layer": "CODE",
"risk": "SNDL_VULNERABLE",
"match": "ECDSA.sign(private_key, message_hash)",
"file": "src/auth/signing.py",
"line": 47,
"triage": "CONFIRMED",
"description": "ECDSA signing — vulnerable to Shor's algorithm on quantum computer",
"remediation": "Migrate to ML-DSA (FIPS 204 / Dilithium) for signatures"
}
Web3/DeFi layer (v1.1)
Every DeFi protocol runs on ECDSA secp256k1. Ethereum, Bitcoin, most EVM chains — the same curve that Shor's algorithm breaks.
The --layer web3 mode detects:
- secp256k1 usage in Solidity, JavaScript, TypeScript
- ecrecover() calls in off-chain smart contract infrastructure
- JWT ES256K in bridge/oracle APIs (common in cross-chain DeFi)
- keccak256 weakened by Grover's algorithm (domain: hash preimage resistance)
- Generates a CBOM (Cryptographic Bill of Materials) per endpoint
- Output compatible with Immunefi bug bounty reporting format
Why does this matter for DeFi now if CRQCs are 2030+?
- Harvest-now-decrypt-later is already happening for high-value financial data
- CNSA 2.0 migration deadlines create regulatory risk for protocols with institutional users
- Immunefi has accepted quantum cryptography findings — there's a bounty surface here
Running it
# Install (zero mandatory external dependencies)
git clone https://github.com/mk-scorpiosec/pq-audit
cd pq-audit
# Basic audit — local directory
python3 pq_audit.py --target /path/to/your/project
# Specific layers
python3 pq_audit.py --target /path/to/project --layers CODE,SYSTEM,DEPS
# TLS/certificate audit of a live endpoint
python3 pq_audit.py --target your-domain.com --layers SYSTEM,NETWORK
# Web3/DeFi audit
python3 pq_audit.py --target /path/to/solidity-contracts --layers WEB3
# Full audit with triage (requires Ollama locally)
python3 pq_audit.py --target /path/to/project --triage --ollama-url http://localhost:11434
# JSON output for pipeline integration
python3 pq_audit.py --target /path/to/project --output json > findings.json
Python 3.10+. No mandatory pip installs for core layers (stdlib only). Triage mode requires Ollama + one lightweight model (gemma2:2b works).
Research: TerraGoat validation
TerraGoat is Bridgecrew's intentionally vulnerable Terraform repository, designed as a reference for IaC security tooling. It's the closest thing the industry has to a standardized benchmark.
Trivy result on TerraGoat: 243 findings. Zero cryptographic.
pq-audit result on TerraGoat:
| Finding | Layer | Risk | What Trivy shows |
|---|---|---|---|
TLS 1.0 minimum in azure/app_service.tf
|
CLOUD | BROKEN_NOW | Not reported |
RSA-2048 cert in aws/acm.tf
|
CLOUD | SNDL_VULNERABLE | Not reported |
ECDH P-256 key exchange in aws/alb.tf
|
CLOUD | SNDL_VULNERABLE | Not reported |
hmac-sha1 MAC in aws/ec2.tf SSH config |
SYSTEM | BROKEN_NOW | Not reported |
These aren't edge cases. They're in the reference repository that security teams use to calibrate their tooling.
Full research data: github.com/mk-scorpiosec/research
Why this matters now
The migration window is real and it's closing.
- CNSA 2.0 (US DoD): mandatory PQC migration by 2027 for national security systems
- DORA (EU financial): Art. 9 requires cryptographic risk management — already in effect
- NIS2 (EU critical infrastructure): includes cryptographic posture in its scope
- NIST FIPS 203/204/205: finalized August 2024 — the replacements are standardized
The "but quantum computers don't exist yet" argument misunderstands the threat model.
You don't need a CRQC to have a problem. You need an adversary with patience and the ability to store encrypted traffic — which sophisticated state actors have had for years.
The organizations that start the crypto inventory now will be the ones that can execute the migration then. The ones that wait will be scrambling when the deadline hits.
pq-audit is the audit step you can run today to understand what you're working with.
GitHub: github.com/mk-scorpiosec/pq-audit
MIT license. Zero external dependencies for core layers.
Questions about specific threat models, Immunefi/bug bounty applications, or enterprise compliance use cases — happy to discuss in comments.













