Scan your dependency lockfiles
Most of the cryptography you ship, you never wrote. PQLens reads your lockfiles and reports the crypto libraries in your dependency tree — including the transitive ones nobody remembers adding.
pqlens scan deps .
How it works
- Run
pqlens scan depsagainst the directory holding your lockfiles. - Supported ecosystems: npm (package-lock), Go (go.sum), Python (pip/poetry), Maven, Cargo and Bundler.
- Known cryptographic libraries are identified and the algorithms they provide are classified for quantum risk.
- Findings land in the same inventory as your code, config and endpoint scans.
The crypto you ship without calling it
A dependency that bundles an MD5 implementation or an old TLS stack is part of your cryptographic footprint even if your code never touches it — it is in your artifact, your container and your SBOM. Auditors increasingly read requirement 12.3.3 that way, and “we did not know it was in there” is precisely what an inventory is for.
Pair it with the SBOM scan
If you already generate a CycloneDX or SPDX SBOM in CI, pqlens scan sbom enriches it with the same classification — useful when the build artifact, not the source tree, is your compliance boundary (containers included).
Frequently asked questions
Which lockfiles are supported?
npm (package-lock.json), Go (go.sum), Python (pip requirements and poetry.lock), Maven, Cargo (Cargo.lock) and Bundler (Gemfile.lock).
Does it catch transitive dependencies?
Yes — lockfiles pin the full resolved tree, so the crypto four levels down is reported alongside your direct dependencies.
Is this a vulnerability (CVE) scanner?
No. It answers a different question: not "is this library exploitable" but "what cryptography does my software ship, and how does it hold up". Run it alongside your CVE scanner, not instead of it.