Most cryptographic inventories start with the network: scan the TLS and SSH endpoints, record the protocols and cipher suites, and call it a baseline. That is a sensible first step, but it only sees cryptography while it is being negotiated on the wire. The algorithm an engineer hard-coded into a payment batch job, the Java keystore copied onto a departmental share in 2017, and the PGP-encrypted archives sitting in a finance folder never appear in a network scan. Cryptographic discovery in source code and on file shares is how you find them.
The gap is officially recognised. CISA’s discovery strategy (15 August 2024) warns that software packages with embedded cryptography and customised applications “may not be discoverable using automated tools”. OMB Memorandum M-26-15 (24 June 2026) goes further and tells US agencies to build their inventory using, among other things, static and dynamic application security testing “to find cryptographic functions in code”, alongside network scanners and software composition analysis. This article explains what repository and file-share discovery should find, how the results feed a Cryptographic Bill of Materials (CBOM) and developer remediation, and how to do it without creating a new security problem.
Why Network Scans Miss So Much
A network scan answers one question well: what does this endpoint negotiate when a client connects? It cannot answer several others that matter just as much for post-quantum planning:
- Cryptography that never crosses the network. Application-level encryption of database fields, signed files, tokens and backups happens inside the code.
- Code paths that are rarely exercised. A fallback to SHA-1 or a legacy RSA-1024 signing routine may only run at month end, or never during the scan window.
- Hard-coded parameters. Fixed key sizes, static initialisation vectors and embedded keys are visible only in the source.
- Data at rest. Encrypted files and archives, and the keystores that hold the keys for them, sit on file shares long after the system that created them has gone.
That last point matters for the harvest-now, decrypt-later threat. Files encrypted with keys wrapped under RSA or elliptic-curve algorithms are exactly the long-lived data an adversary would want to collect today. You cannot assess that exposure if you do not know the files exist.
Cryptographic Discovery in Source Code: What It Should Find
Algorithm usage, with location
The core output is a list of every cryptographic algorithm the code calls, with key size where it can be determined, the file, the line and ideally the enclosing function. That last detail is what turns a finding into something an engineer can pick up without a second investigation. Good scanners also report strong and post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA), not just weak ones, because an inventory that lists only problems cannot show progress.
Broken and quantum-vulnerable algorithms, graded separately
DES, 3DES, RC4, MD5 and SHA-1 are broken or risky today (MITRE CWE-327, Use of a Broken or Risky Cryptographic Algorithm). RSA, ECDSA and Diffie-Hellman are sound today but quantum-vulnerable: NIST’s final IR 8547 (27 October 2026) deprecates them after 2030 and disallows them after 2035. The two categories need different responses, so a scan that lumps them together will mislead your prioritisation.
Hard-coded keys, IVs and nonces
A key embedded in source (CWE-321, Use of Hard-coded Cryptographic Key) cannot be rotated without a release, and anyone with repository access holds it. Static IVs and reused nonces are a classical implementation defect and usually the most immediately actionable finding a code scan produces.
Deprecated libraries and configuration
Much of an application’s cryptography comes from its dependencies and from configuration: cipher strings, TLS settings and provider choices. These are usually covered by software composition analysis and SBOMs rather than by code scanning, which is why OMB lists both. Make sure your programme covers both layers, and be clear which tool owns which.
Scope varies between tools, so read the detail. Quantum Sentinel’s source code repository discovery, for example, connects to GitHub, GitLab, Bitbucket and Azure DevOps with read access, covers seventeen languages, records the file path, line, algorithm, key size and enclosing function for each finding, and detects post-quantum algorithms too. It is equally plain about its limits: it scans the current state of a branch rather than Git history, excludes dependency directories, and leaves committed secrets to dedicated secret-scanning tools. That is the kind of scope statement you should expect from any vendor.
What File-Share Discovery Should Find
File shares accumulate cryptographic material that no system owner remembers. A useful scan should identify:
- Keystores and key containers, such as Java keystores and PKCS#12 files, which usually hold RSA or elliptic-curve private keys.
- Encrypted files: PGP/GPG, OpenSSL and age output, S/MIME messages and password-protected Office documents.
- Encrypted archives and volumes, such as encrypted ZIP, RAR and 7-Zip files and LUKS containers.
- Certificate records left behind as exports from internal certificate authorities.
Detection should work by content signature, not by file extension: a keystore renamed to backup.dat is still a keystore. Quantum Sentinel’s file share discovery for SMB and NFS takes this approach, identifying formats from file headers and scoring each finding for quantum risk and harvest-now, decrypt-later exposure. Check protocol support during evaluation: that page states it supports SMB 2.0.2 to 3.1.1 and NFS v3, but not SMB1 or NFS v4 exports today.
From Findings to the CBOM and Developer Remediation
Code and file findings are only useful if they land in the same inventory as everything else. Each should become a CBOM entry with a precise location (repository, file and line, or share and path), the algorithm and key size, a risk position and its provenance. Quantum Sentinel’s cryptographic discovery and CBOM page describes one way to do this: every source writes into a single inventory, entries are deduplicated by fingerprint, rescans update existing entries, and the whole inventory exports as CycloneDX 1.7 JSON. Our own guide to building a CBOM covers the fields that matter.
Then route the work to the people who own it:
- Group findings by repository and owning team, not by algorithm, so each team receives one actionable list.
- Fix the broken items first: hard-coded keys, static IVs, MD5 and SHA-1 in security functions. These are risks today.
- Plan the quantum-vulnerable items against data lifetime. Code that signs or encrypts long-lived data moves up the list.
- Prefer abstraction to substitution. Where the same algorithm is called in dozens of places, centralise it behind a single interface so the next change is a configuration change, not another code hunt.
- Rescan on a schedule so new code is caught. Quantum Sentinel’s automated cryptographic discovery runs on schedules and records a drift event when an entry becomes weaker between scans.
Keystores and encrypted archives on shares follow a different path: identify the owner, decide whether the data is still needed, and re-encrypt, migrate or securely delete it. Our PQC migration journey article sets out how these steps fit into a wider programme.
Doing It Safely: Read-Only and Metadata Only
Scanning code and file shares means pointing a tool at your intellectual property and your users’ documents. Done carelessly, discovery creates the very exposure it is meant to measure. Insist on the following:
- Read-only credentials, scoped to the repositories and shares in scope, issued to a dedicated service account and revoked when no longer needed.
- No persistent copies of code. A temporary, shallow clone that is deleted after the scan is reasonable; a central archive of your source is not.
- Header inspection, not content reading, on shares. Identifying a file’s format needs only its first few hundred bytes. Unencrypted files should be discarded, not listed.
- No key material in the findings. The inventory should record that a keystore exists and where, never its contents.
- Data stays in your environment. Run the scanner and store the inventory inside your perimeter, especially in regulated sectors. Quantum Sentinel’s security and trust commitments describe this model: read-only, agentless collection of metadata only, deployed on-premises or in private infrastructure.
- Governance sign-off. Brief your data protection and HR teams before scanning shares that hold personal data, and record the scope for your auditors.
How Sinevis Can Help
Sinevis delivers post-quantum cyber readiness assessments that combine network, code and file-share discovery into one prioritised view, then turn the findings into remediation plans your development teams can act on. For automated discovery we work with Quantum Sentinel, a Sinevis technology partner, alongside the code and dependency tooling you already run.
Not sure where to begin? Try our free PQC compliance check, or contact Sinevis to scope a discovery exercise across your repositories and file shares.
Sources
- CISA, Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools, 15 August 2024: cisa.gov
- Office of Management and Budget, Memorandum M-26-15 Execution of the Migration to Post-Quantum Cryptography, 24 June 2026: whitehouse.gov (PDF)
- NIST, IR 8547 Transition to Post-Quantum Cryptography Standards (final), 27 October 2026: csrc.nist.gov/pubs/ir/8547/final
- MITRE, CWE-327 Use of a Broken or Risky Cryptographic Algorithm: cwe.mitre.org
- MITRE, CWE-321 Use of Hard-coded Cryptographic Key: cwe.mitre.org
- OWASP CycloneDX, CycloneDX v1.7 released, 21 October 2025: cyclonedx.org