What exactly is the intended workflow for DefectDojo?

[KramNamez]

Hi! I'm really struggling to figure out how DefectDojo is intended to be used - it seems to fight me at every step and that generally means I don't understand what the right path would be.

My situation (and that of several others) is that I have a handful of tools that all report vulnerabilities in some way or another. Container scans, secrets scans, SBOMs - whatever, bunch of different tools in different teams.

I'd like to have those all centrally managed, so that there's not a duplication of effort and so that it's easy to see problems at a glance. At first glance, it seems that that is exactly what DefectDojo is supposed to do. However, it seems very ill prepared for actually dealing with automated tests that run in CI/CD pipelines.

By default, not only does it want an expiry date for an "engagement" (weird, but okay; I can just set a long duration and hope to be okay) but every time a scan runs, it will generate a new "test" with potentially hundreds of findings - ludicrously unwieldy and completely unmanageable. Okay, so we treat it as a re-import instead, so that findings can get deduplicated.
Now I no longer have absolutely overwhelming amounts of findings, but I can no longer do any sort of risk acceptance in DefectDojo, because the re-import overwrites that every time! Maybe do_not_reactivate helps? Sorta, but now there's a note every time, which eventually just fills up the database, and is a ton of noise that I don't need either. (I'm told that's a new feature and there is a fix in the works for this.)

All of this tells me that DefectDojo is not really meant to be used for automated, regular tests. But then what is it good for? Is it merely an Excel-replacement for managing pentest and similarly one-off reports?

The two example workflows in the DefectDojo documentation show exactly those kinds of workflows - no automation whatsoever, just a single test, where someone sits down to analyze an application and one where a manager looks at results from multiple teams. Neither of these cover CI/CD integration or handling repeated tests.

How is DefectDojo meant to be integrated with repeated, automated scans and CI/CD pipelines?

[tillkuhn]

It seems we're in the very same situation as @KramNamez: Each day our CI Pipelines are producing tons of Trivy scan reports. And at a glance Defect Dojo looked like the right tool to push and consolidate those reports at a central location in order to track the findings, and map them to the projects that triggered the CI Runs.

By using re-import endpoint, and carefully crafted values for engagement_name, environment, product, close_old_findings etc. we somehow managed to achieve a result close to what we expect. But it still feels that we're misusing DefectDojo in a way that it's not intended to be used, and also the terminology that focusses on tests and engagements adds to the confusion.

So I'm really looking forward to feedback on this discussion, maybe from some users who are actually using DefectDojo for similar purposes. Right now there don't seem to be many alternatives for Vulnerability Management on the open source market, so I also see a lot of potential for this project in mostly automated environments. Thanks!

[mtesauro]

Have you seen this? https://www.youtube.com/watch?v=FMUrL3Jzmzg&ab_channel=WeHackPurple
It's a recent overview of DefectDojo including handling CICD runs. It may help.

[MarkusTeufelberger]

In the example pictures it just says "push to DefectDojo", but in the demo later it is explained that Engagements (https://documentation.defectdojo.com/usage/models/#engagement) have 2 types, "Interactive" and "CI/CD". The latter can be set to never end (I assume: Set the end date e.g. 200 years into the future since an end date is actually required when creating one) and is apparently designed to be continually filled with new information over long periods of time while not keeping old information around that was already fixed(?).

It doesn't cover the question of granularity (do you create engagements for every docker container that you use or do you keep a engagement for a whole kubernetes cluster open for example), but I guess that's a bit up to the user as well. Similar with auto-discovery I think - especially using something like service meshes it might be possible to create and update some basic information automatically, but DefectDojo seems too flexible for that and rather requires someone to set up every.single.little.service.by.hand. Or you need to write something using the API that will be very specific to your use case.

[MarkusTeufelberger]

https://github.com/secureCodeBox/secureCodeBox seems like something that can be used to continuously feed DefectDojo old and new information.