QuantumReadyWhat the scanner actually detects
Generated from the rule set in the engine itself, so it cannot drift from what the software does. Below that is an honest map of what we cover against the areas the CSA Handbook asks organisations to work through, including where we do not yet reach.
Two kinds of reading happen. Every language family below is read by pattern: algorithm names, provider calls, configuration directives and certificate material, with language specific rules scoped to the files they were written for. Eleven families, Java and Kotlin, JavaScript, TypeScript, Python, Go, Ruby, PHP, Rust, C#, C and C++, and PowerShell, are also parsed in the local scanner and in expanded hosted deployments, where the call itself is read: the algorithm, its mode and its padding come from the arguments rather than from the text around them, a name assembled from constants is resolved, and a cipher whose algorithm cannot be known from source is reported as a named review item instead of as a claim.
The engine is ours. QuantumReady Discovery Engine, version checking, written in house and not a rebadged third party scanner. The rules, the classifier and the risk model are our own work. Where other tools are also used, such as running syft, trivy or gitleaks that you already have installed, or importing a CycloneDX bill of materials from a scanner you already own, the report records which tool produced each asset, so provenance is never blurred. A separate page sets out exactly what is ours and what is not.
The six layers of an estate, and where we reach today
Cryptography lives in more places than source code. This is the full picture, with our current position stated honestly rather than aspirationally.
| Layer | What lives there | Where we stand today |
|---|---|---|
| 1. Repository | GitHub, GitLab, Bitbucket. Libraries, crypto calls, algorithms, dependency files. | Covered Hosted scan for public repositories, and the offline runner for private ones, including on GitLab.com and self-managed GitLab over their API pattern. |
| 2. Build and artifact | JAR, WAR, binaries, package output. What actually made it into the build. | Covered by the runner qr-run artifact app.jar opens the built file, lists every entry, finds bundled crypto libraries, certificates and keystores, reads manifest and configuration text, and recurses into nested archives such as JARs inside a WAR. |
| 3. Container | Docker and OCI images. OS libraries, OpenSSL, Java runtime, packages, certificates. | Covered by the runner qr-run image image.tar on output from docker save. Reads the manifest and image config, walks every layer, and reports the OpenSSL builds, trust stores and packages that arrived through the base image. |
| 4. Infrastructure | Servers, Kubernetes, load balancers, TLS and SSH configuration. | Partial Configuration as code is covered when it is in the repository: nginx and Apache TLS directives, Kubernetes TLS secrets, Terraform TLS resources, WireGuard keys. Running infrastructure is not reachable from our vantage point. |
| 5. External endpoints | api.company.com and friends. Public TLS, certificate keys, cipher configuration. | Covered Partial protocol probes plus completed TLS 1.3 and TLS 1.2 sessions, certificate inventory and separate trust checks. Raw retry requests do not confirm an established hybrid exchange. Revocation and cipher enumeration remain explicitly scoped. Note the Cloudflare limitation: our own cloud vantage point cannot dial Cloudflare's edge, which is what the offline runner exists to solve. |
| 6. Data systems | Databases, queues, storage. Encryption configuration, not the data itself. | Deliberate non-goal We read the cryptography around a data store, such as a connection string naming TLS or a config file naming a keystore. We do not connect to databases and we do not read business data. That is a design choice, and it is a selling point. |
Coverage against the Handbook areas
The CSA Quantum-Safe Handbook is organised into five areas. Here is what our tooling genuinely does in each, and what it does not. We are not the official QRI, and this is not a compliance statement.
| Area | What the Handbook asks for | What we do | Verdict |
|---|---|---|---|
| Domain 1: Risk assessment | Identify crown jewels, run cryptographic asset discovery on the highest risk systems first. | Automated discovery across code, configuration and endpoints, plus a crown jewels register with the exposure arithmetic in the workbench. | Partial We do not do business impact analysis or threat modelling for you. |
| Domain 2: Governance | Name an accountable owner, keep the inventory current, set policy, plan procurement and refresh. | Owner register, cryptographic policy generator, the three CSA milestone dates, a twelve point agility checklist, and a vendor register. | Partial We produce the documents. We do not enforce policy, run approvals, or sit in your governance forum. |
| Domain 3: Technology | Identify replacement algorithms, understand performance trade-offs, maintain crypto-agility. | Per-algorithm findings with a recommended replacement, migration waves, and the interoperability questions to settle before committing. | Strongest area We do not configure your systems, manage keys, or run the migration. |
| Domain 4: Training and capability | Brief leadership, build staff capability, review internal policies. | A leadership briefing outline and a role based capability register. | Minimal We generate the outline. We are not a training provider. |
| Domain 5: External engagement | Contact key vendors for post-quantum roadmaps, embed requirements into procurement. | A vendor register and a post-quantum request letter with the seven questions that change a timeline. | Partial We draft the ask. We do not contact your vendors. |
There is also a human dimension we cannot automate, and the Handbook says so too: some requirements need attestation, documentation and judgement. Paid assessments include a review step for exactly that reason.
Languages and file types read
| Loading... |
Detection rules
Every rule in the engine, with the algorithm it reports and how it is classified. This table is generated from the code, so it reflects exactly what runs.
| Rule | Reports | Category | Classification | Patterns |
|---|---|---|---|---|
| Loading... | ||||
Local scanner limits
These are the local source scanner limits. The hosted scanner has the smaller budget stated on the scan page and in every hosted report.
| Loading... |
Anything not read is counted and reported in every scan, never silently dropped. Files that contain no cryptographic keyword at all are skipped after one cheap pass, and findings in tests, examples and documentation are separated from production code and excluded from the score.
What this scanner cannot do
- The hosted cloud scanner reads source only. Reading built artifacts and container images needs the offline runner, because those files have to be opened where they sit.
- Syntax reading covers eleven language families. The rest of the twenty two are matched by pattern, so in those a name assembled from constants or a cipher chosen at runtime is out of reach.
- Inside a container image we read file names, sizes and text configuration. We do not disassemble compiled binaries, so we report that a particular OpenSSL version shipped rather than which algorithms inside it are in use.
- We do not connect to running systems, databases or key stores, so we cannot tell you what is configured in production right now.
- Matching text misses dynamically constructed algorithm names, reflection, generated code and encrypted configuration, and the parse narrows that gap rather than closing it: what it cannot resolve it names as a record instead of guessing.
- A finding proves a pattern exists in a file. It does not prove the code path runs, or that the algorithm protects anything important.
- It cannot establish regulatory compliance. Nobody's scanner can. That needs attestation, documentation and human review.