How Scanning Works
Shorstop reads a public GitHub repository and produces an inventory of the cryptography in it. This page explains how that inventory is built, how to check any part of it, and where it stops. Current scanner: shorstop-grep@0.2.0.
What Shorstop gives you
A categorised list of every cryptographic algorithm named in a repository's source, with the file and line for each one, grouped by whether it is quantum-vulnerable, already weak, quantum-safe, or post-quantum. You can export the whole thing as a CycloneDX CBOM.
It is reliable at what it is built for: finding named algorithms and recognisable cryptographic API calls, across every common language, in one pass. If a file we scan writes RSA, ECDSA, AES-256 or ML-KEM in its source, Shorstop will find it and tell you where.
That is deliberately the first step, not the last one. Knowing what cryptography you have is what every published migration timeline asks organisations to do first — see migration timelines below.
How detection works
One shared rule set — algorithm names, cryptographic API call patterns, library imports, curve and OID strings — is applied line by line to every source file, in every language, identically. Each match is then classified into a security category.
Applying one rule set uniformly is a deliberate choice. It makes results comparable across languages by construction, rather than letting coverage depend on which language happened to receive the most attention. A Go repository and a C repository are read the same way.
What is scanned, and what is not
Scanned: source files in JavaScript and TypeScript, Java, Kotlin, Scala, Groovy, Python, Ruby, Go, Rust, C, C++, C#, PHP, Swift, Objective-C and COBOL, plus certificate and key files — on the repository's default branch, at the commit shown on the results page.
Not scanned: these directories are skipped wherever they appear in the tree.
node_modules.git.nextdistbuildcoverage__tests____test__testtestsspecspecs.vscode.ideavendorfixturesflow-typedscripts
Note this excludes test directories, not test files — crypto_test.go beside the code it tests is still scanned. Every results page reports how many files it read against how many exist, so the gap is a number you can see rather than something you have to assume.
Also not read today: documentation (Markdown, plain text), assembly (.S, .asm), build scripts (.pl, .cmake) and configuration formats (.cnf, .yaml). Cryptography implemented in hand-written assembly, or selected only in configuration, is therefore not currently visible.
Git submodules are not scanned. Shorstop reads a repository archive and archives do not carry submodule contents. Where a project keeps cryptography in a submodule, the results page says so on that scan.
How to read a finding
Take a single row from a scan of a Go library:
Shorstop matched ECDSA, classified it as quantum-vulnerable because Shor's algorithm breaks elliptic curve signatures given a sufficiently large quantum computer, and recorded the file and line.
Every finding links to that exact line on GitHub. That link is the point: you never have to take our word for a result. If a finding looks wrong, one click shows you the code that produced it, and you can tell us so.
What Shorstop does not know is context — whether that code path is reachable, what it protects, or whether the project already plans to replace it. A finding is a place to look, not a verdict.
Where it is strong, where it is weak
Strong on breadth and consistency: one pass finds named algorithms across every supported language, and two repositories in different languages are measured the same way.
Weak in two directions, both worth knowing:
- It matches text, so some matches are not live code. Comments and commented-out code are read, example code is treated like production code, and a variable named
desKeycan match. In a library that implements an algorithm on purpose, those matches are the point rather than a problem. - It only sees what is written literally. An algorithm chosen through a variable, a configuration value or a dependency will not appear, and neither will anything in the file types listed above. A quiet result is not proof of absence.
Both are inherent to a text scan, and both are why the file and line accompany every finding: the fastest way to resolve either is to look.
Migration timelines
Several governments have published deadlines for moving off quantum-vulnerable cryptography. They differ in dates, but not in where they start.
| Jurisdiction | Timeline |
|---|---|
United Kingdom NCSC | 2028 identify cryptographic services and build a migration plan · 2031 high-priority upgrades · 2035 migration complete |
United States NIST IR 8547 | RSA, ECDSA, ECDH and DSA deprecated after 2030 · disallowed after 2035 |
European Union Commission Recommendation | Begin transition by end of 2026 · critical infrastructure by 2030 · as many systems as possible by 2035 |
Australia ASD, Information Security Manual | Cease RSA, DH, ECDH and ECDSA by the end of 2030 — the earliest published deadline |
Every one of these begins with the same step: knowing what cryptography you have. The UK's 2028 milestone is, in NCSC's own words, identifying the cryptographic services that need upgrading — which is exactly what a Shorstop scan produces.
Japan, South Korea and Singapore have reported timelines that we have not linked here, because we could not verify them against a primary government source. We would rather cite four we can stand behind than seven we cannot.
Scope
A Shorstop scan is an automated inventory, not a penetration test, a code audit or a formal security assessment, and it does not replace one. Detection is not exhaustive.
Results are provided as-is. Decisions about the security of a system should be made with appropriate professional advice, using this output as one input among several.