ASVS 5.0 V11.2.1: Use Validated Crypto Libraries Only

ASVS 5.0 V11.2.1 (Level 2) requires that cryptographic operations use industry validated implementations, including libraries and hardware accelerated ones. The short version: do not write your own crypto, and do not pick an obscure package because it had a friendly API.

Why it matters

Cryptography fails in the details. Timing leaks, bad edge case handling, weak randomness and subtle padding mistakes pass every functional test and still break security. Widely reviewed libraries have had those bugs found and fixed, often over many years.

There is a second half to this requirement that teams forget. A validated library is only validated at the version that was reviewed. An old release with a known flaw is no longer a safe choice, so keeping crypto dependencies patched is part of meeting it.

How to implement it

Choose by this order of preference:

1. The platform's standard library crypto (Go crypto, Java JCA, .NET System.Security.Cryptography, Python cryptography built on OpenSSL).
2. A high level, misuse resistant library such as libsodium or Tink.
3. A KMS or HSM API when keys must never leave hardware.

Do not accept code that implements AES rounds, a hash, a padding scheme or a big number routine by hand. Wrap the library once in a small internal module and ban direct use elsewhere, so mistakes are fixed in one place.

# crypto_wrap.py: the only module allowed to import crypto primitives
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

def encrypt(key: bytes, data: bytes, aad: bytes = b"") -> bytes:
    nonce = os.urandom(12)
    return nonce + AESGCM(key).encrypt(nonce, data, aad)

def decrypt(key: bytes, blob: bytes, aad: bytes = b""):
    return AESGCM(key).decrypt(blob[:12], blob[12:], aad)

When FIPS validated modules are a contractual need, use the provider mode of your platform and test that it is actually enabled in production, not only on a laptop.

For dependencies, track every package that ships crypto in your software bill of materials, and alert when a vulnerable version appears. Safeguard's reachability analysis helps separate a crypto library flaw your code actually calls from one it never touches, so the urgent fixes come first.

Try it yourself

Click through it at your own pace, or open it full screen.

You can also check a manifest for known vulnerable crypto packages with the free in browser dependency scan at gold.safeguard.sh/scan.

How to test it

Run three checks.

First, a code search for hand written primitives: files with names like aes.js, sha256.py, rc4, or large constant tables of S boxes. Each hit needs justification or removal.

Second, a dependency review. List all crypto related packages from the lockfile, confirm each is maintained (recent releases, active issue tracker), and confirm none carries a known vulnerability at the pinned version.

Third, a runtime check. Confirm the crypto provider in the deployed container is the one you expect, for example by printing the OpenSSL version at startup in a test, and failing the build if it is below your floor.

Common mistakes

• Importing a tiny package with one maintainer and no review history for a core crypto job
• Copying a snippet from a forum that implements a cipher "to avoid a dependency"
• Pinning a crypto library once and never updating it
• Enabling FIPS mode in documentation but not in the actual runtime
• Letting each team wrap crypto differently, which multiplies the surface to review

Quick check

Sources

• OWASP ASVS
• Safeguard free dependency scan: gold.safeguard.sh/scan