Where are product components in DefectDojo?

[aleks-liu]

Hello, community!
I’m new to DefectDojo and am trying to understand the set of entities conceived by developers. I’m feeling a bit frustrated with the "Product" concept. Despite carefully reading the documentation, I’m still struggling to apply it to real-world cases.

To simplify the issue, let’s assume a typical case: a corporate web application supporting a specific business function. Let’s call it “System A.” In most cases, this "System" consists of several sub-systems—e.g., front-end, back-end, database, API server, custom-coded components, etc. These sub-systems are often developed by different teams, and the severity of a vulnerability can vary from one sub-system to another, even if it has the same CVE.

Given this, how can we apply the “System” and “Subsystem” entities to DefectDojo concepts?
What entity in DefectDojo corresponds to “System A”? The first thing that comes to mind is "Product." But in this case, what entity corresponds to the “Subsystem”? They don’t seem to exist. DefectDojo applies “Engagement” to “Product,” but does it suggest we should use the same "Engagement" for all "Subsystems"? That doesn’t seem practical: we can't have the same "Engagement" representing SAST for both the front-end and the API server.

If I link a “Subsystem” to DefectDojo’s “Product,” how should I differentiate, for example, the API server in “System A” from the API server in “System B”? One option could be using appropriate titles:
DefectDojo's Product 1: "System A API Server"
DefectDojo's Product 2: "System A Backend"
DefectDojo's Product 3: "System A Frontend"
DefectDojo's Product 4: "System B API Server"

While this is possible, it forces me to consider a business application as a set of independent products. Does anyone else think this is a bit strange and confusing? Obviously, I want to see a complete list of vulnerabilities across a business application (which consists of multiple components), and in this case, I would need to somehow link different DefectDojo products that belong to the same business application together. This could be done using titles (as above), tags, or "Product type," but it feels like I’m having to create workarounds for something that should be a fundamental part of the design. Why doesn’t DefectDojo create entities that more closely correspond to real-world software? From my perspective, what I call a “System” is essentially a “Product,” and what I call a “subsystem” could be called a “Component,” which could be added as an entity between "Product" and "Engagement."

Community, please share your thoughts. Apologies if I’ve misunderstood something—I’d be happy to hear where I might be going wrong and to better understand DefectDojo's philosophy.

[valentijnscholten]

Initially Defect Dojo was invented as a tool to manage Pentests (engagements) per product. These pentests weren't really split up by subsystem or API or frontend. I believe this is the reason the model is Product. And later on Product Type was added to group products together. What I've been doing in the past is using Product Types for Systems and Products for subsystems. I didn't have any use cases that didn't fit in this model. But it might be impractical if you have lots of microservices. For microservices within the same Product there is the Finding.service field. This can be used to import multiple scans for different microservices into the same Test.

For v3.0 an overhaul of the model was considered, but I believe the conclusion was that currently it would be too big of a change to accomplish in the short term: #11199.
But where always happy to hear specific examples/usecases/feature requests.

[aleks-liu]

Got it. Thanks! Now it's clear.

[mtesauro]

As one of the people who drew out the original design on for DefectDojo on a white board, I can talk about some of those early decisions:

DefectDojo was created in the Product Security team at Rackspace whose scope of work was all the projects/apps/efforts/APIs that made up Rackspace's Cloud Offering at the time. This was a HIGHLY complex system just like you're talking about.

So, what's the deal with Product_Types and Products? Those were primarily created to make reporting on groups of things easier. If Product_Type is "Compute" and all the many things that make up that compute product line (with a VP of Compute) are under that product_type, telling that VP what their 'stuff' looks like is really easy. Think of Product_Types as a way group related things for reporting.

About your front-end, back-end, API products question - yes, I've seen and done it that way. I've also seen and done similar things with Tags. Again, you need to know all the things about the Block-storage part of the Compute Product Type? Do a filter for all products with the "block-storage" tag and "boom" you've got the results you want.

Rackspace and any cloud provider has a diverse, ever changing environment so DefectDojo was designed to flex, bend and change in crazy and unexpected ways - you just have to think about what the goals are for the data your importing into your DefectDojo instance.

I did an entire talk on this. I've attached a PDF of it here and it shows several VERY different fictitious companies store and sort data into DefectDojo. There's 73 slides there with loads of details on that 4 "companies" including why they stored and sorted data they way they did.

Haystack to Needle 08-2024 Office Hours.pdf

I thought the talk would be posted at https://defectdojo.com/events - however, I don't see it as I'm typing this but do realize that someone is currently and actively working on that part of the site so in the future the video may be there depending on when you're reading this.

Anyway, HTH.

[aleks-liu]

Understood! Thanks! Now it makes sense.