Frequently asked questions
Answers for both a technical and a non-technical reader.
Is my code stored anywhere
No source code is kept. A scan fetches one commit into a temporary directory, reads it, and deletes the directory before responding. What is retained is the findings and the CBOM: file paths, line numbers, the matched line and the algorithm. Only public repositories can be scanned here.
The command-line tool keeps everything on your machine and has no network code in it.
Can I scan a private repository
Yes, with the command-line tool: run crypto-view . in your
checkout and nothing leaves the machine. The website accepts public
repositories only, because it fetches them without credentials.
Why does the scan appear in a public history
So a repository scanned twice can be compared over time. Every entry concerns a public repository at a public commit; the scan adds an assessment, not a disclosure.
What does quantum-safe actually mean here
One specific thing: no known quantum algorithm reduces that primitive below its stated strength. It does not mean the code using it is correct, the key is well managed, or the implementation is free of side channels.
When does this actually happen
Nobody can give a date. What is fixed: NIST published the replacements in August 2024 as FIPS 203, FIPS 204 and FIPS 205, and added HQC in March 2025. US federal guidance sets 2030 and 2035 as planning anchors. Those are recommended dates in guidance, not legal deadlines.
The date that binds you is earlier, for the reason below.
Why is the deadline already past for some data
harvest-now-decrypt-later. An attacker who records encrypted traffic today does not need a quantum computer today; they need one before the data stops being sensitive. If a payload must stay confidential for ten years and a capable machine arrives in twelve, you are fine. If it must stay confidential for twenty, the traffic you send this afternoon is already exposed.
That is why key establishment is ranked above signatures throughout this tool, and why the report counts it separately.
Why is a signature finding treated differently from a key-exchange finding
A broken signature scheme lets an attacker forge signatures from the point they have the machine. It is not retroactive: a signature verified in 2026 was genuine in 2026.
A broken key exchange is retroactive. Traffic recorded in 2026 becomes readable the moment the exchange falls, without touching your systems again. That asymmetry decides what to do first.
Is symmetric encryption affected
Much less than public-key cryptography. Grover's algorithm halves the effective strength of a symmetric key, so AES-128 weakens and AES-256 remains comfortable. Hash functions are similar: SHA-256 keeps a workable margin, SHA-384 restores the full one.
Would RSA-4096 buy us time
No. Shor's algorithm is polynomial in the modulus size, so doubling the key costs performance today and buys nothing. The move is to ML-KEM and ML-DSA, usually alongside the classical algorithm rather than instead of it.
What is a CBOM, and how is it not an SBOM
An SBOM lists the components software is built from. A CBOM lists the cryptography it uses: which algorithms, with which parameters, in which files. An SBOM says you depend on BouncyCastle; a CBOM says you call it with RSA in eleven places.
Is a high score a certificate of compliance
No. It compares a repository against itself over time. No supervisor recognises it, and it does not compare organisations. The formula is published so it is not mistaken for an assessment.
Why does it say "not determinable"
The algorithm is chosen at runtime — the argument to
getInstance() is a variable, or the key type comes from
configuration. Static analysis cannot resolve that, and a guess would put a
wrong entry in the inventory, so it is reported as a gap instead.
This finding is wrong. What do I do
If the pattern fired on something that is not cryptography, that is a bug in a rule — please send the line to contact@qcomply.tech.
If the match is right but not a problem in your context, record the decision in the code:
Suppressed findings are counted and shown in the summary, so the number is never quietly reduced.
The scan found nothing. Are we safe
Nothing was found in the files analysed. Cryptography reached through a compiled dependency, a container image, a managed service or another team's API is outside what a source scan sees.
What should we do first
In this order, and the report is arranged to support it:
- Anything already broken. MD5, SHA-1, DES, RC4, PKCS#1 v1.5 encryption. These fail today and have nothing to do with quantum computers.
- Key establishment protecting long-lived data. This is the harvest-now-decrypt-later exposure, and it is the part where waiting costs you something you cannot get back.
- Certificates and keys with long lives. Not because they are more broken, but because reissuing them is slow. Shortening certificate lifetimes now makes the eventual change routine.
- Signatures. High severity, but the exposure begins when the attacker has the machine, not before.
- AES-128 and SHA-256 in long-lived roles. A parameter change, scheduled rather than urgent.
For key exchange the usual move is hybrid: run the classical algorithm and
ML-KEM together, so the result is no weaker than either.
TLS 1.3 with X25519MLKEM768 and OpenSSH's sntrup761x25519 both
do this today.
How does this relate to FIPS 203, 204 and 205
The NIST standards for the replacements, all published in August 2024. FIPS 203 is ML-KEM for key establishment, FIPS 204 is ML-DSA for signing, and FIPS 205 is SLH-DSA for cases needing a hash-based signature. Every remediation here points at one of them.
Something is not answered here
Write to contact@qcomply.tech.