ASVS 5.0 V11.1.3 (Level 3) requires cryptographic discovery mechanisms that identify all instances of cryptography in the system, including encryption, hashing and signing operations. A manual list is not enough; the check must be repeatable tooling.
Why it matters
Crypto hides. A vendored library, a legacy helper that calls MD5, a signing step buried in a build script: none of these show up in an architecture diagram, and all of them can break your guarantees. Discovery turns "we think we use AES" into a list you can trust.
How to implement it
Layer three kinds of discovery:
- Source scanning. Run a static analysis rule set that flags calls to crypto APIs (
Cipher.getInstance,hashlib,crypto.createHash,MessageDigest). - Dependency analysis. List every package that ships crypto primitives, direct or transitive, through your software bill of materials.
- Runtime and network discovery. Scan endpoints for TLS versions, cipher suites and certificate algorithms.
A starter grep gives immediate value:
grep -rnE "MD5|SHA1|DES|RC4|ECB|createHash|MessageDigest|Cipher\.getInstance" src/
Feed the results into the inventory from V11.1.2 and diff it in CI so a new algorithm cannot appear unnoticed. Safeguard's reachability analysis helps you decide which vulnerable crypto libraries are actually called by your code.
Try it yourself
Click through it at your own pace, or open it full screen.
How to test it
Plant a known operation, for example a call to SHA-1 in a throwaway branch, and confirm the discovery pipeline reports it and fails the check. Repeat for a new third party package with its own crypto. If the tool misses either, widen its rules.
Common mistakes
- Scanning only first party code
- Treating discovery as a one time project
- Missing crypto in build and deploy scripts
- No link between findings and the inventory
Quick check
Which operations does V11.1.3 name?
Encryption, hashing and signing.
Sources
- OWASP ASVS
- Free in browser dependency scan: gold.safeguard.sh/scan
