Most crypto-inventory tools assume one clean, modern codebase. African fintech infrastructure rarely looks like that — a COBOL or legacy Java core, a modern API middleware layer bolted on top, a PHP admin portal, a mobile client, often four different teams with four different crypto postures. CryptoRadar scans all of it together.
The approach: deliberately regex-based rather than full AST parsing. A scanner that works today across Java, Kotlin, COBOL, JS/TS, Python, PHP, Go, C#, and config files beats a perfect-but-single-language one for a first-pass inventory — especially when a COBOL core is in scope and no mainstream AST tooling covers it well.
The bug worth sharing: Java names signature algorithms as one concatenated token — SHA256withRSA, SHA1withECDSA — with no separator between the hash and the algorithm. Standard word-boundary regex matching cannot match inside that token from either side. I verified this empirically against six real compound-algorithm strings before trusting the fix: all six produced zero findings under the old pattern set. This is arguably the single most common way Java names a signing algorithm, so it was a real coverage gap, not an edge case. Fixed with a dedicated compound-token signature rather than patching the existing patterns with lookbehind hacks.
The other fix: comment-masking. A // comment describing legacy crypto fired the same finding as the real code beneath it — in one case, a file with no actual legacy crypto at all produced a pure false positive sourced entirely from a comment. Built a single-pass, offset-preserving masker that strips comment content but leaves string literals untouched, so a hardcoded secret inside a quoted string is still caught.
Real results: ran the updated scanner against a production-shaped fintech codebase (11 microservices, 676 files). Before: grade F, 26.4%, 10 Critical findings (a hardcoded secret shared across ten services). After rotating that secret and re-scanning: grade D, 31.4%, zero Critical findings — confirmed as genuine remediation, not a scanner artifact, by independently checking the updated scanner still detects the original secret pattern when present.
Try it:
pip install "git+https://github.com/bennybriel/cryptoradar.git@v0.2.0"
cryptoradar scan-multi "legacy-core:demo_repo/legacy-core-java" "api-layer:demo_repo/api-layer-node" "mobile-adapter:demo_repo/mobile-adapter-python" "pqc-pilot:demo_repo/pqc-pilot-service" -o demo_report.html
MIT licensed. Feedback on the detection approach, and any false positives or false negatives you find, genuinely welcome — link to the repo below.
Backend
Source:https://dev.to/bennybriel/i-built-a-crypto-agility-scanner-then-found-a-detection-gap-in-it-worth-sharing-49kp
I built a crypto-agility scanner, then found a detection gap in it worth sharing
dev.to Java0 views
PreviousWhat If Reactive Execution Doesn't End at Rendering?NextWiring PostgreSQL LISTEN/NOTIFY to a Kotlin Multiplatform Mobile Client
Related posts
A tampered Claude Code extension, five broken coding-agent browsers, and agents nobody owns
0dev.to

What Is Danmaku? How to Download Bilibili Bullet Comments and Find Any Video's Highlight
0dev.to

Whoever takes your old GitHub name gets your MCP namespace
0dev.to

What Is Danmaku? How to Download Bilibili Bullet Comments and Find Any Video's Highlight Of Bilibili
0dev.to
Low-Cost Property Ticket Summarization — Token Reduction Strategies in Node.js
0dev.to

Passing once is not the same as being reliable
0dev.to