Upgrading to DefectDojo Version 2.53.x

Helm Chart Changes#

• This release introduces an important change to the Helm chart configuration for the initializer job.
• DefectDojo 2.52.0 replaced Redis with Valkey in docker-compose deployment. DefectDojo 2.53.0 (chart 1.9.0) is replacing it in HELM charts.
• Add support for HPA and PDB

HPA & PDA#

Added Helm chart support for Celery and Django deployments for Horizontal Pod Autoscaler using .autoscaling fields under each section. And Pod Disruption Budget using .podDisruptionBudget for any of Celery Beat/Worker or Django deploy

Breaking changes#

Valkey#

Renamed values#

HELM values had been changed to the following:

• createRedisSecret → createValkeySecret
• redis.enabled → valkey.enabled
• redis.auth.existingSecret → valkey.auth.existingSecret, plus value is pointing to secret defectdojo-valkey-specific now
• redis.auth.existingSecretPasswordKey → valkey.auth.existingSecretPasswordKey, plus value is pointing to secret valkey-password now
• redis.auth.password → valkey.auth.password
• redis.master.service.ports.redis → valkey.service.port
• redis.sentinel... → valkey.sentinel...
• redis.tls... → valkey.tls...

The whole subchart is based on cloudpirates-valkey, so all additional values can be found there.

If an external Redis instance is being used, set the parameter valkey.enabled to False. The parameters redisServer and redisParams remain available and function as before. Additionally, redisScheme and redisPort have been introduced to accommodate users requiring these configurations.

How to migrate to Valkey#

0. As always, perform a backup of your instance
1. If you would like to be 100% sure that you do not miss any async event (triggered deduplication, email notification, …) it is recommended to perform the following substeps (if your system is not in production and/or you are willing to miss some notifications or postpone deduplication to a later time, feel free to skip these substeps) 0. Perform the following steps with your previous version of HELM chart (not with the upgraded one - you might lose your data)
   1. Downscale all producers of async tasks:
      • Set django.replicas to 0 (if you used HPA, adjust it based on your needs)
      • Set celery.beat.replicas to 0 (if you used HPA, adjust it based on your needs)
      • Do not change celery.worker.replicas (they are responsible for processing your async tasks)
   2. Wait until the processing queue is empty (choose one of the following methods):
      • kubectl exec statefulset/defectdojo-redis-master -c redis -- redis-cli -a `kubectl get secret defectdojo-redis-specific -o go-template='{{index .data "redis-password" | base64decode}}'` llen celery – should output 0 (if your HELM chart used a different name, adjust the command based on your environment)
      • kubectl logs deployment/defectdojo-celery-worker -c celery --all-pods=true --follow – should stop outputting new task logs
2. Replace values based on the Renamed values part, update the chart version, and set the number of replicas back. Be aware that Valkey is using a password from the new location, and if you use createRedisSecret/createValkeySecret password will be regenerated. If you stored this password somewhere else, it will not be valid anymore.
3. Enjoy DefectDojo

Initializer Annotation Handling#

• Renamed initializer annotations: The initializer.annotations field has been renamed to initializer.podAnnotations for clarity and consistency with other DefectDojo resources.
• Merged annotation support: Global extraAnnotations are now automatically merged with the initializer’s podAnnotations to ensure consistent annotation handling across all resources.

The previous implementation did not merge global extraAnnotations with the initializer job’s pod annotations, causing inconsistencies in annotation management.

Moved values#

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

• initializer.annotations → initializer.podAnnotations (applies to Pod template metadata within the Job)

Note: initializer.jobAnnotations affects the Job spec metadata, while initializer.podAnnotations affects the Pod template metadata within the Job.

Migration#

If you were using:

initializer:
  annotations:
    foo: bar

Update to:

initializer:
  podAnnotations:
    foo: bar

Both extraAnnotations and initializer.podAnnotations will now be properly applied to the initializer pod.

Reimport updates fields fix_available and fix_version#

Reimport will update existing findings fix_available and fix_version fields based on the incoming scan report.

Batch Deduplication#

Before 2.53.0 Defect Dojo has been deduplicating new or updated findings one-by-one. This works well for small imports and has the benefit of an easy to understand codebase and test suite. For larger imports however the performance is bad and resource usage is (very) high. A 1000+ finding import can cause a celery worker to spend minutes on deduplication.

PR 13491 changes the deduplication process for import and reimport to be done in batches. This biggest benefit is that there now will be 1 database query per batch (1000 findings), instead of 1 query per finding (1000 queries).

A quick test with the jfrog_xray_unified/very_many_vulns.json samples scan (10k findings) shwo the obvious huge improvement in deduplication time. Please note that we’re not only doing this for performance, but also to reduce the resources (cloud cost) needed to run Defect Dojo.

initial import (no duplicates):

second import into the same product (all duplicates): initial import (no duplicates):

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