FIPS 140-3 · OCI images · NIST CMVP

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.

ubi9-minimal azurelinux core distroless microsoft go
No sign-upNothing is executedPrivate registries supportedOpen source
cryptopsy scan mcr.microsoft.com/azurelinux/base/core:3.0
$ 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
—days

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.

Check your images

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.

01 · What

What crypto is in here?

Shared libraries, static copies, Go binaries, JARs and the Python wheels that quietly bundle their own OpenSSL.

02 · Who

Who actually uses it?

The DT_NEEDED dependency closure plus dlopen hints, from every executable to the crypto module it reaches.

03 · Validated

Is it CMVP-validated?

Matched to validation lineage: active, vendor build, in process, or historical after the 140-2 sunset.

04 · Enforced

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.

1

Resolve

OCI Distribution API: token auth, multi-arch index → your platform, paginated tags.

2

Stream

gzip/zstd layers with whiteouts applied; every blob verified against its SHA-256 digest.

3

Fingerprint

ELF headers, Go buildinfo, version banners, JAR classes, dpkg/apk/rpm databases.

4

Cross-reference

CMVP lineage catalog plus OS-aware vendor validations and the 140-2 sunset.

5

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.

ImplementationDetected fromFIPS path
OpenSSL 1.0.2 → 3.x + FIPS providerbanners, SONAME, OPENSSLDIR, fips.so versionprovider / vendor
Go.go.buildinfo: GOFIPS140, fips140 GODEBUG, boringcrypto, systemcryptoGo Crypto Module (in process)
BoringSSL / BoringCrypto, AWS-LC (C & Rust)integrity-test symbols, aws_lc_fips_* prefixesAWS-LC 140-3
Microsoft SymCrypt, NSS, GnuTLS, libgcryptlibraries + OS-aware vendor matchingvendor builds
Java: BC-FJA vs bcprov, ACCP, Conscrypt, JDK providersclass paths incl. Spring Boot fat jars, java.securityBC-FJA
Bundled crypto in Python wheels & npm modulesstatic-embed analysis of defined symbolsbypasses system module
LibreSSL, ring, libsodium, Mbed TLS, Crypto++, Botanbanners, symbol prefixesnever 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.

SARIF 2.1.0code scanning alerts
CycloneDX 1.6crypto BOM (CBOM)
Markdownjob summaries, PRs
JSON + APIREST, live SSE progress
BadgeREADME status
# fail the build on high-severity FIPS findings curl -fsSL https://cryptopsy.cloudtrace.io/install.sh | sh cryptopsy scan ghcr.io/acme/api:$GITHUB_SHA \ --format sarif -o fips.sarif --fail-on high # block regressions between releases cryptopsy diff ghcr.io/acme/api:1.3 ghcr.io/acme/api:1.4 \ --fail-on-regression # offline: skopeo / docker save output cryptopsy scan oci:./layout cryptopsy scan docker-archive:image.tar

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?
No. It means Cryptopsy found no non-validated crypto on the execution path and saw FIPS mode enforced. Compliance also depends on how the software uses crypto and on your deployment boundary. Treat the report as evidence for your assessor, not as a certificate.
Why is my UBI / RHEL image only CONDITIONAL?
RHEL-family, Amazon Linux, SLES, Azure Linux and Ubuntu Pro FIPS images switch into FIPS mode from the node's kernel flag (/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?
From a curated CMVP lineage catalog, refreshed from the NIST CMVP site with 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?
Yes: GHCR, ECR, GAR, ACR, Quay, Harbor and any OCI Distribution registry with basic or bearer-token auth. For registries on an internal network, run Cryptopsy yourself with CRYPTOPSY_ALLOW_PRIVATE_REGISTRIES=1.
How big an image can it handle?
Layers are streamed, so memory stays around the size of the largest single binary. In our testing a 285 MB, 25k-file image took about 22 seconds.
How does it fit into CloudTrace?
Cryptopsy is the crypto-compliance module of CloudTrace. It runs standalone at cryptopsy.cloudtrace.io and ships as a CLI and API you can self-host.

Run your first FIPS postmortem

Paste an image reference. Results in seconds, with nothing to install.

Open the scanner →