Offline quantum-readiness discovery CLI

Find cryptographic clues. Build a better inventory.

Explore how QuantumSafe Scanner identifies supported source patterns and local dependency declarations, producing observations for human review and post-quantum migration planning.

For SaaS engineering teams and SMEs with custom applications that need a bounded starting point for quantum-readiness planning. Agree authorization, supported languages, and evidence handling before scanning.

Laboratory prototype · Synthetic report demonstration
Local v0.2.0 prototype · public downloads unavailable
Findings do not establish complete coverage, runtime use, compliance, or production readiness. Public executable downloads are currently unavailable.

Inspect the sample report ↓Read the getting-started guide ↗

Illustrative interface concept · not a live product or customer system

What v0.2.0 discovers

v0.2.0 uses file-local analysis and reviewed catalogs. Listed file types are candidate inputs, not a promise that every construct or cryptographic use is detected.

Reviewed cryptographic API usage in supported source files, using file-local analysis.
Recognized direct local dependency declarations by default; selected local lockfile evidence is optional.
Console, JSON schema v2, and SARIF 2.1.0 reports with coverage and warning details.

Supported inputs, within a versioned boundary

Go

Source files: .go
Local dependency evidence: go.mod

Python

Source files: .py / .pyi
Local dependency evidence: pyproject.toml / requirements*.txt

JavaScript

Source files: .js / .jsx / .mjs / .cjs
Local dependency evidence: package.json

TypeScript

Source files: .ts / .tsx / .mts / .cts
Local dependency evidence: package.json

Java

Source files: .java
Local dependency evidence: pom.xml / Gradle

C#

Source files: .cs
Local dependency evidence: MSBuild project/props XML / packages.config

Direct declarations by default; recognized local lockfiles are optional. Literal declarations only where supported; unknown or dynamic structures generate warnings.

Detection categories include classical public-key algorithms, symmetric encryption, hashes, TLS/X.509 API evidence, KDF/MAC/RNG, PQC, and hybrid patterns. TLS/X.509 source observations are not certificate or network scans.

Generated files and common vendor/build directories are skipped by default. TypeScript declarations are skipped unless explicitly included. Ignores, filters, parse limits, and warnings affect coverage. Local lockfile evidence is partial; no complete dependency graph, CVE analysis, SBOM, or CBOM is produced.

Synthetic laboratory sample · not a customer result

A finding you can inspect

This excerpt comes from the included six-language sample report. Complete coverage means its supported candidate inputs were analyzed; it does not mean a complete system inventory.

Synthetic laboratory sample · not a customer resultv0.2.0 / JSON schema v2

Observed evidence High severity

RSA usage

Crypto.cs · Line 8

Recorded observationcall System.Security.Cryptography.RSA.Createdirect-api-usage

Rule: QS1001
Algorithm: RSA-2048
Detection confidence: 0.99

Confidence describes the detection, not the probability that a deployed system is unsafe.

[01] Why it matters

This observation starts a review of public-key cryptography. Its purpose and the surrounding protocol determine which migration questions to ask.

[02] What remains unknown

Source presence does not establish deployed use, data confidentiality lifetime, or provider support. Human review must confirm the system context before choosing a change.

Read the original scanner recommendation

Original report text

RSA usage detected

Determine whether this RSA use provides key establishment, encryption, signatures, or another function. Assess ML-KEM for key establishment and ML-DSA or SLH-DSA for signatures only after confirming protocol and provider support.

NIST FIPS 203 — ML-KEM ↗ final
NIST FIPS 204 — ML-DSA ↗ final
NIST FIPS 205 — SLH-DSA ↗ final
NIST FIPS 186-5 — Digital Signature Standard ↗ final
NIST IR 8547 — Transition to PQC Standards ↗ draft

This excerpt comes from the included six-language sample report. Complete coverage means its supported candidate inputs were analyzed; it does not mean a complete system inventory.

Open the full synthetic JSON report ↗

Read one observation in context

Synthetic laboratory sample · not a customer result

package.json:4
QS7001
declaration npm:jose
jose ^6.0.0

Open the full synthetic JSON report ↗

Observed: The synthetic manifest finding below names a local dependency declaration. Its location, rule, and symbol are copied from the report.
Interpretation: A recognized cryptographic package is a candidate for inventory follow-up. Declaration alone is not evidence of actual algorithm use.
Not established: Execution, reachability, vulnerability, quantum resistance, and wider system readiness remain unverified.
Next investigation: Ask the application owner whether the package is used, which callers can reach it, and what cryptographic roles it serves.
Disposition: Illustrative status: unresolved pending owner review. Retain, correct, or mark unresolved after review; the scanner has not made that decision.

From authorized input to reviewed evidence

01
Authorize local input
Agree repository ownership, permitted files, access boundaries, and evidence handling.
02
Analyze supported inputs
Use an approved executable in a least-privilege environment. File-local source and recognized local dependency analysis do not establish runtime behavior.
03
Read structured findings
Inspect report versions, coverage, warnings, filters, and locations before interpreting individual observations.
04
Review with an owner
Confirm purpose, reachability, dependency use, and uncertainty with the responsible system owner.
05
Update the inventory
Retain reviewed observations, correct misinterpretations, and record unresolved questions or assessment candidates.

Understand the report before acting

Rule and location: Rule identifiers name a detection rule, not a vulnerability ID. Relative paths and source regions identify the observation location.
Evidence type: Source patterns and dependency declarations carry different meaning. Neither automatically proves deployed use.
Severity: A rule-based review signal, not an organization’s risk rating or a confirmed vulnerability. Interpret it with purpose, exposure, and data lifetime.
Confidence: Detection confidence reflects the scanner’s evidence interpretation. It is not an organization’s readiness percentage or a probability that a deployed system is unsafe.
Review flags and recommendations: requiresReview identifies the need for human review. Recommendations suggest investigation; they are not an automatic replacement or deployment instruction.
Coverage and warnings: Check coverage.complete, skipped inputs, warnings, suppressions, and filters. Even complete processing of supported candidate files is not a complete system inventory.

A recognized pattern may not represent reachable cryptographic use. Wrappers, dynamic behavior, unsupported syntax, indirect dependencies, or unknown catalog entries can also be missed. Review both findings and gaps.

Keep evidence types distinct

Source-pattern observation: A supported API pattern recognized in a local file; operational behavior needs separate confirmation.
Dependency declaration: A recognized local package coordinate; use and reachability are not inferred.
Synthetic sample: Constructed data demonstrating report behavior; not a customer result.
Laboratory test result: A result from a specified test and environment; not automatically production assurance.

From finding to migration decision

Business ownership, data retention, vendor readiness, and migration feasibility require separate supplied evidence and human review. A scoped engagement can produce reviewed findings, evidence gaps, and prioritized follow-up actions.

Scoped cryptographic inventory ↗Readiness assessment ↗

How to evaluate the evidence

Repository documentation describes synthetic fixtures with expected positive and negative patterns, parser and binding checks, schema checks, and coverage warnings. These test a defined implementation boundary; they are not a representative production dataset or a published precision/recall benchmark. No detection-rate or performance claim is made here.

Version and report compatibility

v0.2.0 / JSON 2.0.0: The displayed sample uses the six-language source and local dependency model. Console and SARIF 2.1.0 outputs are also documented.
Legacy schema v1 mode: An explicit Go-only compatibility mode retains the earlier contract and disables dependency discovery. It is not the sample displayed here.

Compare scanner, ruleset, knowledge, parser catalog, dependency catalog, and schema versions when comparing reports. Finding counts can change with catalogs even when the schema remains compatible. Breaking report semantics require a new schema; do not assume arbitrary future versions are interchangeable.

Customer distribution awaits release verification and approved distribution terms. You can review the sample and discuss an assessment scope.

Local analysis, with explicit handling boundaries

The current CLI does not open runtime network connections, send telemetry, compile or execute customer code, or invoke package managers. External wrappers, CI agents, report storage, and your operating environment can still transmit data outside the scanner’s control. Reports include relative paths and cryptographic metadata and should be treated as sensitive. This website accepts no repository or report uploads; inquiry details have separate Supabase and LINE handling.

Read the website privacy policy ↗

Questions before using scanner evidence

Does a finding mean the system is vulnerable?

No. It is an observation that needs context and human review. Source presence does not establish execution, exposure, or a confirmed vulnerability.

Does an empty report mean the system is ready?

No. Check supported inputs, skips, warnings, suppressions, and filters. Undetected patterns and dependencies may remain.

Does a declared dependency prove it is used?

No. A local declaration does not prove runtime use, reachability, or the algorithms selected by the application.

Can the scanner inspect deployed infrastructure?

No. It does not scan runtime systems, networks, certificates, configuration, binaries, or cloud environments.

Does it upload source code or contact external services?

The current CLI has no runtime networking or telemetry. External wrappers, CI agents, storage, and the operating environment remain outside that boundary. Website inquiries use separate provider handling.

Can visitors download or run it today?

Public executable downloads are unavailable. The guide describes the workflow for an approved executable; it is not a public installation offer.

How should sensitive reports be handled?

Agree access, recipients, storage, and retention before collection. Do not submit repositories, keys, credentials, or confidential reports through this website’s inquiry form.

Use the observation to ask a better question.

Tell us which system or migration decision you want to explore. Keep the first inquiry high-level; do not submit credentials, private keys, secrets, or confidential reports.

Discuss a repository assessment ↗