django-DefectDojo icon indicating copy to clipboard operation
django-DefectDojo copied to clipboard

Adding a "component" / "service" data structure below products

Open fhoeborn opened this issue 2 years ago • 2 comments

Is your feature request related to a problem? Please describe We have Products with multiple components / services. Each component / service will be built into its own docker container image. We are scanning our docker container images with a vulnerability scanner. Per container we create an engagement for the scan and add tests per done scan. We use the “close old findings” feature to keep track, what is still an active vulnerability and what not.

As a lot of vulnerability findings are coming from common issues in the base image, so for multiple components / services we will see similar vulnerabilities. If we would deduplicate on product level, we would run into the problem that those similar vulnerabilities across components / services get deduplicated. And when they get solved in that one container image, it gets closed off, even though it might not be solved in the other docker images.

Now to solve that problem we could create one Product per component / service, but that would blow up our product count pretty much. With our current solution to bundle those components / services into an engagement we are misusing that engagement data type a bit and it’s not blending into the metrics.

Describe the solution you'd like An idea to solve that could be to create a structure below the product called something like “component”. It would be good to be able to deduplicate inside the "component"

Describe alternatives you've considered We also thought about using "product type" as the full bundle of all services inside a "product" and then make a "product" for each service. From our understanding the “product type” is more suited for something like a “business unit” that might span multiple products (e.g. you have a business unit doing "Tax software" and one doing "accounting software - I totally made those examples up).

fhoeborn avatar Sep 07 '22 08:09 fhoeborn

+1, we face the same issue and currently have to flatten our application/service hierarchy for this and use Custom Fields and tags to point them to actual repositories. If implemented, this would be massively helpful.

jaskaransinghdr6j avatar Sep 12 '22 21:09 jaskaransinghdr6j

Have you tried the service field when importing the findings? It should do what you need, by adding an additional layer to deduplication. Findings in a product are not deduplicated, when they belong to different services.

StefanFl avatar Sep 19 '22 18:09 StefanFl

I tried out the service field in a test setup. My test setup was the following: Two identical scans uploaded to different engagements (deduplication set to product level) with two different service names per upload. It didn't seem to care about the service name and deduplicated anyway.

Broken or did I miss something? (we are on v. 2.14.0, but I didn't see a fix in that part in a quick changelog check...)

fhoeborn avatar Oct 19 '22 07:10 fhoeborn

As @StefanFl mentioned, service attribute was designed for that. if it doesn't works it's a bug. we should focus on understanding why service attribute doesn't works.

damiencarol avatar Oct 22 '22 09:10 damiencarol