The FIPS autopsy for container images.
Point Cryptopsy at any registry, pick your tags and get a postmortem of every cryptographic module inside: who loads it, whether it's CMVP-validated, and whether FIPS mode is actually switched on.
$ cryptopsy scan mcr.microsoft.com/azurelinux/base/core:3.0 ▸ linux/amd64 · 1 layers · 32.1 MB ▸ layer 1/1 sha256:c877612270d1 (32.1 MB) ▸ building crypto inventory ■ FAIL score 77/100 Microsoft Azure Linux 3.0 · 389 ELF · 0 Go · 0 JAR Crypto modules • OpenSSL 3.3.7 shared · 45 consumers → via FIPS provider • Microsoft SymCrypt shared → vendor-validated • Libgcrypt 1.11.3 shared · 21 consumers → no CMVP match ✔ A CMVP-validated module is present ✘ No non-validated crypto on the execution path ✔ No statically embedded crypto ! FIPS mode follows host kernel fips=1 HIGH CPY-115 Libgcrypt 1.11.3 in use without validation LOW CPY-104 OpenSSL 3.3 past upstream EOL INFO CPY-205 FIPS mode depends on the host kernel
FIPS 140-2 certificates moved to the Historical list on 21 September 2026.
Modules validated only under 140-2 are no longer acceptable for new federal acquisitions. Cryptopsy recomputes certificate status every time you scan, so old reports age honestly.
Four questions every assessor asks
“We use a FIPS base image” isn't evidence. Cryptopsy answers each question with file-level proof and the layer that introduced it.
What crypto is in here?
Shared libraries, static copies, Go binaries, JARs and the Python wheels that quietly bundle their own OpenSSL.
Who actually uses it?
The DT_NEEDED dependency closure plus dlopen hints, from every executable to the crypto module it reaches.
Is it CMVP-validated?
Matched to validation lineage: active, vendor build, in process, or historical after the 140-2 sunset.
Is FIPS mode really on?
openssl.cnf include chains, the fipsmodule.cnf integrity MAC, GODEBUG, java.security and host-kernel dependence.
Pull, don't run.
Layers are streamed straight from the registry and analysed in flight. No container runtime, no disk unpacking, no code execution.
Resolve
OCI Distribution API: token auth, multi-arch index → your platform, paginated tags.
Stream
gzip/zstd layers with whiteouts applied; every blob verified against its SHA-256 digest.
Fingerprint
ELF headers, Go buildinfo, version banners, JAR classes, dpkg/apk/rpm databases.
Cross-reference
CMVP lineage catalog plus OS-aware vendor validations and the 140-2 sunset.
Verdict
PASS / CONDITIONAL / FAIL, a score, a checklist and a fix for every finding.
A checklist an auditor can read.
Seven checks, each backed by evidence: the file path, the layer digest, the consumers, the certificate. Blocking rules force a FAIL no matter how clean the rest looks.
- Stable rule IDs (
CPY-101…CPY-207) for tracking and suppression - Every finding comes with a concrete fix
- Vendor, upstream, in-process and historical, always labelled
A postmortem, layer by layer.
See exactly which Dockerfile step introduced non-validated crypto, and which one removed it. Whiteouts are honoured, so a deleted library doesn't count against you.
Catch regressions between tags.
Multi-select tags, scan them in parallel with live progress, and diff any two: modules added, removed or bumped, findings new or fixed, score delta.
What Cryptopsy recognises
Native libraries, language runtimes, and the places crypto hides.
| Implementation | Detected from | FIPS path |
|---|---|---|
| OpenSSL 1.0.2 → 3.x + FIPS provider | banners, SONAME, OPENSSLDIR, fips.so version | provider / vendor |
| Go | .go.buildinfo: GOFIPS140, fips140 GODEBUG, boringcrypto, systemcrypto | Go Crypto Module (in process) |
| BoringSSL / BoringCrypto, AWS-LC (C & Rust) | integrity-test symbols, aws_lc_fips_* prefixes | AWS-LC 140-3 |
| Microsoft SymCrypt, NSS, GnuTLS, libgcrypt | libraries + OS-aware vendor matching | vendor builds |
| Java: BC-FJA vs bcprov, ACCP, Conscrypt, JDK providers | class paths incl. Spring Boot fat jars, java.security | BC-FJA |
| Bundled crypto in Python wheels & npm modules | static-embed analysis of defined symbols | bypasses system module |
| LibreSSL, ring, libsodium, Mbed TLS, Crypto++, Botan | banners, symbol prefixes | never validated |
Built for pipelines.
Gate merges on FIPS posture, push SARIF into GitHub code scanning, and attach a cryptographic bill of materials to every release.
Safe to point at production registries
Nothing executes
Pure static analysis. Optional dynamic probes are off by default and run with no network, a read-only rootfs and no capabilities.
Credentials never persist
Registry tokens live in memory for a single job and are masked in every log. Prefer short-lived, read-only tokens.
SSRF-hardened
Registry hosts must resolve to public addresses, re-checked on every request and redirect. Every blob is digest-verified.
FAQ
Does a PASS mean my image is FIPS compliant?
Why is my UBI / RHEL image only CONDITIONAL?
/proc/sys/crypto/fips_enabled). The image alone can't guarantee it, so run these workloads on FIPS-enabled nodes.Where do the certificate numbers come from?
cryptopsy cmvp sync. Always confirm a certificate on csrc.nist.gov before citing it in an audit. Every report links to the certificate or the lookup page.Can I scan private registries?
CRYPTOPSY_ALLOW_PRIVATE_REGISTRIES=1.How big an image can it handle?
How does it fit into CloudTrace?
Run your first FIPS postmortem
Paste an image reference. Results in seconds, with nothing to install.
Open the scanner →