feat(helm): Split image locations+tags, allow digest pinning

[kiblik]

tag and repositoryPrefix fields have been deprecated. Currently, image tags used in containers are derived by default from the appVersion defined in the Chart.
This behavior can be overridden by setting the tag value in images.django and images.nginx.
If fine-tuning is necessary, each container’s image value can also be customized individually (celery.beat.image, celery.worker.image, django.nginx.image, django.uwsgi.image, initializer.image, and dbMigrationChecker.image).
Digest pinning is now supported as well.

[dryrunsecurity]

This pull request leaves image digests unset by default in the Helm chart (values.yaml) so mutable tags are used unless users manually pin digests, and it also uses the 'latest' image tag in the k8s test workflow, both of which create supply-chain and reproducibility risks. Both issues are non-blocking but recommend switching to immutable tags or digests for safer, reproducible deployments and tests.

Lack of Image Digest Pinning by Default in helm/defectdojo/values.yaml

Vulnerability

Lack of Image Digest Pinning by Default

Description

The Helm chart's default configuration in values.yaml sets the digest field for all container images to an empty string. The chart logic in _helpers.tpl falls back to using mutable tags when the digest is not provided. This creates a supply chain risk, as deployments are not guaranteed to be immutable. If an image tag is overwritten in the registry (e.g., a new 2.52.0-dev image is pushed), subsequent deployments will pull the new, potentially untested or malicious, image. While the chart adds support for digest pinning, it is not used by default, leaving users vulnerable unless they manually configure it.

django-DefectDojo/helm/defectdojo/values.yaml

Lines 36 to 39 in 8ceafd9

	digest: ""
	nginx:
	image:
	registry: ""

Insecure Use of 'latest' Image Tag in CI in .github/workflows/k8s-tests.yml

Vulnerability

Insecure Use of 'latest' Image Tag in CI

Description

The .github/workflows/k8s-tests.yml workflow explicitly sets Docker image tags to 'latest' for both Django and Nginx images. While this workflow appears to be for testing the Helm chart in a Kubernetes environment, using mutable tags like 'latest' introduces non-reproducibility and supply chain risks. A 'latest' image can change at any time, meaning that a test run today might use a different image than a test run tomorrow, even if the workflow definition hasn't changed. This can lead to inconsistent test results, make debugging difficult, and potentially introduce vulnerabilities if a malicious or broken image is pushed as 'latest'. Best practices strongly recommend using immutable tags (e.g., specific version numbers or image digests) to ensure build reproducibility and security, even in test environments.

django-DefectDojo/.github/workflows/k8s-tests.yml

Lines 69 to 76 in 8ceafd9

	defectdojo \
	./helm/defectdojo \
	--set django.ingress.enabled=true \
	--set images.django.image.tag=latest \
	--set images.nginx.image.tag=latest \
	--set imagePullPolicy=Never \
	--set initializer.keepSeconds="-1" \
	--set redis.enabled=true \

---

All finding details can be found in the DryRun Security Dashboard.

[mtesauro]

Approved

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[kiblik]

@mtesauro / @Maffooch, GHA is failing because of some unrelated issue. Can we merge this PR as it is?