Keys, certificates and TLS, in any language.
Much of your cryptography is fixed in files you commit, not in code. NightVision reads keys, certificates, SSH keys, server TLS settings and dependency manifests across the whole tree, whatever the application is written in.
Committed keys, certificates and TLS configuration fix cryptographic choices that a code review rarely sees: a 1024-bit root in a CA bundle, a token signing key generated as RSA, an nginx server still offering TLS 1.0. NightVision reads these files in any language and reports each key's algorithm and size, each certificate's signature hash, the TLS protocols and ciphers a server allows, and the cryptography libraries the project ships. A finding never holds the key itself.
One pass over the tree, file by file
The file scan is language-independent. Here is what it reads from a typical service repository, and what it leaves alone.
- payments-service/
- certs/
- server.crtThe public key and signature hash of each certificate, PEM or DERread
- ca-bundle.pemOnce per kind of certificate, with a count. Trust-store CA keys are not flagged as quantum-vulnerableread
- keys/
- jwt-signing.keyThe key's algorithm and size or curve. Never the key itselfread
- deploy/
- nginx/site.confssl_protocols, ssl_ciphers and their proxy_ formsread
- openssl.cnfMinProtocol and CipherString of the profiles the file appliesread
- authorized_keysEach SSH key line's algorithm and sizeread
- web/
- package.jsonShipping dependencies on a cryptography library outside the approved setread
- src/utils/hash.jsA hand-written MD5, recognized by its constantsread
- requirements.txtShipping Python dependenciesread
- requirements-dev.txtDevelopment dependencies do not shipskipped
- tests/fixtures/test.pemNo deployment uses a test fixture's keyskipped
The algorithm and size, never the secret
Private, public and SSH keys
Private keys in PKCS #1, PKCS #8, SEC 1, OpenSSL DSA and OpenSSH formats report their algorithm and their size or curve. Public keys and DH PARAMETERS blocks are read the same way, and so is each line of an SSH .pub or authorized_keys file. An encrypted PEM key still shows its algorithm. Every key, certificate and PEM file name is read for every kind of block, so a private key saved as server.crt is still reported as a key.
Certificates and signing requests
Each certificate and signing request, PEM or DER, reports its public key and the hash it was signed with. An RSA or elliptic-curve certificate is quantum-vulnerable. One signed with SHA-1 or MD5 is weak today, and a key below current minimums is flagged whoever issued it. File types read: .pem, .crt, .cer, .cert, .der and .csr.
A PKCS #8 ENCRYPTED PRIVATE KEY block shows nothing about its algorithm, so it is not reported.
A CA bundle is not your key choice
Many repositories carry a CA bundle so a client can verify the servers it calls. The application chooses which CAs to trust, not the keys those CAs use, so NightVision does not report a trust store's CA keys as quantum-vulnerable. A bundle is reported once per kind of certificate (algorithm, key size, curve and signature hash), with a count, instead of once per certificate.
A key too small or a hash too weak to trust is still reported. A 1024-bit root in a bundle is a real problem whoever chose it.
A self-signed CA certificate is a trust anchor. Path validation takes it as given and does not verify its own signature (RFC 5280, section 6.1), so its signature hash is not assessed and it is reported for its key alone. A certificate a CA signed is assessed for both its key and its signature hash.
The TLS a server offers, from its config
NightVision reads the protocol and cipher directives in server configuration files, including the forms that govern connections the server makes upstream:
- nginx:
ssl_protocols,ssl_ciphers,proxy_ssl_protocols,proxy_ssl_ciphersin*.conffiles. - Apache:
SSLProtocol,SSLCipherSuiteand theirProxyforms in*.confand.htaccess. - OpenSSL:
MinProtocolandCipherStringof the profiles anopenssl.cnfapplies.
TLS 1.0 and 1.1 are deprecated; SSL 2.0 and 3.0 and NULL or export cipher suites are broken. Only what a directive names is read. Apache's all admits whatever the linked OpenSSL admits, which the file does not fix, so it is not reported.
Libraries you ship, algorithms you wrote
Dependency manifests are read for direct dependencies on cryptography libraries outside an approved set: requirements files, pyproject.toml, Pipfile, setup.cfg, package.json, composer.json, Gemfile, go.mod, pom.xml and build.gradle. Only dependencies that ship count: development, test and lint requirements are skipped. These are informational, an inventory to review. Lock files are not read, so a library only another dependency pulls in is not listed.
Source files in any common language are checked for standard algorithms written by hand, recognized by the constants they define, such as MD5's sine table or the AES S-box. A hand-written one in your own code is rated medium. Copies of approved libraries such as OpenSSL or libsodium are not reported, and bundled third-party code is listed as informational.
Findings from committed files
Two example findings and the report header. Each finding names the file and line, what was found and why it matters, and never holds the key.
Reason
RSA is public-key cryptography that Shor's algorithm breaks.
Remediation
Plan the move to ML-DSA (FIPS 204) for signatures or ML-KEM (FIPS 203) for key establishment.
Reason
A CA in this bundle has a 1024-bit RSA key, below the 2048-bit minimum NIST SP 800-131A sets.
Remediation
Trust only CAs with RSA keys of 3072 bits or more, or P-256 keys.
Gap: file-scan-limit
The committed-file scan stopped at 200000 directory entries; the rest of the tree was not scanned.
What it skips, and how it tells you
The scan walks the tree once. It skips:
- Test and fixture directories:
test,tests,testing,testdataand__tests__. - Paths you pass to
--exclude. - Key, certificate, configuration and manifest files over 1 MiB, and source files over 4 MiB.
- PEM blocks past the 256th in a single file.
The walk is bounded at 200,000 directory entries. If a run reaches that limit, the report says complete: false and lists the gap, so a short report is never mistaken for a clean one.
Findings never hold key material. A dependency named by a URL is recorded without its version, since a URL can carry credentials. Run with --credentials as well and a committed private key's cryptography finding and its hardcoded credential finding name each other. Both run in the NightVision CLI as part of source intelligence; viewing and tracking these findings in the NightVision platform is in development.
Questions about keys, certificates and TLS.
Does the report contain our private keys?
No. A finding records the key's algorithm, size or curve and where the file is. It never holds key material, so the report is as safe to share as the API spec.
Which files does NightVision read?
Private and public keys, certificates and signing requests in PEM or DER, SSH public keys and authorized_keys files, nginx and Apache configuration, OpenSSL configuration, dependency manifests from requirements files to go.mod, pom.xml and build.gradle, and source files that implement a standard algorithm by hand.
Will a CA bundle flood the report?
No. A bundle is reported once per kind of certificate, with a count, and a trust store's CA keys are not reported as quantum-vulnerable, since the application does not choose them. A key too small or a hash too weak to trust is still reported.
Are test keys reported?
No. Test and fixture directories (test, tests, testing, testdata and __tests__) are skipped, since no deployment uses their keys.
How do I know the scan covered the whole repository?
The report says complete true when it covered everything the run set out to read. When it stops early, for example at its limit of 200,000 directory entries, it says complete false and lists each gap, so a short report is never mistaken for a clean one.
Where does this run today?
It runs in the NightVision CLI today: add the --weak-crypto flag to nightvision openapi extract and the report is written beside the API spec that source intelligence generates. The --no-upload flag sends nothing to NightVision. Viewing and tracking these findings in the NightVision platform is in development.
Know every key and certificate in your repos.
Inventory the cryptography your committed files fix, in any language, with a fix for each weak choice. Pair it with hardcoded credential detection to see which keys are secrets in the tree.