OCImend FIPS containers: what you get and how they are verified
Short answer
An OCImend FIPS container is the image you already use, with FIPS mode enforced for every OpenSSL 3 consumer: using the image's own validated module (Red Hat UBI, Azure Linux, Wolfi) or the OpenSSL 3.1.2 FIPS provider (CMVP #4985). It is rescanned, started next to the original, tested live for FIPS mode and published as ocimend.io/NAME:TAG-fips only when every check passes.
The gates every FIPS image passes
- 01Buildsandboxed, one new layer
- 02Rescannew FIPS verdict
- 03Startnext to the original
- 04Live testFIPS provider on, MD5 refused
- 05Publishpinned by digest
| Vendor FIPS image | OCImend FIPS image | |
|---|---|---|
| Base | switch distributions | the image you already run |
| FIPS mode | follows the host kernel | enforced in the image |
| Evidence | vendor statement | rescan + live test report, per image |
| Go / Java crypto | varies | listed as not covered, never hidden |
What is not covered
Runtimes that bring their own cryptography (Go's standard library, Java's default JCE providers) are not made FIPS by an OpenSSL change. The report lists them so the verdict stays honest.
Browse published FIPS images →
Questions
Are OCImend FIPS images free?
Yes, for public images. Private images are built on request and handed back as a download or pushed to your registry, never published.
Where are they published?
At ocimend.io, e.g. docker pull ocimend.io/nginx:1.27-fips, with the report that justified each tag.
Sources
More guides
- How to build FIPS-enabled containers (FIPS 140-3)
- How to fix container image CVEs automatically
- A container vulnerability pipeline that ends in a fix, not a report
- "No fix available": what to do about unfixable container CVEs
- Base image or your layers? Finding which Dockerfile step introduced a CVE
- EU Cyber Resilience Act for container images: SBOM, VEX and 24-hour reporting