requirements.txt missing from image defectdojo-django:2.51.0

[cadehuismann]

From this PR it looks like both the requirements.txt and requirements-dev.txt should be in image in v2.51.0 but I'm only seeing requirements-dev.txt. Am I missing it somewhere or is it supposed to be removed in favor of the requirements-dev.txt file?

% docker run --platform=linux/amd64 -it --entrypoint /bin/bash defectdojo/defectdojo-django:2.51.0
defectdojo@/app$ ls
components  dojo  manage.py  media  requirements-dev.txt  tests  unit-tests.sh	unittests  wsgi.py

/$ find /app -type f \( -iname 'requirements*.txt' -o -iname 'requirements*.in' -o -path '*/requirements/*.txt' -o -path '*/requirements/*.in' \) 2>/dev/null
/app/requirements-dev.txt

[valentijnscholten]

It's caused by #13209.
What do you think @fopina . Should we ensure the requirements.txt is present in the generated Docker images?

[fopina]

Ah got it, so you take a fresh base image and you copy selected things over from the published image? Such as the app dir itself I suppose.
That makes sense.

about requirements, from my change perspective, -dev being there is definitely the miss, not sure how it happened. It’s not even installed in that image. Or maybe it is, I’m not sure what image is pushed to docker hub, as I always build mine from the repository

As a quick workaround for you, would running “pip freeze” in the upstream image in a separate stage help?
It should dump every package installed, maybe it’s too much

[valentijnscholten]

@cadehuismann If you're doing this build process anyway, would it not be easier to just build from source?
On the other hand I am not cinvnved that having the requirements.txt in the docker image is a big risk. It might actually help users in their risk asessements/triage to know what's in the image.

[cadehuismann]

Yep, exactly — we start from a clean base image and selectively copy over pieces from the published DefectDojo image (like /app, configuration, and supporting binaries) as part of our hardening and dependency verification process.

Having the requirements.txt file available in the published image just makes that step a lot cleaner — it allows us to re-install or verify dependencies without needing to clone or reference the full source repo.

Using pip freeze as a workaround would definitely work in the short term, though it’s a bit noisier since it captures transitive dependencies too. The original requirements.txt gives a more curated view of what’s actually intended to be installed.

Totally fair point on the minimal risk of including it — I’d agree that keeping the requirements.txt in the image could actually help with reproducibility and security review.

Thanks both for the quick replies

[fopina]

I understand your point and I think there are different yet valid approaches to hardening, however my understanding it slightly different:

• if I want to review an application, I review its code, not a system where it’s installed
• If I want to pentest it, I test the whole system, that includes transitive dependencies as part of the system
• If I wanted to harden a system/container, I look at everything installed, both system packages and all python dependencies, all possible gadgets for exploitation - transitive dependencies not being pinned would actually be an issue in my hardening perspective. New versions come out all the time with issues
• Reproducibility in my day2day means the ability to produce the same artifact (image) with the same source (Dockerfile) - that’s not exactly what you’re looking for

I keep my vote on keeping them out: production-grade containers should be as clean as possible (-dev.txt to be removed)

That being said, it seems there’s no env var or label being set in the images with the release number, just the tag (which is lost in “latest”), maybe I can open PR with that too @valentijnscholten ?

Just thought of another solution for your issue (regardless of why): check dojo version and curl requirements.txt directly from GitHub for that tag (no auth complexity as it’s open) 🤷

[cadehuismann]

Sadly we also work in an air-gapped environment so can't curl out. We will just have to manually update our own repo with a requirements.txt file and maintain it, although a little tedious still doable. Thanks for all the help!