Unpatched HIGH Vulnerabilities in defectdojo-django & defectdojo-nginx Image - How can i help you patch this?

[danileau]

Dear community

I noticed during my automated build scans that the defectdojo images django & nginx themselves contain vulnerabilities which are HIGH.
Is it possible to patch them?
If it's just a question of free resources, may I support you? I have already patched the django findings myself by updating the following libraries in a Dockerfile and then rebuilding the Image and would just need instructions on how to return the patched version to the community (opensource contributor noob)¨

RUN apt-get update
RUN apt-get install -y libc-bin=2.31-13+deb11u7
RUN apt-get install -y libgssapi-krb5-2=1.18.3-6+deb11u4
RUN apt-get install -y ncurses-base=6.2+20201114-2+deb11u2
RUN apt-get upgrade -y

defectdojo-django:

defectdojo-nginx:

Thank you for your feedback and happy holidays
Dan

[mtesauro]

Dan,

Thanks for providing the changes you made to the container builds - others in the community could certainly use those if they are in a similar situation as you are in in terms of container issues.

Couple of things to get you an answer:

(1) First, for people who aren't you, we have a process to report security issues already in place - GitHub discussions isn't the right place to raise these issues. (Yes, I know you [Dan] also submitted this to HakcerOne). The process to submit security-related issues is outlined at https://github.com/DefectDojo/django-DefectDojo/blob/master/readme-docs/SECURITY.md

(2) The DefectDojo project provides both Debian and Alpine based images as a convenience to the community. Generally speaking, Alpine images have fewer issues when scanned with tools like Trivy at the cost of using the musl C library vs glibc. For those who don't want to build their own images, the Alpine images are another option which may better fit your circumstances. We build both nginx and defectdojo-django images using Debian and Alpine bases. We also run both dependabot and renovate to keep libraries updated in the code we control as well as using the latest available upstream container images e.g. #9194

(3) My personal recommendation for anyone using any open source project is to build your own images - this not only ensures you can do that in the future should you want to alter upstream source but you can add/remove anything else necessary for your specific situation. We provide dockerfiles in the repo, so feel free to use those to create images that meet your requirements.

(4) Our images are rebuilt on a weekly bases - either as part of a minor version release (e.g. 2.29.0) or bug-fix releases (2.29.3) every Monday between the monthly minor version releases. If you update image references weekly, you should be running an image that was updated to the latest packages provided by either Debian or Alpine no longer than a week ago. This is an aggressive schedule of updates generally and especially for an open source project.

For example, for the issues you list in the defectdojo-django container:

• libc-bin is currently at 2.31-13+deb11u6 and will be updated to 2.31-13+deb11u7 (the version you suggest) on next Monday's release
• same for ncurses-bin (6.2+20201114-2+deb11u1 => 6.2+20201114-2+deb11u2), libgssapi-krb5-2 (1.18.3-6+deb11u3 => 1.18.3-6+deb11u4), etc

So this is somewhat a matter of when the scan was run and when the last release happened plus when upstream packages are updated by either Debian or Alpine.

(5) The DefectDojo project was recently provided a complementary license to RapidFort which we're currently testing this with the end goal of providing a further hardened image for the community. We don't have an ETA yet on when that testing will be completed but once we're generally confident in the hardening process, we'll start providing hardened image as part of our normal release process. Keep an eye out for new options and updates to our images and dockerfiles going forward.

So, I appreciate you sharing the process that worked for you. I'm sure there's many in the community that will have similar requirements and utilize what you've provided.

As an open source project, we need to strike a balance between providing generally useful software that fits the broad needs of the community and addressing every possible use-case. We also have to balance adding complexity to handle more and different situations that the community may have against the time the contributors have to write code, test it, and otherwise improve DefectDojo in general. Being open source, we don't force the community to do or use anything they don't want to since they have access to the same source that makes up our releases.

Cheers!

-- Matt Tesauro