Transcript

00:08
Thank you very much, Chris. Let's get this ball rolling. Yes, like he said, this is tackling common use cases in DefectDojo. And the whole idea here is, and this is fundamental to DefectDojo, is you shouldn't have to bend your processes or change things because you get a new tool, the new tool should adapt to how you do things. So what are we gonna talk about today? I just kind of teased this, honestly. The guiding principle, when we created DefectDojo,

00:38
A while back, it was specifically written so it could adapt to how your security program works, not you adapted DefectDojo's view of the world. Meaning you don't have to change processes. And this is just honestly because of the environment it grew up in. It started at Rackspace. I was a product, I ran product security for Rackspace and every team did things differently. There was zero consistency across teams at DefectDojo.

01:07
All right, this is excuse me at Rackspace. So DefectDojo had to be malleable because that was the environment it grew up in. And so it's never changed. And that's been a fundamental design principle since day one. So what's ahead? I'm going to go through some examples of how to structure DefectDojo, both looking at the flexible RBAC model that DefectDojo has, as well as the data organization. So you can test however you want, whenever you want.

01:35
however you want and you can track and report it all in DefectDojo. At least that's the idea. Little bit of like wavy screen flashback action. Pretend you're getting that doodly doodly thing happening. In previous talks, I've used this diagram. You may have seen it before. This is kind of the big picture of DefectDojo. You have some sort of targets. You do some sort of testing of them. All of that flows into DefectDojo.

02:03
And then all of that goes to, and then those consolidated and deduped and normalized findings go to downstream stakeholders. So if you're shifting left, I had a previous talk on this. This is about getting data into DefectDojo. Um, this talk is really going to be talking about putting data into DefectDojo in the most effective way so that those downstream stakeholders ideally can self-serve, right? And you don't have to do anything, but give them a login.

02:31
or at least you can produce reports if that's more your thing that fit the needs of those stakeholders. And then DefectDojo has some smart features that I'm going to briefly cover just so that if there are people new to Dojo, they understand. DefectDojo will duplicate findings across tools. It can automatically close fixed vulnerabilities for you.

02:53
It can auto assign findings for infrastructure scans, and it can keep track of false positives and automatically keep marking things as false positive the first time you go in and say, hey, this is a false positive. It'll remember that and keep marking that for you. And then DefectDojo's data model, for those who haven't seen it, you can have one or more product type. Product types can have one or more product. Products can have one or more engagement.

03:22
or more tests, tests have findings and findings may or may not have endpoints. Like SAS scans don't really have endpoints per se.

03:33
But that's the data model. And when it comes to the data model, particularly for this talk today, it's really those top three ones, which is where you're going to be making decisions, product type, product and engagement tests, findings, endpoints, those kind of, I wouldn't say they don't matter, but those are kind of very standardized, you're going to run tests. They're going to find things and they may have endpoints that doesn't really affect how you do reporting and organize the data in dojo.

04:03
But really it's those top three where the thought process is. And then one last thing before we get into the case studies. Excuse me, I have a bit of a, I'm getting rid of a, or I have the lingering remnants of a cold. If for some reason you can't quite get the data model where you need to, DefectDojo supports tags all over it.

04:26
And that can get you that customization last mile. So if there's some kind of edge case or odd thing that you need to keep track of that doesn't really fit the data model perfectly, there's always tags. And there's things like finding owners or findings of the idea of owners. So there's a whole bunch of ways you can make this happen.

04:46
All right, so let's get into the case studies. This is the meat of the talk.

04:52
And yes, the names have been made up to protect the innocent. These are really just an agglomeration of different times that I've used DefectDojo, people I've talked to that have used DefectDojo, customers we have, just sort of general principles based on a bunch of experience of seeing DefectDojo in action.

05:14
So this is BigCorp, or at least fictitious BigCorp, which we're saying is a large multinational enterprise. And in the case of BigCorp, there's a CISO and a centralized IC security group that includes AppSec. The key concerns for BigCorp are consistency of testing across their different business units. They want to enforce policy, which is how you get the consistency, but also they have compliance requirements.

05:42
And some of the business units have PCI compliance as well that they need to keep track of.

05:50
And then security at BICORP, it's highly centralized. There's some things that are delegated out to BISOs, which are like business unit CISOs, basically, business information security officers, if you want the thing de-acronymed. But the goal here is to avoid compliance and regulatory issues, while ideally having a good, solid testing standard that goes across all business units.

06:20
Key stakeholders, SISO and BISOs, obviously product owners and then compliance and internal audit teams Also have a role to play in the security at BigCorp And then what it looks like structurally is There's a centralized SISO office that owns all security for BigCorp Each business unit has what's called the BISO like I mentioned earlier that owns security for that business unit

06:49
And then product owners own security for their product. And then there's compliance and audit that report directly to the CTO. So they're sort of adjacent to the security team, but an important player.

07:03
Excuse me again. R back at BigCorp. So the security team owns a security program that reports up through the SISO. Bezos want to make sure that to understand and make sure their business unit is doing the right thing. They're not drifting or have problems. Product owners have that same perspective but just focused in on the product that they own. And then developers in this case want to work in JIRA. That's where they're already working. They don't want yet another thing to log into.

07:33
They're happy where they are, so let's not mess with them.

07:37
So in terms of setting up RBAC at BigCorp, here's a representation of DefectDojo in this BigCorp fictitious example, they have a consumer electronics business unit, a consumer goods and a power generation business unit. And in this case for admin access, the security team owns DefectDojo and in DefectDojo RBAC speak, they would be given the role of global owners. So they own

08:07
and can see everything inside of the DefectDojo platform.

08:13
Next one, read-only access. So, BISOs, the business unit, or the business information security officer, right? Gets read-only access so they can see and do look at how they're doing within the confines of a product type. So for the case of BISO number one, they have access to consumer products. And number two has access to consumer goods.

08:42
And of course, number three has access to power generation. So they just have read-only access. They can go in and see what they need to see.

08:52
Next, in terms of owner access at the product level, product owners will have what's called in DojoSpeak product owner RBAC permission, which means for example, product owner one, the product owner for smart speakers has only access to that product. Same for product owner two, which is smart refrigerator for refrigerators, same for product owner three, smart meter platform.

09:20
And this continues for the different product owners on the different product lines, all the way down to the seventh and eighth one. So each product owner has a view of DefectDojo that's confined to just their product. They don't like smart ovens, can't see how smart TV is doing, and can't see how the smart meter platform is doing because of our back.

09:43
And then in this case, developers have no access, right? They're going to log into Jira. DefectDojo has bi-directional integration with Jira, so it can push things there. So there's no reason in this particular case for BigCorp for developers to log into DefectDojo, at least they don't want it, right? Up to you.

10:01
And then testing at BigCorp. So they run CI, CD jobs that run SAS, SCA, and secret scanning. Every product gets a threat model. Some products have PCI, and some products get third-party pen tests. So let's look at testing at BigCorp graphically. This is a bit of an eye chart. I apologize. It got a little cluttered when I drew this all out. So we're going to zoom in.

10:30
to smart meter, here's smart meter. And so for smart meter, they're doing CI-CD runs, which is that SAS, SEA and secret scanning. You've got threat modeling, and you've got a Q1 2025 pen test, which a third party pen testing outfit is gonna do. Not too bad. And then the case of grid maintenance, they're doing the standard CI-CD three.

10:57
Tests as well as a threat model, they're not having third party pen testing in their case.

11:06
And then for centralized meter billing, they're doing the threat model and the CI-CD thing. They're also doing a third party pen test, but they're also subject to PCI. So in their case, they're gonna do what they call a Q2 pre-PCI assessment, which is basically them running their own kind of quasi-PCI audit to make sure that when they actually do the third party PCI audit, it comes out clean, or at least as clean as they can get it.

11:35
So here's an example of how you can use the data structure to divide up things in any way that makes sense to your org. You can have one engagement that has multiple things. So if we wanna know how centralized meeting looks like in terms of CI, CD, this engagement tells us. If I wanna know how the third party pen test went, I can look at this engagement and it tells us. So you have a lot of flexibility.

12:02
Cyber Robotics. So this is a robotics company that has embedded software in the robots. They actually create and field assembly line robots with embedded software. So it's a very different environment than Big Corp. They have a chief product officer that oversees product and cybersecurity. And for them, they really need to understand what customers have which version.

12:30
of these robots because it's embedded software, it's on-prem at wherever these factories are. So once you sort of deliver a robot, they need to make, they need to understand that this factory has version seven. This other factory has version eight because I've got an update for eight, but not seven or whatever. Safety and security of fielded robots is obviously very important. Like nothing like having a robot like take out a factory worker to cause bad press. And then.

13:00
They do R&D on the next line or generation or whatever you want to call it of robots. And in their R&D department, they're really concerned about IP theft primarily. They don't want a competitor to find out the next cool robot they're coming up with some kind of cool and interesting features. So security at cyber robotics. It's really focused on a small number of product lines, but because multiple...

13:28
versions can be deployed in a field, they have a very different view of the world, right? If I'm a SaaS company, I have the version that's in my SaaS product, period. Well, this company can have multiple fielded versions, so they have a very different look of the world than your kind of air quote normal software company. And they wanna ensure that fielded robots have the latest software updates, particularly if there's any functional or security issues.

13:57
The key stakeholders, obviously that chief product officer, each robotic product line has an owner, and then customers with deployed robots which is really support personnel, because if they do have to do an update, then they have to have a body like a person get in a van or whatever and drive down to a factory and do an update. So this is an expensive operation, so they want to avoid those and only do it when it's strictly necessary across the versions that are fielded.

14:28
Um, security, there's a, the organizational structure for security. There's a chief product officer that owns the app sec program. And then each product line has, like I said, a, a robot product line owner that owns app sec for that particular robot product line, and then support personnel. Focus on a single product line. And we'll go off and do those field updates if necessary.

14:56
RBAC at Cyber Robotics. The Chief Product Officer just wants to make sure the AppSec program is doing okay. They're not having issues. They're on top of things across all of the product lines. AppSec team members are the ones that manage day-to-day operations. The robot product line owners want to make sure their product line is doing okay and there's not any sort of problems in their future or they're keeping up with what they need to keep up with.

15:25
And then support personnel need to know if there's any updates or statuses in their product lines. Cause I may need to go, like I said, get in a van and drive down to a factory and schedule some maintenance time or whatever.

15:38
Okay, so for admin access, the AppSec team basically owns DefectDojo. They'll get the role in RBAC called global owners and they will have access to everything within the cyber robotics DefectDojo platform.

15:56
the chief product officer will get global read-only access so he can go in and use it anywhere. Or he can go in and not use it. He can see anything within DefectDojo, not use. He can see anything in DefectDojo. He can keep track of how the welder, the robotic welder is doing versus the HVLP paint robot, right?

16:22
product type access so the product owner, the robotic product line owners will get product type writer access so they will have write access within a product type so for the R&D department that robotic product line owner will have access to will have write access to both of the products. For the HLPV the painting robot.

16:52
That product owner will have access to three different fielded versions as well as that entire product line. And same thing for the welding robot. So the welding robot product owner will have access to this piece of defect Ojo.

17:08
Read-only access, so for support personnel, because they're related to a product line, they will have read-only access, but restricted within a product type. So for the paint robot, the HVLP, painting robot support people, they will only have access to this product line. And for the robotic, they will only have access to this product line, and there's no support people for robots because you haven't fielded anything yet, so there's no real access.

17:37
support wise for those. And so interestingly, you'll notice that in this case, product type really became the product line and products became the versions of those products. This is an example of how you can use defecto just model to do whatever you need. This is a very different environment than the big corp, but they're still able to model things and get the data out in the places and to the people that they needed.

18:06
Testing at Cyber Robotics. Obviously these are embedded systems, so they wanna make sure they get testing done upfront before they actually ship one of these things out and drop it in a factory. Internally, they're doing CI, CD, SAST and SCA. They have what's called a security control reviews as sort of a desk check to make sure all of the software has the necessary controls put in it. And they also do network scans.

18:32
And then they have third party code review. So an external consultancy or whatever will come in and review their code. They have security safety attestations for some models because some factories may require some sort of attestation that says this robot is safe to whatever standard it is. So I tried to do a global model for cyber robotics. It was impossible. So I just asked AI to drop.

19:00
to give me an image of a ridiculously complicated diagram, and that's what you're getting. But we'll zoom in, in our case, to the painting robot. And in this case, we have the three different fielded versions and a bunch of testing. Let me zoom in further. Well, actually, let me look at this. So the product line of the paint robot has three different fielded versions. For this 168 version,

19:30
They do CI-CD runs, they do what they call a pre-release scan, which is basically just a SAS scan. It's had an external code review, it has had a security control review, and a safety attestation. Third party went in and said, yes, this robot is safe with whatever the requirements are for that security review. 174 got CI-CD runs, that pre-release scan, external code review, security control view, but not a security attestation, so apparently this factory doesn't require that.

20:00
And same for model 203.

20:04
If you look at the welder robot, pretty much the same thing. Some of them have the safety attestations. All of them have the CI, CD. Some of them have this, well, all of them have this pre-release run. And some of them have had a security control review and some of them haven't. So there's just in various stages based on where they are in terms of the life cycle of that product. And then for R&D, there's no real products. So they're not.

20:31
scanning code necessarily because it hasn't been productized yet. Instead, they're really worried about IP theft. So in their case, they're only doing network scans. Once again, another demonstration of how for different product types, you can change what engagements and how things work because for the R and D department, the SAS scans and those things don't really make sense, particularly things like security as destination, because we haven't made a product out of it yet. It's just research.

21:01
um, Kate's cloud service is a modern software company doing Kubernetes and microservices and all the cool, cool kids buzzword things.

21:12
So in this case, there is a VP of cloud that oversees cloud product security. There's also a CISO, but this is focusing in on the cloud portion of the business. Key concerns, avoiding security issues, particularly cross-tenant, right? If you've ever run a multi-tenant infrastructure, customer one attacking customer two is really a bad thing that you don't want to see happen, so Cates.

21:40
is very concerned about those kind of issues. But they also have to be very agile. They're a rapidly changing cloud environment. If you've ever used any cloud provider, how often does it change? Almost frickin' daily. So they have to be agile as well. And then they have a lot of shared services. This generally happens in larger distributed systems. You have shared services, so they need to have some kind of governance and understanding of how those shared services work, particularly from a security perspective.

22:11
So security at Cates, it's focused on automation because like I said, they want to move fast. So they are doing automated everything they possibly can, as well as having tech leads triaged, whatever the automation comes up with. So tech leads will triage the findings that come in from automation, parcel them out amongst their product offering, their cloud, excuse me, cloud offering, and then go get them fixed.

22:40
So they use, like I said, automation to get max coverage with minimum human time because they wanna be fast. Key stakeholders is a SISO that's in charge of all of security for CAITs. And then a VP of cloud and then the cloud product tech leads.

22:58
From a structure, the SISL office owns all of the security program. The VP of cloud owns product security for the cloud offerings. That's the person, a theoretical person who brought in DefectDojo. And then cloud offering tech leads like the compute or the storage or whatever load balancer, tech leads own security for their product.

23:23
And then thinking about how things work at Cates, particularly in terms of RBAC. Sysl owns all security, which means their cloud offering, but also support. Now support isn't gonna be in DefectDojo for whatever reason, politically, structurally. In this case, they have a separate group handling the support side of the org. So in this case, we're primarily concerned with product security. And like I said, the VP of cloud.

23:51
needs to understand how all of their cloud offerings are doing. The cloud product tech leads want to know how their piece of the cloud is doing. And then there are developers who generally work in JIRA, but they want to be able to log in to DefectDojo and comment on security issues.

24:12
So in this case, admin access, product security owns DefectDojo, they got the global owners are back rule.

24:21
Global read-only access is given to, well, some analysts basically that work for the VP of cloud so that they can produce the necessary metrics and report to the VP that everything's going okay for these various cloud product lines.

24:38
Maintainer access, so tech leads have maintainer level access at the product type level. This allows them to go in and triage results for all of the different pieces that make up their product. So cloud storage gets access to cloud storage, compute gets access to compute and all of its subproducts, and same things for shared services.

25:04
And then individual developers will get what's called writer access within their products that allows them to do things like risk acceptances, also to do things like say, hey, put in what's called a peer review to request a review and say, hey, this thing is a false positive. Hey, this thing, the scanner says it's a high, it's really a medium because of X, Y, Z, whatever, they can provide feedback. And so the various teams have access to their

25:33
Products like this is the web console, the web console API and the REST API for cloud storage. Same thing for compute devs. Same thing for the devs for shared services.

25:48
So testing, like I said, at Cates is very automated. There are a few things I have to do on a schedule. Like externally, they're required to do annual pen tests, so they don't automate that because it's a third party. But they're doing SAS, SCA, secret scanning, DAS, they're using IEC and container and Kubernetes scans. They're looking at their images and their image artifactory. All of this is automated.

26:14
And then in their case, the only really external thing is third party pen tests, which are required by compliance.

26:22
Again, this model was crazy. In fact, even if I zoom in on just the cloud storage, it's pretty much an eye chart, so let's zoom in even more and look at just the web console. So in this case, the web console, they have CI CD runs and for each run, they're running SAS, SCA and secret scanning, pushing those all into this single engagement.

26:47
They have what they call a deploy review, which is basically running a DAS scan before they make it available to customers. They're doing a Kubernetes scan that they call the K8 review. They have an annual pen test. And then they have a container review where you have container image scanning, Docker file linting and artifactory registry scan, all of those running together and being combined in that container review. The API for web console for this

27:16
part of the cloud, also is doing the CI-CD, also is doing those deployment scans, also is doing the container reviews. Fairly similar, not quite exactly the same as the prior. They don't have third party pen testing in this case. And then in the REST API, also for compute, it's running the same CI-CD three scans, the deployment review or DAST basically, annual pen test and then the container review.

27:45
Some special notes about K8s is they had shared microservices as I mentioned. So they actually have a product type to handle those shared services. Like things like, like customer addresses or billing or those kinds of things that every service needs to use. And they use tags on those products. I'm doing air quotes. They use tags on those products to say which.

28:13
services rely on that shared service. So if compute and storage both rely on the customer info service, let's say, those would be tagged with compute and storage. So that if there's a problem in the customer shared service, they know they have to go talk to the teams that are compute and storage in our fictitious case. And then their cloud offering or their.

28:40
their tech leads for the various cloud offerings change frequently because they're constantly adding new products. And as they add a new product, the current tech lead may become the tech lead of that new product and someone else will come up behind them and take their place. And so they're changing frequently because they're growing frequently and there's rapid, well, just flux within this cloud product offering. So because they change frequently, they instead use tags to denote

29:09
what tech lead owns this, and then they have an external mapping that maps those tags to which is, who is the current tech lead, because they just changed too rapidly. They don't wanna go back and rewrite data, it doesn't make sense.

29:23
Final use case is Sassy Software. They're a software as a service company that originally had one offering and then acquired a bunch of others. So now they have multiple offers.

29:34
In the case of company structure, there's a director of quality engineering and that director oversees the app sec program. Key concerns they don't want public security issues and because they're selling a SaaS offering there's certain compliance programs like sock and ISO and all those others. That they need to maintain because to be able to be purchased by some companies, they have to show that they beat those got those standards. They need flexibility of tuning tooling because they bought

30:04
things from acquisition. So they may as a company have started with their single product and really liked, I don't know, SAST, let's say check marks, but they buy a company and for them SAST is SEMGREP. Well, okay, fine. At the end of the day, they're worried about you have SAST, not you're using this particular vendor. And reporting on main and feature branches. So for this software company, they do a lot of main and feature branch work.

30:32
And so they need to be able to report and understand what's in main, what's in this feature branch, how are they different, what is the security state of those various things.

30:43
Like I said, the security efforts are focused on customer impacting things, particularly when it impacts customer confidence, because there's a level of trust when you're offering a SaaS service. And then compliance certifications, obviously they want to keep those up to date and have no issues there. So once again, their goal, they don't want security issues to negatively impact customer confidence. Key stakeholders, SISO and the director of quality engineering.

31:10
product owners and then the go to market or the sales basically team and compliance teams.

31:17
And then if you're thinking about the security structure, the SISO owns all security for SASE software, including desktops and everything. Director of Quality Engineering owns just the AppSec team across the various SaaS business units. Each business unit has a product owner who's responsible for their product, no surprise there. And then go to market and compliance teams advocate for customer and compliance requirements. If there's a...

31:45
If customers keep asking about, do you have, I don't know, this whatever compliance requirement and they don't, or if you meet this whatever standard and you don't, then GoToMarket will work with compliance to make sure that they get that certificate or certification, whatever, and then so they can now sell to a different body of customers.

32:08
The SISL wants to make sure, oh, I messed up this slide. I'm sorry, copy and paste. This should say SASE software. That's my bad. Copy paste error. The SISL wants to make sure there aren't any landsmines. The director of quality engineering wants to ensure that AppSec is effective across all of their SaaS offerings. Product owners handle risk acceptances, track product metrics within their product. Developers can request peer reviews, but otherwise can't.

32:38
do any kind of changes within defect ojo. Like they can say, hey, this thing should be a high instead of a high instead of a critical. And then QE and compliance want to monitor and track issues to make sure we don't violate any of the compliance regimes, etc.

32:57
So admin access or in DefectDojo speak, the global owners will be the AppSec team. They have access to all of the platform. For writer access, the product owners will have writer access within each product type. This allows them to do things like do risk acceptances, gather metrics, et cetera. So each of the different product owners will have access to their product line or the really their SaaS offering in this case.

33:28
Developers will have read only access, but even with read only access at the product level, those developers can go in and say, hey, I would like to submit what's called a peer review. And then have a security team address that review triage it. Oh, you're right. This really should be a critical or a high instead of a critical whatever They have that access and that works. I didn't draw this out, but that works for all of these different product teams and they're isolated within just the thing that they work on.

34:00
And then global reader gives read only access global reader being the R back term and dojo gives read only access to both the QE analyst and the compliance team so they can go and make sure everything's working as it should across all of the product lines.

34:18
Testing at SASE, they're focused on major categories. Like I said, they're standardized on kind of the type of test rather than the vendor who is providing that scanner or whatever it is. So for CICD, there's a whole bunch of different things they do based on basically acquisitions within that product line. They do DAS, container scans, threat modeling. There's compliance audits and also third-party pen tests.

34:47
So this is another one where the thing was crazy. So I'm zooming into pieces of the chart because I couldn't fit all of the chart and have it be readable on one page. In fact, I'm gonna zoom in to just the front end because this gets hard to read. So if we look at the front end, they have a main branch. And for the main branch, they're gonna run CI, CD tests, SEA, and then manual code review, as well as threat modeling. All this happens against the main branch.

35:16
For their various feature branches, they're running their CI-CD as well as SCA, but that's it. That's all that feature branches get. And same thing for a hotfix branch, if they have to create one. If there's a hotfix, they'll create a branch, CI-CD tests fire against that branch as well as SCA scans.

35:35
If you look at the backend, same story, right? We have a main branch that gets the full Monte, they get everything. And then feature and hop-vics branches get just CI, CD and SCA. Because at least we're not going to be adding those problems to the main branch when those merges happen, that manual code review and threat model can handle any sort of more higher level issues that can't be fared out by CI, CD or SCA in the feature branches.

36:05
And then the main branch is what becomes their SAS product.

36:10
Special notes for SASE, they're really focused on feature branches. So they need to report on the currently deployed software, which is the main branch. But they also want to report on future versions of this SaaS offering, which is their feature branches. And because you can have multiple features being worked at at the same time, they have multiple things they need to report on. If there's three feature branches in a main, that's four things they're reporting on.

36:39
branches in DefectDojo is very possible. The product is a piece of the product line via product type. And then the engagement represents the branch. So in this case, you saw in those diagrams, they'd have a main branch or a feature branch or a hotfix or whatever you call your branches, but each engagement can be a branch. And then you do deduplication at the engagement level. And that keeps things from, that keeps the branches isolated in terms of reporting.

37:09
Because generally speaking, if you're doing main and feature branch, if I have an issue in the feature branch that doesn't exist in main, I don't want deduping at the product level to say, oh, this is fixed in this engagement, but not in the feature branch engagement. Therefore, I'm going to dedup that. You don't want that happening. You want duplication within those branches. So I can know that there's drift or problems in the feature branch before I merge it into main. So this is something that DefectDojo has done.

37:39
kind of forever, is you can do deduplication at two different levels, at a product level and at an engagement level. And so for SASE software, if they have products that don't have branches, they would use dedupe at the product level. But because their SaaS products do have main and feature branches, they're gonna do dedupeing at the engagement level. And it doesn't matter how you get dode.

38:07
data into Dojo, if it's import or reimport, whatever, deduping still works at both the product and the engagement level. And if you like to see this visually, here's an overlay on that product hierarchy. It's the same thing, so within a product, this is where dedup happens, within an engagement, this is where dedup happens. And if you've looked at our documentation, you'll see these diagrams, which is just another graphical representation of it. Here's where deduping happens at a product level.

38:36
at an engagement level that's broken down by engagement.

38:41
And I said, I would talk about porting. So I'm gonna do a quick fly through of reporting. When you're doing reporting, product type is a natural place to aggregate results, right? That is a thing to think about. If you look at all these examples, where they needed a higher level cross company view, those generally were product types. Products kind of are the beginning or the start, I guess you could say.

39:06
of focused reporting because we're now getting into more granular areas, sort of zooming in a bit. You can filter by engagements, product types, tags, tons of ways that you can slice and dice data within DefectDojo. A lot of companies or users of DefectDojo will make a naming convention for engagements, and that's another thing you can filter on just as a pro tip.

39:32
And then if you need to, you can always go to the all findings view and there's loads of filters you can do there. So if you can get the data in and the right structure, you can make your life really easy and do self reporting. Excuse me. For DefectDojo pro we have what are called insights, which are a series of dashboards those allow now filtering on product type products and product tags.

40:00
So not only do you have the default dashboards that show whatever your RBAC allows you to see, but you can do further filtering if you have say tagged products within a product line and for some reason a VP wants to see only a subset of that product line, they can do that via say product tags.

40:20
And then just some examples of where RBAC can help. These are, these are happened to be dashboard tiles from DefectDojo Pro. Here's the pro. Here's an example of a demo system with some dashboard tiles. If you pay attention to this bottom row, 18, eight, nine, 74 and eight. This is with a global read access user. If I log out and log back in as somebody who has limited RBAC, suddenly those things update now at 16, zero, 22 and one.

40:48
Right. So whatever your RBAC is gives you a view of the data. This is where you can get self-service for reporting. Right. As if I have a RBAC login and I only am allowed access to a subset of the data, all of the things, these dashboard tiles, same thing for the global charts. Um, here's example of it. Much different date, much different data between global and not global RBAC.

41:16
Same thing for the graded products. Here's all of the products. Globally, if I only have access to two products, guess what, I'm gonna see grades for two products. Same thing works for the various insight dashboards. Here's a global version. Here's an RBAC version with radically different numbers because the scope is much smaller. Same thing for remediation insights. Here's all of Dojo. Here's a slice of Dojo. And so the key takeaways here.

41:46
DefectDojo's model is flexible by design. There's no reason to change how you do things. You can just fit into Dojo, whatever you need to, and make it work for you. And if you do that correctly, you'll end up mapping stakeholders to reporting needs. And if you combine that with RBAC, you can suddenly have stakeholders self-serving the data they wanna see just by logging into Dojo, and it'll adapt to that user's view of the DefectDojo world, so to speak.

42:15
Dashboards, charts, all that stuff will only show the data that the RBAC permissions of that particular logged in user have access to. And so if you take data model and then those visual and reporting insight graphs I showed you, stakeholders can keep informed on their own, right? They can log in, they can do filtering like I showed you by product, product type, product tag. And you can demonstrate the value.

42:43
of the work of security teams to either globally if you're at that level or for individual, say products in DojoSpeak. And those visualizations have trend analysis and a whole bunch of other ways to sort of show how your program is working or not working and where you need to give more or less effort. Whew, and I'm gonna take a drink and we can hit questions.