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.

FIPS images are published for every release from 3.3.200. They come from the same registry as the standard images, and the registry credentials in your license already pull them, so there is nothing to request or enable. See Getting the FIPS images.

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#

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, the embedded datastores, or the OSCAL validator, so the trade-off is an explicit decision rather than an assumption; see the Kubernetes tab under Enabling FIPS mode.

Getting the FIPS images#

Each image with a FIPS variant is published next to its standard image, in the same repository, tagged <version>-fips:

us-south1-docker.pkg.dev/defectdojo-container-registry/dojo-pro/django:<version>-fips
us-south1-docker.pkg.dev/defectdojo-container-registry/dojo-pro/nginx:<version>-fips
us-south1-docker.pkg.dev/defectdojo-container-registry/dojo-connectors/connectors:<version>-fips
us-south1-docker.pkg.dev/defectdojo-container-registry/dojo-integrators/integrators:<version>-fips
us-south1-docker.pkg.dev/defectdojo-container-registry/ddorch/ddorch:<version>-fips
us-south1-docker.pkg.dev/defectdojo-container-registry/go-dd-pro-mcp/mcp-server:<version>-fips
us-south1-docker.pkg.dev/defectdojo-container-registry/dojo-pro/webhook-gateway:<version>-fips   # from 3.4.0

The registry credentials that come with your license cover these repositories, the same as the standard images. Nothing needs to be requested or enabled on your account.

On Kubernetes and Docker Compose you do not write these tags yourself: fips.enabled and DD_FIPS_MODE select them, as described under Enabling FIPS mode. You need them directly when you write your own deployment, such as an Amazon ECS task definition, or when you mirror images into a private registry.

linux/amd64 only. The OpenSSL FIPS Provider’s certificate lists x86_64 operating environments, so the FIPS images are published for amd64 and not for arm64. A FIPS deployment needs amd64 nodes.

Signed. Like the standard release images, each FIPS image is signed and carries SPDX and CycloneDX SBOM attestations. Verifying Images and SBOMs shows how to check them, including after mirroring.

Which version. Deploy the most recent release in the DefectDojo Pro Changelog and append -fips to its version. Planning a FIPS deployment on a private network end to end is covered in Planning a Private Deployment.

Enabling FIPS mode#

fips:
  enabled: true

helm upgrade --install dojopro charts/dojopro \
  -f your-values.yaml \
  --set fips.enabled=true

fips:
  enabled: true
sensei:
  enabled: false          # partial coverage, see the coverage table above
postgresql:
  enabled: false          # use an external FIPS-compliant database
redis:
  enabled: false          # use an external FIPS-compliant cache

Error: fips.enabled is true but these services have no FIPS image variant:
sensei (service crypto validated; bundled scanner toolchain is not),
redis (embedded). Disable them, or set fips.validate=false to accept that they
run non-validated cryptography.

sudo -E dojo-compose-cli environment add -k DD_FIPS_MODE -v 1
sudo -E dojo-compose-cli app pull-images
sudo -E dojo-compose-cli app restart

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:

kubectl logs deploy/dojopro-django | grep FIPS

docker compose logs dojo | grep FIPS

You can also verify on demand inside a running container:

kubectl exec deploy/dojopro-django -- openssl list -providers
kubectl exec deploy/dojopro-django -- python3 /verify_fips.py

docker compose exec dojo openssl list -providers     # fips provider, 3.1.2, active
docker compose exec dojo openssl md5 /dev/null       # expected to FAIL
docker compose exec dojo python3 /verify_fips.py     # full check

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 -fips nginx image covers TLS terminated by DefectDojo itself.
• Database and cache. PostgreSQL and Redis are separate products. 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.