Quantum readiness: find the crypto quantum will break.
Source intelligence reads your code and committed files for the cryptography a quantum computer is expected to break, and the weak choices that are already broken today. Each finding names where it is, why it is weak, what to use instead and NIST's dates.
Quantum-vulnerable cryptography is the public-key cryptography that Shor's algorithm breaks: RSA, DSA, Diffie-Hellman and elliptic-curve keys, signatures and key exchange. NIST's draft transition guidance (IR 8547) deprecates it after 2030 and disallows it after 2035. Replacing it starts with an inventory of where your applications use it. NightVision builds that inventory from source, and reports each quantum-vulnerable and weak choice beside the API spec it generates.
Traffic recorded today can be decrypted later.
An attacker who records encrypted traffic now can decrypt it once a large enough quantum computer exists, so key exchange and encryption are the urgent part. Certificates, tokens and signing keys need a plan too. A scanner outside the app sees only the TLS handshake. It does not see the RSA key committed to the repo, the JWT signing algorithm set in code, or the cipher mode a library call picks by default.
Where your cryptography is chosen
In code and settings
Algorithms, modes, key sizes, padding and verification settings handed to cryptography and JWT libraries such as hashlib, pyca/cryptography, PyCryptodome and PyJWT, and framework settings such as Django password hashers and JWT algorithms.
In committed files
Private and public keys, certificates and SSH keys in the repo, and the TLS protocol and cipher settings in nginx, Apache and OpenSSL configuration.
In dependencies
The cryptography libraries your manifests pull in, and standard algorithms implemented by hand in the tree instead of taken from a validated library.
A finding your team can act on
Where it is
The file and line, and the function it sits in.
Why it is weak
Broken, deprecated, misused or quantum-vulnerable, with the NIST or IETF reference.
What to use instead
ML-KEM or ML-DSA for a quantum-vulnerable use, AES-GCM for ECB, TLS 1.2 or later.
When it expires
NIST's deprecation and disallow years, where NIST has scheduled them.
Findings keep the same fingerprint when code around them moves, so you can track them from one run to the next.
Not only quantum: what is already broken
The same pass reports choices that are weak today: MD5 and SHA-1 where they protect a secret, DES and RC4, ECB mode, an IV written into the source, short RSA keys, TLS 1.0 and 1.1, JWT signed with "none", and certificate or token verification turned off. AES with 128-bit keys or more, ChaCha20 and SHA-256 and above are not flagged, so the report stays on what needs a change.
It tells you what it did not read
Code analysis covers Python today. Committed keys, certificates, TLS configuration and dependencies are read whatever the language. When a run cannot cover part of the tree, the report says so and lists the gaps, so a short report is never mistaken for a clean one. A finding never holds key material, only an algorithm, a size or a curve.
Part of source intelligence in the NightVision CLI
Add --weak-crypto to nightvision openapi extract and the report is written beside the generated API spec. Run it on a laptop or in your pipeline, and add --no-upload to keep the report on your machine. Viewing and tracking these findings in the NightVision platform is in development.
Source intelligence also maps your API routes from source code, flags hardcoded credentials, and marks the routes that call a language model for AI endpoint testing.
Quantum readiness questions, answered.
What is quantum-vulnerable cryptography?
Public-key cryptography that a large quantum computer running Shor's algorithm is expected to break: RSA, DSA, Diffie-Hellman, ECDH, ECDSA and EdDSA, including JWT signing algorithms such as RS256 and ES256. Symmetric ciphers such as AES with 128-bit keys or more, and hashes such as SHA-256, are not in that group.
When does quantum-vulnerable cryptography need to be replaced?
NIST's draft transition guidance, NIST IR 8547, deprecates quantum-vulnerable algorithms after 2030 and disallows them after 2035. Because the guidance is still a draft, each NightVision report records the version of the classification that assessed it.
What should we replace it with?
NIST has standardized ML-KEM (FIPS 203) for key establishment and ML-DSA (FIPS 204) for signatures. Each NightVision finding names the replacement for the choice it found.
Which languages does NightVision cover?
Code analysis covers Python today. Committed keys, certificates, SSH keys, the TLS settings in nginx, Apache and OpenSSL configuration, and the cryptography libraries your dependency manifests pull in are read whatever language the application is written in.
Does the report contain our keys?
No. A finding records an algorithm, a key size or a curve, never key material.
Is this in the NightVision platform?
It runs in the NightVision CLI today, as a report written beside the API spec that source intelligence generates. Viewing and tracking these findings in the NightVision platform is in development.
Start your cryptography inventory from source.
Find the quantum-vulnerable and weak cryptography in your applications, with a fix for each, then test the running apps with NightVision web app DAST.