FIPS 140-3 Mode (Pro)
DefectDojo Pro can be deployed with FIPS 140-3 validated cryptography, for environments subject to FedRAMP control SC-13 or similar requirements.
FIPS mode ships as a separate set of container images, identified by a -fips tag suffix. The standard images are unchanged: enabling FIPS is an explicit choice, never a silent default.
For access to FIPS images, contact us at .
What the FIPS images provide
All cryptographic operations are performed by the OpenSSL FIPS Provider 3.1.2, which holds NIST CMVP certificate #4985 under FIPS 140-3. Go services use the Go Cryptographic Module v1.0.0, CMVP certificate #5247.
Because enforcement happens inside the container, FIPS mode does not require the host to run a FIPS-enabled kernel. That is what makes it workable on managed container runtimes such as Amazon ECS with the Fargate launch type, where the host operating system is not under your control.
FIPS 140-3, not 140-2. FIPS 140-3 supersedes 140-2 and satisfies a requirement written against it. All FIPS 140-2 certificates move to the CMVP Historical List on 21 September 2026 and stop supporting new deployments after that date, so new systems should be validated against a 140-3 module.
Coverage
| Component | Covered | Module |
|---|---|---|
Django application (dojo) | yes | OpenSSL FIPS Provider 3.1.2 |
Async import (dojo-import-scan) | yes | OpenSSL FIPS Provider 3.1.2 |
| Celery worker and beat | yes | OpenSSL FIPS Provider 3.1.2 |
Initializer (init) | yes | OpenSSL FIPS Provider 3.1.2 |
Orchestration workers (ddorch-workers) | yes | OpenSSL FIPS Provider 3.1.2 |
| nginx | yes | OpenSSL FIPS Provider 3.1.2 |
| PSIRT advisory engine | yes | OpenSSL FIPS Provider 3.1.2 |
| Connectors, Integrators, ddorch, MCP server | yes | Go Cryptographic Module v1.0.0 |
| Sensei | partial | service binaries: Go Cryptographic Module v1.0.0. Bundled scanner toolchain: not covered |
| PostgreSQL / Redis (embedded) | no | use external FIPS-compliant services |
Sensei is a partial case worth understanding. Its own binaries are built against the validated Go module, so the job API’s TLS and tokens are covered. The image also bundles a polyglot third-party scanner toolchain — Node (which ships its own OpenSSL), Rust (rustls), Python, Ruby, and third-party Go binaries we do not compile — and several of those fetch advisory databases over TLS using their own cryptography. That toolchain cannot be brought under a single validated module, so it is not covered and should not be represented as such to an assessor.
The embedded PostgreSQL/Redis have no FIPS variant at all. In Kubernetes the chart refuses to render if you enable FIPS alongside Sensei or the embedded datastores, so the trade-off is an explicit decision rather than an assumption; see the Kubernetes tab under Enabling FIPS mode.
Enabling FIPS mode
Running on Amazon ECS / Fargate
FIPS on Amazon ECS with the Fargate launch type is covered on its own page: see FIPS 140-3 Mode on Amazon ECS / Fargate.
Fail-closed startup
With DD_FIPS_MODE set, every container verifies at startup that the validated provider is loaded and that non-approved algorithms are genuinely refused. If that check fails, the container exits instead of starting.
Same reasoning as the chart guard: a container that quietly fell back to non-validated cryptography would keep serving traffic while breaking your compliance posture, and you would not find out until an assessment.
Verifying FIPS mode
Each container prints an evidence block at startup, which is usually the most convenient form for an assessor. On managed runtimes it lands in your log aggregator:
================================================================
[FIPS] DefectDojo Pro FIPS mode verification
Providers:
fips
name: OpenSSL FIPS Provider
version: 3.1.2
status: active
[FIPS] MODE: ACTIVE
[FIPS] Module: OpenSSL FIPS Provider 3.1.2 (CMVP #4985, FIPS 140-3)
[FIPS] Non-approved algorithms (MD5-as-security, ChaCha20): blocked
================================================================Retrieve it with:
You can also verify on demand inside a running container:
For Go services (connectors, integrators, ddorch, MCP server), FIPS mode is compiled in and reported by the Go runtime as GODEBUG=fips140=on. Check it on a running service with kubectl exec on Kubernetes or docker compose exec on Docker Compose, for example printenv GODEBUG.
Behaviour differences in FIPS mode
Some non-approved algorithms are unavailable, so a few behaviours change. These are the ones worth planning for.
Password hashing
FIPS builds use PBKDF2-SHA256 as the default password hasher. Argon2, bcrypt and scrypt are not FIPS-approved key-derivation functions and are disabled.
Existing users are not locked out. Django re-hashes each password to PBKDF2 on the user’s next successful login, and PBKDF2-SHA1 hashes remain verifiable during the transition. If you prefer a hard cutover, force a password reset rather than relying on gradual migration.
TLS cipher suites
ChaCha20-Poly1305 is not FIPS-approved and is removed from every nginx configuration that terminates TLS, and TLS 1.3 is pinned to TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256. TLS 1.2 and TLS 1.3 remain available using AES-GCM suites. Clients that support only ChaCha20 will not be able to connect.
The validated module would refuse ChaCha20 in any case; removing it from the configuration means the server never advertises a suite it cannot complete, which keeps the deployed configuration self-documenting for an assessor.
Metrics basic authentication
When nginx metrics authentication is enabled, the password hash uses SHA-256 crypt rather than Apache’s MD5 (apr1) format, which the validated module refuses. This is transparent unless you generate .htpasswd entries yourself, in which case use openssl passwd -5.
Scan parsers
Some parsers use MD5 to build deduplication keys. That is a non-security use and is explicitly annotated as such, so those parsers continue to work normally under FIPS. No parser functionality is lost.
Deployment notes
- TLS termination. If TLS terminates at a load balancer in front of DefectDojo, that device is responsible for its own FIPS posture and should be documented separately in your system security plan. The
-fipsnginx image covers TLS terminated by DefectDojo itself. - Database and cache. PostgreSQL and Redis are separate Assets. In a FIPS environment, use FIPS-compliant instances — for example a managed database offering a FIPS endpoint — and document them as inherited components.
- Compliance scope. DefectDojo is not itself a cryptographic module and holds no certificate of its own. What these images provide is validated cryptography performed by modules that do, running in FIPS-approved mode. Your assessor will want the module names and certificate numbers, which appear in the evidence output above.