What your SAST scanner misses about your cryptographic surface.

Every CISO we have ever talked to has run a SAST scan against their codebase, gotten back a long list of uses crypto hits, and concluded the inventory is done. It is not. Generic SAST is built to flag the obvious: RSA.generateKey, AES.encrypt, jwt.sign. That set is real, and it is roughly 30% of your cryptographic surface. The other 70% — the part that determines whether your migration is a 12-week project or a 36-month re-architecture — sits in places your scanner does not even look at.

1. Configuration files.

Your TLS suites are not in your application code. They are in nginx.conf, haproxy.cfg, fastly.vcl, aws:cloudfront:DistributionConfig.OriginSslProtocols, in your Terraform modules, in YAML pinning Cloudflare workers. SAST does not parse any of these. We do. The first thing our scanner reads, every time, is the union of every reachable configuration that touches a TLS endpoint.

2. Build pipelines.

How is your release binary signed? Almost no one can answer this in less than 20 minutes. Your CI scripts probably reference an opaque ${SIGN_KEY_ID} that resolves through three layers of indirection to an HSM key whose algorithm metadata is hand-written in a runbook from 2019. The scanner that does not follow CI variables does not see the algorithm.

3. Cert and KMS provider metadata.

AWS KMS, GCP KMS, Azure Key Vault, Thales, Entrust — every one of them expresses key algorithm in its own JSON schema, and most of them allow keys created with deprecated algorithms to remain usable forever. SAST does not call your cloud provider’s admin API. A real inventory does. We enumerate the actual key material, by ID, by algorithm, by last-rotation date, and bind that back to the application code that uses each key.

4. Vendored binaries and pre-compiled wheels.

Your Python requirements.txt contains cryptography==41.0.3. That is a wheel. Inside the wheel: a vendored libssl, statically-linked, with its own list of supported algorithms, distinct from the system openssl. SAST cannot see this. We extract every wheel, every Go-vendored binary, every embedded openssl, and inventory the algorithms each one was compiled to support — including which ones are reachable from the application’s actual call graph.

5. On-chain primitives.

If you ship a smart contract, your cryptographic surface extends to every chain you have ever deployed on. ecrecover in Solidity. Ed25519::verify in Move. secp256k1::verify in Solana programs. SAST tools written for web2 do not catalog any of this. Our inventory walks every deployed bytecode you control and flags the signature schemes you are pinned to.

What this changes.

When the regulator asks “what cryptographic primitives are you using and where?”, the SAST output is roughly the wrong answer. The right answer — the one CNSA 2.0 and DORA expect — covers every channel where your data is in motion (TLS), every channel where it is at rest (KMS), every channel where you are claiming authenticity (signing), and every channel where someone else is claiming authenticity to you (cert pinning, on-chain verification).

QorTrace Labs runs all five layers in one engagement. The deliverable is a single CSV + PDF, sortable, exportable, and accepted by the regulator on first review. See the full service →