SOLUTIONS · USE CASE
Cryptographic Discovery for Code Repositories
Cryptographic discovery for code repositories is the process of finding which cryptographic algorithms an organisation’s source code actually calls, and which of them are quantum-vulnerable. Quantum Sentinel scans GitHub, GitLab, Bitbucket and Azure DevOps repositories across seventeen languages, reporting the algorithm, the file, the line and the enclosing function for every finding.
Cryptography in your code is cryptography you own
Everything else in a cryptographic inventory is configuration. A TLS endpoint negotiates what its library offers. A certificate is what a CA issued. You can change most of it without touching a codebase.
Cryptography written into source code is different. It is a decision somebody on your team made, it will not change because a library updated, and migrating it means a change, a review, a test cycle and a release. On a post-quantum timeline, the cryptography in your own code is the part with the longest lead time and the least visibility.
It is also where the awkward findings live. An RSA key size hardcoded eight years ago. A hash function chosen when it was still fine. An initialisation vector that was meant to be random and is a row of zeroes.
What the scanner flags
Quantum Sentinel applies close to 50 detection patterns to every line of source it walks, across four risk levels.
Critical. DES and 3DES, RC2, RC4, MD5, SHA-1, DSA, and RSA at 512, 768 or 1024 bits, including the Python key_size= and Java RSAKeyPairGenerator forms that state the size in code rather than in the algorithm name.
High. ECDH, ECDSA and ECC generally, NIST P-curves, Curve25519 and Ed25519, Diffie-Hellman, and RSA-2048. These are not broken. They are quantum-vulnerable, which is a different statement and the one that matters for a migration plan.
High: hardcoded initialisation vectors and nonces. A predictable IV or nonce is a classical implementation defect rather than a quantum one, and it is usually the most immediately actionable thing a scan finds. Under CBC it leaks plaintext structure; under a counter mode such as CTR or GCM, a reused nonce can surrender the plaintext and the key. The scanner catches the common giveaways: a Java IvParameterSpec built from an unfilled byte array, a variable named iv or nonce assigned a hex literal, a Buffer.alloc or bytes(n) that is never filled with randomness, a literal passed straight into Node’s createCipheriv, and pycryptodome’s AES.new(key, AES.MODE_CBC, b'...'). When a line contains both a static IV and an algorithm name, the static IV wins, because it is the more urgent finding.
Medium. AES in CBC or ECB mode, AES-128, Blowfish and Twofish.
Low and informational. AES-256, AES-256-GCM and CCM, SHA-256, SHA-384 and SHA-512, SHA-3, ChaCha20, Poly1305, Argon2, bcrypt, scrypt, HKDF and PBKDF2.
And the post-quantum algorithms you have already adopted. ML-KEM and Kyber, ML-DSA and Dilithium, Falcon, SPHINCS+, FrodoKEM and Classic McEliece are detected too. An inventory that only counts what is broken cannot show progress. This one can show both sides of the migration.
Findings you can act on without a second investigation
Each finding records the repository, the file path, the line number, the matched line trimmed to 200 characters, the canonical algorithm name, the key size where it can be determined from context, the language, the risk level, and the enclosing function or method name where it can be detected.
That last field is the difference between a finding an engineer can pick up and a finding somebody has to go and research. "RSA-1024 at crypto/legacy.go:214 in signPayload" is a ticket. "RSA-1024 somewhere in this repository" is an afternoon.
Seventeen languages, and sensible exclusions
The scanner walks 21 file extensions covering seventeen languages: Go, Python, Java, JavaScript, TypeScript including JSX and TSX, C#, C, C++ and their headers, Ruby, PHP, Rust, Kotlin, Swift, Scala, Objective-C, and the smart contract languages Solidity and Vyper.
It skips what you would want it to skip: node_modules, vendor, .venv, __pycache__, dist, build, target, .gradle and the version control directories themselves. Commented-out lines are skipped too, so a disabled call to a broken cipher does not inflate your figures. Files above 2 MB are skipped by default, which keeps generated and vendored blobs out of the results. The point is an inventory of cryptography your team owns, not of every dependency ever pulled in.
How it connects
Quantum Sentinel connects to GitHub, GitLab, Bitbucket and Azure DevOps over HTTPS. GitHub, GitLab and Azure DevOps authenticate with a personal access token; Bitbucket uses an account username paired with an app password, which is Bitbucket’s own equivalent. Read access is enough in every case. Self-hosted instances are supported, because the clone URL is yours to specify.
The scan performs a shallow, single-branch clone with no tags: it takes the current state of one branch, not your repository’s history. You can name the branch or let it use the remote default. The working copy is temporary and exists only for the duration of the scan.
Two honest consequences of that design, both worth stating plainly:
- Git history is not scanned. A key that was committed and later removed will not be found by this scanner. That is a job for a secret-scanning tool, and it is a different job.
- The scanner reads lines, not data flow. It reports the cryptography a line of code names. It does not trace a variable across functions to prove a nonce is genuinely reused. Where an idiom is safe in practice, such as Go’s
make([]byte, n)followed byrand.Read, it is deliberately not flagged rather than filling your report with noise.
Enclosing function names are best-effort. They are recovered by recognising function and method definitions across the common styles, keyword-introduced (func, def, function, fn) and return-type-first (Java, C#, C++). Where a definition does not match those shapes the field is simply left empty rather than guessed at.
This is inventory, not vulnerability scanning
It is worth being precise about what this is, because it sits next to tools that look similar.
A SAST tool asks whether your code has an exploitable flaw. This asks a different question: which cryptographic algorithms does your code use, where, and what is their quantum exposure. AES-256-GCM is not a vulnerability, and this scan reports it, because a cryptographic inventory that only lists problems is not an inventory.
The output is a contribution to your CBOM. Repository findings sit alongside network TLS, PKI, HSM, cloud KMS, database and file share findings in one inventory, which is what a regulator asking for a cryptographic inventory is actually asking for.
Frequently asked questions
Which repository platforms are supported?
GitHub, GitLab, Bitbucket and Azure DevOps, over HTTPS. GitHub, GitLab and Azure DevOps authenticate with a personal access token; Bitbucket uses a username and app password. Self-hosted GitLab and other self-hosted instances are supported, since you specify the clone URL.
What access does the scanner need?
Read access to the repositories you want scanned, and nothing more. GitHub, GitLab and Azure DevOps use a personal access token; Bitbucket uses a username and app password. Scope the credential to read-only.
Is our source code copied or retained?
The scanner performs a shallow single-branch clone into a temporary working copy for the duration of the scan, and what it records is the finding: file path, line number, the matched line trimmed to 200 characters, algorithm, language and risk level. The working copy does not persist.
Which languages are supported?
Go, Python, Java, JavaScript, TypeScript, JSX, TSX, C#, C, C++, Ruby, PHP, Rust, Kotlin, Swift, Scala, Objective-C, Solidity and Vyper.
Does it scan Git history?
No. It scans the current state of the branch you select. Finding credentials that were committed and later removed is the job of a secret-scanning tool, which is a different problem from cryptographic inventory.
How is this different from a SAST tool?
A SAST tool looks for exploitable flaws. This builds an inventory of cryptographic usage, including algorithms that are perfectly sound, so you can see your whole cryptographic surface and plan a post-quantum migration against it.
Does it detect post-quantum algorithms too?
Yes. ML-KEM and Kyber, ML-DSA and Dilithium, Falcon, SPHINCS+, FrodoKEM and Classic McEliece are all detected, so the inventory shows migration progress rather than only migration debt.
How does it handle monorepos?
Files above 2 MB are skipped by default and common generated and dependency directories are excluded, which keeps a large repository’s results focused on code your team owns.
See what your code is actually using.
Point Quantum Sentinel at one repository and see the inventory it produces. Request a demo.