feat(docker): Drop nginx debian

[kiblik]

Both Django and Nginx have been available for a long time in Debian and Alpine alternatives. However, Nginx has never been the true Debian image. Yes, Debian was used in the building phase, but only for running collectstatic. But final image is based on Alpine every time.

django-DefectDojo/Dockerfile.nginx-debian

Line 76 in 2b63f9e

FROM nginx:1.28.0-alpine3.21@sha256:d83c0138ea82c9f05c4378a5001e0c71256b647603c10c186bd7697a4db722d3

This PR drops support for building the nginx-debian image and supports only nginx-alpine.

• If there are no complaints about this idea in general, I will add related information to the release notes as well (I just do not want to waste time on writing it until it is clear that this PR will pass).
• If this is accepted, it might be a good idea to also simplify the generation of Docker tags (but in a separate PR).

[dryrunsecurity]

This pull request contains findings related to potential command injection vulnerability, information disclosure through workflow logs, and an unpinned Docker image version, with none of the issues being considered blocking risks.

Information Disclosure via `set -x` in .github/workflows/release-x-manual-tag-as-latest.yml

Vulnerability

Information Disclosure via set -x

Description

The set -x command in the GitHub Actions workflow causes commands to be printed to the workflow logs after variable expansion. The command docker buildx imagetools create -t "${{ env.DOCKER_ORG }}/defectdojo-${{ matrix.docker-image}}:latest" ${{ env.DOCKER_ORG }}/defectdojo-${{ matrix.docker-image}}:${{ inputs.release_number }} uses the ${{ inputs.release_number }} variable. While release_number itself is not inherently sensitive, if a user were to provide sensitive information in this input field, it would be exposed in plain text in the public workflow logs. The env.DOCKER_ORG and matrix.docker-image variables are also exposed, but these are not typically sensitive.

django-DefectDojo/.github/workflows/release-x-manual-tag-as-latest.yml

Lines 45 to 51 in c2bb89f

	- name: Set up Docker Buildx
	uses: docker/setup-buildx-action@e468171a9de216ec08956ac3ada2f0791b6bd435 # v3.11.1
	- name: Tag with latest tags
	run: |
	set -x
	docker buildx imagetools create -t "${{ env.DOCKER_ORG }}/defectdojo-${{ matrix.docker-image}}:latest" ${{ env.DOCKER_ORG }}/defectdojo-${{ matrix.docker-image}}:${{ inputs.release_number }}

Unpinned Docker Image Version in .github/workflows/integration-tests.yml

Vulnerability

Unpinned Docker Image Version

Description

The CI/CD workflow explicitly sets the NGINX_VERSION environment variable to alpine. This floating tag is then used in the docker-compose.yml file to specify the Nginx image version. Using a floating tag like 'alpine' instead of a specific version with a digest introduces a supply chain risk. The underlying image can change without any modification to the repository's code, leading to non-reproducible builds and the potential for new, unvetted vulnerabilities to be introduced automatically.

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

Lines 73 to 86 in c2bb89f

	run: docker compose up --no-deps -d postgres nginx celerybeat celeryworker mailhog uwsgi redis
	env:
	DJANGO_VERSION: ${{ matrix.os }}
	NGINX_VERSION: alpine
	- name: Initialize
	timeout-minutes: 10
	run: docker compose up --no-deps --exit-code-from initializer initializer
	env:
	DJANGO_VERSION: ${{ matrix.os }}
	NGINX_VERSION: alpine
	- name: Integration tests
	timeout-minutes: 10

Command Injection in .github/workflows/release-x-manual-tag-as-latest.yml

Vulnerability	Command Injection
Description	The inputs.release_number from the workflow dispatch trigger is directly interpolated into a shell command executed via run:. This allows an attacker with permissions to trigger the workflow to inject arbitrary shell commands. For example, if inputs.release_number is set to 1.0.0; rm -rf /, the rm -rf / command would be executed on the GitHub Actions runner.

django-DefectDojo/.github/workflows/release-x-manual-tag-as-latest.yml

Lines 45 to 51 in c2bb89f

	- name: Set up Docker Buildx
	uses: docker/setup-buildx-action@e468171a9de216ec08956ac3ada2f0791b6bd435 # v3.11.1
	- name: Tag with latest tags
	run: |
	set -x
	docker buildx imagetools create -t "${{ env.DOCKER_ORG }}/defectdojo-${{ matrix.docker-image}}:latest" ${{ env.DOCKER_ORG }}/defectdojo-${{ matrix.docker-image}}:${{ inputs.release_number }}

---

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

[Maffooch]

I am not strongly opposed to dropping the debian nginx image - especially since it never really existed... @mtesauro are you good with this?

[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.

[mtesauro]

I'm actually not a fan of musl c library vs glibc but since the final base image of Nginx is Alpine, I agree that mixing Debian and Alpine doesn't make sense for the Nginx image.

[valentijnscholten]

Approved is in itself it looks OK. However I think we should consider droppding Debian alltogether, i.e. also for the django image. Although I am a fan of Debian, the go-to base image seems to be alpine for most projects. The images will be ~20% smaller as well. And we can simplify our workflows, plus reduce the maintenance load on version update PRs.
cc @mtesauro @Maffooch

[kiblik]

Approved is in itself it looks OK. However I think we should consider droppding Debian alltogether, i.e. also for the django image. Although I am a fan of Debian, the go-to base image seems to be alpine for most projects. The images will be ~20% smaller as well. And we can simplify our workflows, plus reduce the maintenance load on version update PRs.

Fully agree with this. I'm happy to help with this, but I would do it step by step (now nginx, next django).
And I agree. Alpine is a more Docker-preferred solution. It is much smaller, and on average, there are fewer vulnerabilities.

[mtesauro]

@valentijnscholten @kiblik I've been working on wolfi based images to provide hardened containers for the project. I'd prefer to keep the Debian images around until we have a hardened replacement that uses glibc TBH.

The reason I'm not a fan of Alpine is the choice of musl and the strange bugs that can slip in when most distros use glibc. glibc has much better QA / QE / testing coverage due to it's much wider usage. Here's an example of these odd and painful bugs - or here or here.

Networks keep getting faster and disk storage is ridiculously cheap so trading off better tested underlying OS vs image size feels like a pretty good trade to me.

[mtesauro]

Approved

[Maffooch]

@rossops leaving the last approval to you so that you're aware of this change

[valentijnscholten]

In think the situation around Alpine had improved over the years. But I don't have a strong opinion on which distro to use. But I would like to switch to one distro only at some point 😄

[mtesauro]

In think the situation around Alpine had improved over the years. But I don't have a strong opinion on which distro to use. But I would like to switch to one distro only at some point 😄

I agree with the idea of a single distro for our containers. Give me bit to finish the hardened containers and I think everyone will be happy as they should have few to no vulns and be as small as feasible.