dev: hot reloading improvements celery/html/tpl

[valentijnscholten]

Improvements to hot-reloading/autoreload:

• fix path to /app/dojo/settings/settings.py
• also reload on .html and .tpl changes
• enable autoreload on the celeryworker

For celery it could be done without watchmedo, but that would require installting pypi package celery[dev] which would end up also in production. I'm not sure of the impact of that, so I avoided it.

[dryrunsecurity]

This pull request contains minor security observations related to development dependencies, file permissions, and a development script in the production image, all of which are currently marked as non-blocking and pose minimal risk to the application's overall security posture.

Unnecessary Development Dependency in requirements.txt

Vulnerability	Unnecessary Development Dependency
Description	The watchdog package is added to requirements without clear separation between development and production dependencies. This could unnecessarily increase the application's dependency attack surface if deployed to production without careful filtering.

django-DefectDojo/requirements.txt

Lines 76 to 79 in fdb714f

	PyYAML==6.0.2
	pyopenssl==25.1.0
	parameterized==0.9.0
	watchdog==6.0.0 # only needed for development, but would require some docker refactoring if we want to exclude it for production images

Overly Permissive File Permissions in docker/entrypoint-celery-worker-dev.sh

Vulnerability	Overly Permissive File Permissions
Description	The umask 0002 setting grants group write permissions to newly created files, which is less restrictive than typical production security practices. In a shared environment, this could allow unintended file modifications by group members.

django-DefectDojo/docker/entrypoint-celery-worker-dev.sh

Lines 1 to 26 in fdb714f

	#!/bin/bash
	umask 0002
	id
	set -e # needed to handle "exit" correctly
	. /secret-file-loader.sh
	. /reach_database.sh
	wait_for_database_to_be_reachable
	echo
	if [ "${DD_CELERY_WORKER_POOL_TYPE}" = "prefork" ]; then
	EXTRA_PARAMS=("--autoscale=${DD_CELERY_WORKER_AUTOSCALE_MAX},${DD_CELERY_WORKER_AUTOSCALE_MIN}"
	"--prefetch-multiplier=${DD_CELERY_WORKER_PREFETCH_MULTIPLIER}")
	else
	EXTRA_PARAMS=()
	fi
	# do the check with Django stack
	python3 manage.py check
	# hot reload using watmedo as we don't want to install celery[dev] and have that end up in our production images
	watchmedo auto-restart --directory=./ --pattern="*.py;*.tpl" --recursive -- \
	celery --app=dojo worker --loglevel="${DD_CELERY_LOG_LEVEL}" --pool="${DD_CELERY_WORKER_POOL_TYPE}" --concurrency="${DD_CELERY_WORKER_CONCURRENCY:-1}" "${EXTRA_PARAMS[@]}"

Development Script in Production Image in Dockerfile.django-alpine

Vulnerability	Development Script in Production Image
Description	The Dockerfile includes a development-specific entrypoint script that could expose unnecessary configuration details or debug features if used in a production environment. This increases the potential attack surface by including non-essential scripts with potentially less secure configurations.

django-DefectDojo/Dockerfile.django-alpine

Lines 67 to 73 in fdb714f

	COPY \
	docker/entrypoint-celery-beat.sh \
	docker/entrypoint-celery-worker.sh \
	docker/entrypoint-celery-worker-dev.sh \
	docker/entrypoint-initializer.sh \
	docker/entrypoint-first-boot.sh \
	docker/entrypoint-uwsgi.sh \

---

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

[mtesauro]

For celery it could be done without watchmedo, but that would require installting pypi package celery[dev] which would end up also in production. I'm not sure of the impact of that, so I avoided it.

I agree with this ☝️ thinking

[mtesauro]

Approved

[Maffooch]

This is legit life changing