Skip to content

2.51.md

Latest commit

 

History

History
146 lines (97 loc) · 6.54 KB

2.51.md

File metadata and controls

146 lines (97 loc) · 6.54 KB
title Upgrading to DefectDojo Version 2.51.x
toc_hide true
weight -20250902
description Helm chart changes and Postgres major version updates.

Helm Chart Changes

This release introduces several important changes to the Helm chart configuration:

Breaking changes

Volume Management Improvements

  • Streamlined volume configuration: The existing volume logic has been removed and replaced with more flexible extraVolumes and extraVolumeMounts options that provide deployment-agnostic volume management.

The previous volume implementation prevented mounting projected volumes (such as secret mounts with renamed key names) and per-container volume mounts (like nginx emptyDir when readOnlyRootFs is enforced). The new approach resolves these limitations.

Moved values

The following Helm chart values have been modified in this release:

  • redis.transportEncryption.enabled → redis.tls.enabled (aligned with upstream Helm chart)
  • redis.scheme → redis.sentinel.enabled (controls deployment mode and aligns with upstream chart)
  • redis.redisServer → redisServer (prevents potential schema conflicts with upstream chart)
  • redis.transportEncryption.params → redisParams (prevents potential schema conflicts with upstream chart)
  • postgresql.postgresServer → postgresServer (prevents potential schema conflicts with upstream chart)

New features

Container and Environment Enhancements

  • Added extraInitContainers support: Both Celery and Django deployments now support additional init containers through the extraInitContainers configuration option.
  • Enhanced probe configuration for Celery: Added support for customizing liveness, readiness, and startup probes in both Celery beat and worker deployments.
  • Enhanced environment variable management: All deployments now include extraEnv support for adding custom environment variables. For backwards compatibility, .Values.extraEnv can be used to inject common environment variables to all workloads.

GitHub Scan Type and Parser Updates

The Github Vulnerability scan type and parser has been split into two disctinct scan types:

The original Github Vulnerability scan type will continue to accept SCA vulnerabilities uploaded in GitHub's GraphQL format, as it has always done. It will also continue to accept SAST uploads, however we recommend upgrading to the new Github SAST scan type for uploading these types of vulnerabilities going forward. This new scan type will accept the raw JSON response from GitHub's REST API for code scanning alerts. Sample Github SAST scan data can be found here.

Other changes

  • Celery pod annotations: Now we can add annotations to Celery beat/worker pods separately.
  • Flexible secret deployment: Added the capability to deploy secrets as regular (non-hooked) resources to address compatibility issues encountered with CI/CD tools (such as ArgoCD).
  • Optional secret references: Some secret references are now optional, allowing the chart to function even when certain secrets are not created.
  • Fixed secret mounting: Resolved issues with optional secret mounts and references.
  • Improved code organization: Minor Helm chart refactoring to enhance readability and maintainability.

PostgreSQL Major Version Upgrade in Docker Compose

This release incorporates a major upgrade of Postgres. When using the default docker compose setup you'll need to upgrade the Postgres data folder before you can use Defect Dojo 2.51.0.

There are lots of online guides to be found such as https://hub.docker.com/r/tianon/postgres-upgrade or https://github.com/pgautoupgrade/docker-pgautoupgrade.

There's also the official documentation on pg_upgrade, but this doesn't work out of the box when using Docker containers.

Sometimes it's easier to just perform the upgrade manually, which would look something like the steps below. It may need some tuning to your specific needs and docker compose setup. The guide is loosely based on https://simplebackups.com/blog/docker-postgres-backup-restore-guide-with-examples. If you already have a valid backup of the postgres 16 database, you can start at step 4.

0. Backup

Always back up your data before starting and save it somewhere. Make sure the backup and restore is tested before continuing the steps below where the docker volume containing the database will be removed.

1. Start the Old Postgres Container

If you've acceidentally already updated your docker-compose.yml to the new versions, downgrade to postgres 16 for now:

Edit your docker-compose.yml to use the old Postgres version (e.g., postgres:17.6-alpine):

postgres:
  image: postgres:17.6-alpine
  ...

Start only the Postgres container which will now be 17.6:

docker compose up -d postgres

2. Dump Your Database

docker compose exec -t postgres pg_dump -U defectdojo -Fc defectdojo -f /tmp/defectdojo.dump
docker cp <postgres_container_name>:/tmp/defectdojo.dump defectdojo.dump

You can find the postgres_container_name via docker container ls or docker ps.

3. Stop Containers and Remove the Old Volume

You can find the volume name via docker volume ls.

docker compose down
docker volume rm <defectdojo_postgres_volume_name>

4. Switch to the New Postgres Version

Edit your docker-compose.yml to use the new version (e.g., postgres:18-alpine):

postgres:
  image: postgres:18-alpine
  ...

5. Start the New Postgres Container

docker compose up -d postgres

6. Restore Your Database

Copy the dump file into the new container:

docker cp defectdojo.dump <postgres_container_name>:/defectdojo.dump

Restore inside the container:

docker exec -it <postgres_container_name> bash
pg_restore -U defectdojo -d defectdojo /defectdojo.dump

7. Start the Rest of Your Services

docker compose up -d

There are other instructions for upgrading to 2.51.x. Check the Release Notes for the contents of the release.