Transcript

00:00 Welcome and Intro
00:53 Agenda and Roadmap
01:47 Defect Dojo Data Model
04:10 Why Asset Hierarchy
05:29 Tags as Alternative
07:12 Hierarchy Mechanics
10:11 RBAC and Access
12:07 Whats New in V3
14:28 Design Tradeoffs
18:21 LLMs for Setup
21:52 Common Patterns
28:17 Marketing vs Engineering
30:24 Live Demo Walkthrough
37:33 Wrap Up and Q&A

  Thank you, Chris. Yes, so I'm gonna do a 101 to go back to the way the college I went to worked. A 101 level coverage of, uh, the asset hierarchy, just to get the, uh, the general knowledge out there, and I am, I'm looking forward to getting a whole bunch of questions and answering your specifics, 'cause those are generally much more interesting.

Um, but let's get this thing started. So for those who, who don't know, I am Matt Tesauro. Uh, I've been doing this AppSec thing and security thing and writing code for far too long, 20-plus years. I am the co-founder and CTO of DefectDojo Inc. I have been with OWASP since 2008, uh, actively participating in a whole bunch of areas, been on the board, et cetera, et cetera.

Um, and I do, I do like training, so this is right up my alley. I've, I've written a bunch of stuff. I like to speak. So let's get this thing rolling. So what are we gonna cover today? I will do kind of a quick flyover of what the asset hierarchy is and just some sort of background level setting, uh, before we get into what's new.

Um, this is what's new beyond just the hierarchy addition, um, and some ways that we've sort of integrated that into different parts of DefectDojo. I'll also talk about LLMs or your favorite AI friend and the hierarchy, and how you can use those to sort of, uh, speed up this process and give you some assistance.

So we've done some testing with that and it's worked rather well. Common hierarchy patterns. These are things we've seen customers that are currently using the hierarchy, what they've done with them from working with customers and just answering questions and understanding their problems, to give you some examples of how this can help solve your problems potentially.

I will tempt fate and do a live demo, although I have some screenshots in case things go completely sideways, and then we'll do a wrap-up. So let's quickly review the DefectDojo data model. At its heart we have organizations that have assets, that have engagements, that have tests. Tests are like those scans or a manual pen test, and those will have findings.

I ran out of space basically, but this gives you the idea. Um, longtime listeners, wink, wink, uh, will realize that this used to not be this way. It used to be a different way. This is sort of the new way, and one new thing we introduced in V3 of DefectDojo, which got launched yesterday in open source, is locations.

Uh, and we defaulted that to on for V3. Locations is just a... It-- For open source, it's a rewrite of what was endpoints, which we're now calling URLs, um, because one, endpoints have been around since the Dojo started, and two, there was a whole bunch of improvements we could do, and instead of making endpoints be this all-singing, all-dancing thing, we decided to do this locations idea, where locations gives you where the finding was found, and there's a lot of places findings can be found.

So this gives us a much more broad way to handle those, as opposed to cramming everything into what we originally called an endpoint. Uh, but like I said, if you're familiar with Dojo from the past, you're much more familiar with the, what I would call the original, and I'm gonna mess this up. I'm gonna say product type and product all over the place, 'cause I have 10 years of saying that.

Uh, but the original DefectDojo model was you had a product type that had products, those had engagements can have one or more tests have findings, and findings are connected to endpoints. This is the historical way that DefectDojo managed things. In this new world we have organization and asset, and it's then from there it's the same, right?

Engagement, test, finding, and then the, the final caveat, location now is used instead of endpoint. So really in some regards, this is a relabeling. Um, a lot of people in the community and also our customers just got confused. They're like, "We don't really have products. We have repos. How do I put a repo on a product?"

And it's... Well, at the end of the day, it's just an asset, really. D- Dojo never cared what was in a product type or a product, but this n- this naming structure seems to work better and, uh, reduce the cognitive load of our, of our user base, which is a good thing. And so this is how it works today. With that, and I've covered the base functionality, let's talk about the asset hierarchy, what we've added, uh, in Pro So why, why do we have a hierarchy?

I mean, honestly, software has not gotten any less complicated in terms of building it, right? People are doing more and creative things all the time in software. My goodness, it's changed in the times I've been around. The idea of the one big monolith that did all the things is fairly dead.

There's still monoliths, but not as many, or there's a lot of little monoliths maybe. So you have microservices, you have monorepos that combine, five or six what would be assets or products in the old dojo into one big repo. So is that a repo, or is that the individual constituencies? How do I model that?

How do I make sense of that? Different environments, shared infrastructure. Like, I get a lot of... I've had a lot of questions from customers in the community about, "Hey, we've got these services that four different of our you know, software stacks use. How do I model that in DefectDojo?" So this hierarchy gives you the ability to do those kind of things in sort of a cleaner, a cleaner method that's easier to sort of grok, for lack of a better terms, to just understand Um, I did say assets, asset hierarchy is a pro only feature.

So maybe you're using the community version and you wanna know what alternatives exist. This is what I used to do prior to there being an asset hierarchy. I used tags, right? So at an asset or if you wanna use the old term, at a product level, you can put tags, and then what I like to call a multi-value tag.

I don't-- I made that up, but hey, you know, I get to make these things up 'cause I'm doing the talk. But the idea of a multi-level tag is a tag that has multiple values in it. So this tag over here, BA:service:location, right? That's a multi-value tag 'cause I have three values separated by colons in the tag. So if you create a convention that explains how you want the hierarchy to be, you can do that via tags.

And then in community and in pro, we have the tag contains filter. So if I wanna know all of big app, I can do tag contains BA colon, right? And I get all of these. If I wanna only know the back end, I can do tag contains BA back end. Services, I can only do those two first pieces, right?

BA:service:. So this allows you to create that hierarchy in a flat model, um, using tags. So this is still very doable. Everything I'm gonna talk about hierarchy is still very doable in the community version. It just depends on the implementation, right? We give you a graphical representation and the ability to establish parent-child relationships.

In Pro, those aren't available in community, but you can still do this with tags. I did that for years. It works well. So I didn't wanna leave the c-community thinking that they were out of luck, 'cause you're not. So how do they work, right? They have an arbitrary depth. I can't remember. We put some guardrails around this.

I think we put it at twelve or twenty. I can't remember. We were kinda waiting for people to hit that guardrail, and then we can expand it. When we originally created these, we did performance testing to stupid levels. I think it was Two or three thousand deep hierarchies to make sure that it was performant.

I don't know why we would ever want a hierarchy that deep, but we did. So it, it is, it will allow you to go arbitrarily deep with some guardrails. I don't remember exactly where we put those. That was a while ago that we did this hierarchy. Uh, but the other nice thing is that although this is a hierarchy and you're establishing a relationship between assets, each of those assets function like the normal asset in the flat model, right?

So in this case, this web app front end functions just like as it-- or this web app front end prod functions just as if it was a child of organization in terms of RBAC, in terms of deduplication, right? We're just allowing you to structure those and then do some interesting things I'll talk about in some other slides with that structure.

But from a, a core feature set, all assets are trade- created equally or treated equally. Um, they just allow you to sort of have these relationships that you can do interesting things with So here's that other diagram redrawn. I did this. I probably could have done this better. You can tell I'm not an artist.

Um, just to re- represent the fact that you get a multiple assets. Now, each asset acts like an individual asset. Each of these assets in this sort of accordion thing can have an engagement, a test, a finding, et cetera. Um, and I put an eye chart in here that helps explain it. This is what I gave, honestly, our engineers when we first created this.

So this idea of an organization, so in this case DefectDojo Inc. Well, we have an asset called DefectDojo. We have other assets, like the Universal Importer and other things we create. In the case of the DefectDojo asset, well, we have Pro and we have Community. I can do engagements at the DefectDojo kind of global level, a super parent asset level, or I could do things maybe at just for the community.

Or I could even break down Pro into the Pro repo and integrators code, and maybe I even want another child for integrators for the integrator container, and maybe from the Pro repo I want the Pro Django container, right? I can do this arbitrarily deep nested structure that matches the reality of my engineering, um, but also gives me the thing that the C level and the marketing people talk about, this DefectDojo, right?

If, uh, somebody from the marketing department says, "Hey, we need to, you know, I don't know, increase ad spend on DefectDojo," they're not talking about the integrator code base. They're talking about the whole thing that, that is made up of multiple pieces

Uh, and then the final thing, RBAC and asset hierarchy. Like I said, all assets are treated equally, so the same RBAC, um, where you can assign someone to be either owning at the org level or at an individual asset level exists for a hierarchy. So depending on how your teams are, and I've never seen a place that ha- ran teams the same, but depending on how your teams are, you can either take...

create a group is how we do RBAC. Create a group that includes all of the children and add someone to that group, and bam, they have access to the parent and all its children. If they only have a single child that they need to manage, you can create a, a, an RBAC group with that. So you can add roles and remove roles, and basically take pieces of that hierarchy anywhere you want to allow RBAC access to the things that you need and not too much.

And then the global roles still apply here, so a global reader can read everything in Dojo, can read everything down the parent-child relationship. That should be fairly standard. But the hierarchy is interesting because if you have, say, third-party pen testers, you can now do interesting things like create a child asset that is the pen tester's report, um, or the pen tester's engagement or assignment or, I don't know, what is...

I guess I'd call it a statement of work. Whatever you wanna call it. But that pen testing activity can happen. You can give the pen tester access to only that one asset. They can input their results, but they can't see anything else except for the stuff they produce, right? Now, when you're doing the reporting, you can combine its parent and that pen test into one reporting unit.

But from a pen test pen tester able to see everything in your vulnerability management system, that's not... you can avoid that happening. You can keep that from happening Okay, what's new in V3? V3, which launched yesterday, so if you touch that three, you might get white paint on you. V3, very new.

So besides the hierarchy that I just talked about, there is a DefectDojo Pro has an insights, which is a collection of dashboards that allow you to see the data in various and sundry ways inside of DefectDojo. You can now use the parent-child relationship when filtering all of the different insight dashboards we have.

So if I wanna see what a parent and all of its children look like or just a section of that hierarchy, I can do that now with the dashboards. Which also means with a little bit of filtering, I can see just a tree, a whole section, any part of that hierarchy, which is really nice, and I can do trend analysis.

Like, how is this whole group doing against that whole group? Or How are we doing at the repo level? Maybe this product consists of five repos. I could compare those repos independently. And so it just gives you more flexibility, which is super nice. And if you created that structure, then you can do these roll-ups very easily, which is, uh, which is a great thing.

One of the, like, the equivalent in my big app tagging example, if I wanna see all of big app, I could do tag equals or tag contains BA colon. In this case, I can do one of these, and I'll show you this when I demo it. I can do product and all of its children and get that same effect, which is quite handy

Pro Reporting understands child assets just like we, we launched Pro Reporting, is it two weeks ago? Very recently. I don't remember when we launched it. It's been very recent. That's another one of the, where the paint is barely dry on it. Um, and to be 100% disclosing, I'm not sure if it made it in yesterday's release or it will be in the next release for Pro, but the ability to do that same child, parent, give me all of its children is part of...

Oh, it is part of. I'm pretty sure it's part of the Pro Report Builder. It's getting to be where DefectDojo has so much in it I can't keep track of it, which is, a good thing. Um, but this then allows you to do the same thing I was talking about with insights. I can report at the parent and all of its children level.

I can report on just a chunk of that hierarchy. I can report on a level of that hierarchy. Uh, whatever I need to do to sort of get my, my reporting needs handled via the hierarchy, and, and answer questions for the, the stakeholders that wanna see what's going on and why you're doing all this security work So when you're creating a hierarchy, things you need to think about, and these are the sort of the trade-offs you have to consider and, and how to make sure you, you engineer something that works for you rather than makes your life harder.

Um, I really like to focus on reporting granularity. I think that's one of the key things that Dojo is... I've used Dojo to make my life much easier, right? If I know that I've got a VP north of me on the org chart that's gonna ask me about a something, I kind of wanna make sure that something is really easy to report on.

And so think about that when you're doing the hierarchy, because if you do this I wouldn't say wrong, but in a less than optimal way, you could make that reporting much harder, and there's no reason to make your future life harder. It'll probably be fun enough without you making it harder. Uh, deduplication scope, this is a super interesting one.

How isolated do you want those assets in terms of deduplication? And I, I, hilariously, last week I had a call with one customer who wanted to dedup across branches in a repo. And so for them, they made one asset for that entire repo and engagements per branch, because they only wanted one representation of a finding across branches.

I think it was two days later, or shortly thereafter, I talked to an entirely different customer who wanted to isolate each branch. They wanted to know that the main branch had a finding that was also present in the feature one branch, that was also present in the feature two branch. So they wanted a distinction of deduplication across those branches.

Make them separate assets. That makes that really clear and easy. Now, they have these assets that end up being short-lived, right? There's no problem with that. Dojo doesn't care. If you want an asset that lives as long as that feature branch is alive, and when you do a merge to main, you can delete that asset, that's perfectly fine.

Dojo is 100% happy with that. So it just depends on how you want that deduplication to happen and how broad that scope is. So it's an important thing to think about. Uh, also RBAC, like I was talking about earlier, another thing to consider when you're setting up this hierarchy, how do my teams work and who needs to see what?

Who's logging into Dojo? Do they have read access? Do they have write access? What level of access do they need? All that stuff boils into your hierarchy, and you can make it easier or harder on yourself depending on how well you lay that out. So just something to think about. Um, luckily RBAC is very flexible, so I don't think you have to kill yourself on this one, but give it a thought.

And then future-proofing, right? And over-engineering. You can make this hierarchy so crazy complicated that you can report on anything, but it also makes general reporting a pain, right? Maybe you'd have an asset for... i'm trying to think of a silly example. Maybe you have an asset for every tool that you would want to run against your repo.

So you have a secret scanning asset for your repo and a, and a SAS scanning asset for your repo or something. I'm, it's, I'm, hard for me to be crazy off the hip. But if you did something like that, yeah, it would work. Dojo would happily do that for you. But you would also make your reporting really interesting, 'cause now I have to sum up all these different assets to just say what the repo looks like.

Does that make sense? Maybe it doesn't. But just think through that. The other thing to note, um, and this has been like a superpower of Dojo since day one, Dojo is very happy to have you move stuff around. If you decide that this asset is no longer a, a child of that parent, remove the parent.

Dojo's fine with that. Move it to a different organization. Dojo's fine with that. You can do those things, right? So there's a whole bunch of flexibility in Dojo, so don't kill yourself on this, but think it through and just understand what you're walking into. Um, it'll make your future life easier, which I am all about Okay, so get out your bingo cards.

I'm about to say AI and the asset hierarchy, right? So how can you use an LLM to make your life a little easier with this asset hierarchy thing? Uh, we've played around with that, and it's been very productive. So this is kind of a, a cool thing. And in general, speaking just in general about Dojo and how we're doing features, all of our features we want to have AI-ified, and typically AI-ified in a way

Not AI-ified, excuse me, API-ified in a way that AIs can automate this for you. So we'll always have a UI 'cause there might be a human wanting to click. We'll always have an API because there may be humans who want to write code to automate it, or there may be AIs that wanna use those codes to do that automation.

So we wanna sort of handle all three of those use cases for every feature Um, so setting up. So in this case, I'm gonna use Claude as an example. Pick your favorite LLM, kind of doesn't matter. But you tell Claude what my application environment looks like, what my team structure is, the tools I'm thinking about scanning or I've already, purchased, who I have to report to, the frequency.

Do I care about SLAs? You know, do I have a, a distinction between branches? All those kind of things. Just dump all that into a markdown file and feed it to your LLM, and ask it to lay out a hierarchy for you. And it will do it. We've tested this, and it, it works surprisingly well. Uh, we, we did a couple exercises of this where we had a fictitious company.

Actually, the one I'll use in the demo was one of them. And you feed an LLM, "Hey, this is what I... This is how things work. This is how I want it to happen, and give me a structure." And I have had consistent results. We've tested Claude and Gemini both. Consistent results, getting very usable structures out of that by just giving it a decent context via markdown and feeding it into the prompt.

So I would definitely recommend doing that. However LLMs can have a poor use of context and hallucinate, or however you wanna say they can make mistakes. Or you didn't tell them something important, and it produced a result that doesn't match your reality. Those are all things that can happen when you're dealing with AI.

So do validate against this and your understanding of your business's reality 'cause trust me, it's likely better than the AI's. Does the dedup scope make sense? Can you do the RBAC you need across that hierarchy, or is it overly complex? Can I do reporting, like that VP who I know is gonna bug me about that, you know, how their stuff is doing?

Can I get them a report in a couple of clicks, or is it gonna be a pain? And then is it maintainable? Is it so complex that I don't think I can even manage it, like mentally, let alone, uh, managing it in terms of data? So just run through it and make sure that, that the LLM's recommendation matches your needs And then when you get ready to do this, how do you do this?

Create your organizations first, create your parents and then children under those parents. You can create groups then for RBAC that represent the pieces of that hierarchy that you want to provide access to create an engagement for, importing and then start the CI/CD or however you wanna get Dojo data into Dojo, set those up and start rolling.

So this can be actually a very quick process. I don't remember... I mean, the, the prompt response time for this, these asks of LLMs that we tested with was no different than any other something. It was quick. I didn't time it, but yeah, this can be really easy, and you can bam, you can get a structure up in a heartbeat So what hierarchy patterns have we seen?

I think we launched hierarchy, was it around Christmas time of last year? I can't remember. It's been out for a while, and we've seen a lot of interesting use cases, so I'm gonna run through the ones that we've seen and what we've heard from our customers So team. So a lot of, uh, the, the people we work with are team-focused, and they have teams that own, apps or repos or some portion of the in- IT infra.

And so they use the teams to do that, those boundaries. Gosh, I can't speak. So they'll make an org for, say, the payments team, and an org for the platform team, and then underneath those, they'll make assets that make sense. And then maybe even sub-assets if they have, say, the auth gateway has a repo and it also has a container.

Well, then have a child of that auth gateway that's the container for that auth gateway. Those kind of things. Particularly for teams that are... It's been interesting. We have some customers that are very concerned about separating access, and others that are not. I think also it depends on size. Usually smaller teams with the a- app sec team is kind of the only person logging into Dojo, RBAC becomes obviously far less important.

But if you have dev teams or VPs logging in, then that RBAC becomes really, really crucial. But so in this example with the team setup, you can have that. You can have reporting. It's all based on team, which maps beautifully to the org and asset structure. Um, and RBAC boundaries are kind of writing themselves based on team, right?

If you have a VP that controls or oversees the payments team, give them read-only access to that org, and they can see everything that their charges are doing and where they're at, right? Works very well. Tech domains, I haven't seen this as much, um, but we have seen this in a couple of customers to where organizations that have sort of teams built on a, I don't know, tech stream.

I don't know if that's the right way to say it, but, like, large chunks of a technology. So if there's a whole group that does web apps for this company, they will make an org for the web app team, and then have assets underneath that org that represent each of the repos and all of the different things that team creates.

Same for infrastructure, mobile, uh, data platform. We've seen a bunch of data science stuff, um, coming in. Those kind of things work very well if you're more of a driven by large tech stacks, I guess, for lack of a better word, organization. And then usually those stacks have teams and VPs and all that stuff, so the reporting and the RBAC just flows, much like the team structure

Feature branches. This gets fun 'cause people do GitHub in about as many different ways as you possibly... Or GitHub. Git, I should say, and branching, 'cause it could be GitLab. Doesn't really matter. In as many ways as, as possible, right? Do you have a main and a dev? Do you have a feature branch? Do you have long-lived branches for versions?

There's a ton of different ways to do this. And so I think this is where my conversation earlier about deduplication really is crucial. If you want to make sure that feature branch A's findings aren't deduped against feature branch B's findings, then separate assets is a really clean way to do that.

And like I said, those assets don't have to live forever. Feature branch B can live until feature branch B is merged into dev or main, however you wanna do it, and you can delete that asset, and Dojo doesn't care. That's fine, right? Historically, you might wanna keep it if you need for auditing purposes, but that's, you know, that's your policy and what you wanna do.

But Dojo, it doesn't mind if you have short-lived assets. It's just kind of your decision there. But then if you don't care, like that other customer I talked to, you can make those engagements. That totally works, too. That is perfectly fine. And then I've... We even have some customers that have very ephemeral branches, um, and they are popping and removing assets on a regular basis because they wanna have the dedup, um, happen and isolate those branches to know that, like, a new branch isn't introducing a whole bunch of new vulnerabilities.

The other thing we have seen for branching is using engagements, 'cause you can do dedup at the engagement scope. I... That works perfectly fine. I think as a mental model, I never like when there's a technology where to get to the truth I have to ask a bunch of what if questions. Oh, okay, feature B, feature branch B, is that an o- is that an engagement or an asset?

Oh, it's an asset? I know dedup is scoped to that. Done. If that's an, if that's an engagement, then I have to go to a second level of questioning. Oh, do we have dedup per engagement for that particular engagement? So I, I really like when you can be consistent and have the same answer across all the things.

Nothing wrong with using engagement dedup. It totally works, but it's, like, more cognitive load on the people trying to manage the... Particularly if you start to get to big scale. I'd almost rather have a child asset, honestly, just to make the answer simple Uh, monorepos. So you have one giant repo that has all of the things that make up your product or maybe multiple products, right?

Shared services front-end, back-end, mobile all jammed into one giant repo, and that's perfectly fine. That works for a lot of companies. However, that's begging for different assets. And honestly, like, from, uh, someone who worked with a company that did a monorepo, hopefully your tools understand monorepos.

There's a lot of tools that don't grok monorepos, which makes, uh, scanning portions of a monorepo really interesting. That's a conversation for another time. But you can do per, you could call it module. I would call it, like, per directory, which generally in monorepos, or a subdirectory, uh, in e- in essence relates to either a team or a product or a service or some kind of unit of measure that has a VP and people who write code for it, et cetera.

And then because you can break that monorepo into pieces in the asset hierarchy, you can also establish RBAC just to, to the places where you need it if you are a company that, that finds access control important. It's really interesting. I love this about the fact that we have a company now that does Dojo, 'cause, like, I am seeing so many variations on this theme.

I saw a bunch when I worked at different places, but talking to people, it's been super interesting Ah, and then fundamental to all of this, I think this is just a fundamental problem that, that tech has, is there is a marketing reality, and this may be me being a bit tongue in cheek, and an engineering reality.

And so from a business perspective, we talk about the thing that we sell, right? So at DefectDojo Inc., we talk about DefectDojo. There's DefectDojo Community and DefectDojo Pro, and both of those have a whole bunch of features. There are several containers that make up both of those, either community or pro.

So there's complexity right there, right? But from a talking about the thing perspective, which is usually where the business or marketing talks about it, they'll talk about it at a much higher level. Engineering, I have a repo, I have a container, I have a small atomic unit. That's almost in contradiction to how marketing and the business think of things.

So you have this natural tension. Like, the business wants to talk about it at a very high level, an abstract level, and engineers, of course, we're down in the weeds. We wanna know, like, do you mean the, the repo or the container? Do you mean this line of the source, or what do you mean, right? You can reconcile those with a hierarchy, which I think is really cool, and I could spout on about this for a long time, but I think one picture does it all, right?

You're selling the robot, and marketing, you know, does websites and buys ad spend or whatever they do to sell this robot. Engineering actually makes all the cogs and gears and whatnot that makes that robot happen. And as an AppSec person, you gotta secure all of it, and somewhat more importantly, you have to report on all of it.

So being able to tell the business that the robot looks good or bad from a security perspective is important. But also being able to say that this cog right here has some serious problems, we gotta look at it, is also important. So that dichotomy between engineering and the business is just a natural aspect, I think, of tech.

But having a hierarchy gives you the ability to answer both of those constituents, uh, with grace, which is a good thing Okay, here's where I tempt fate, and I'm gonna do a live, uh, demo. And let me set the scene. So in our theoretical example, we are, um, we are Cyber Robotics Inc., and we're a company that sells robotic devices.

And marketing in the business talk about the Cyber Fido guard dog, so we have this robotic guard dog that guards things. The product teams, the engineering is particularly concerned about what versions of that dog are fielded, right? If there's a customer that bought version two, we need to know if there's problems with version two, 'cause we have to go track down those customers and get them to do a firmware upgrade or whatever it takes to rev that thing.

And so what vulns are in which fielded version is really what the product team cares about. And honestly, the business for that matter, right? If I've got all but one customer running one version, and that one customer has an older version that has a vulnerability, I need to know that so I can tell them, "Hey, you need to rev it."

And then security assets are gonna, or security assessments rather, are gonna happen at every fielded version, and then likely a main or a dev branch, depending just on how you do branching. So I'm going to switch to this tab, and hopefully I have not been, I've not been logged out, which is great. Um, so here under assets, we have the new asset hierarchy If I go here, I'm going to, in this case, filter for the Cyber Robotics Inc.,

'cause I don't care about the other orgs in this particular instance of DefectDojo. Okay, so here's all of the assets that are within this Cyber Robotics Inc. organization. You'll see this, which if I click on it, will pop up the existing hierarchy that I have, which is super handy.

Or if I'm setting up a hierarchy, or I just wanna look at it from a different perspective, I can select all of these since I have them filtered how I want them, and then click over here on this view asset hierarchy. And you notice, by the way, this, uh, version one two AD two is in the field, right? So I'm using tags to tell which ones are fielded.

2.0 must be a new release. We don't have anybody using that. Here is sort of the, the parent of all of them, it appears, um, in a development version. But let's look at this from our hierarchal, hierarchical perspective So, okay, so I have, yes, that cyber ... Let me zoom in a little bit. The, uh, cyber Fido Guard Dog is the parent, has a bunch of children.

Saving is important. And this parent is going to be-- The parent of this one will be this And let me save that. And let me refresh this. There we go. Yay! Okay. I can demo this, I swear. So now we have this set up, right? And we have all of our parent and children. What this does from a reporting perspective is, or as a metrics perspective rather, if I go to the insights now, I'm just gonna go to the...

We have a ton of different dashboards here. I'm gonna just use the executive insights for simplicity. Let me get rid of this restriction. I could do this and just get the whole org, but I actually wanna look at the asset level to show what, what you can do with asset hierarchy.

So if I do CR

Wait, come here you C-R-C-Y. There we go. If I do cyber guard dog and I include the child assets, it will automatically create all of those things we just saw in the hierarchy and add them to this. I can apply filters. Excuse me. And now I have, here's the organizational summary of where the findings are at. I can look at the different versions and get an overview.

Okay, this version needs help. It's got way more active versus all the others. Apparently, this old version is pretty good. It looks like we're trending in the wrong direction, honestly, if you go up versions. But now I have decent metrics. Now I, I, unfortunately, I added... Last night when I was practicing, I realized I had no findings for these, so I added them.

So our trend graphs are pretty terrible 'cause there's a trend of one day or overnight. Um, so if you, if you clear this, these graphs look much better if you look at it from a high level. So you'd get graphs that function for these if you had time series of data. Active mitigated and risked over time active findings, active, uh, findings by risk, findings over time, tests over time, tests performed over time, et cetera, right?

So these, these graphs work when I have time series data, but when you add only one test to all of the, uh, assets the night before, you don't get great time series data. But that's how it-- that's how the hierarchy can help you do reporting. And then if I only wanna do a portion of those assets, I could do, um-

Wait, CF. Right, if I only wanna look at the one series, I could select only the one series and apply filters, and now I only have the one series. If I wanted to look at two by itself, I do the same filtering. I can cut and slice that, those sections of the hierarchy in any which way I want to, which is kinda super cool.

Um, and then if you're interested in this or curious, we have, uh, very good documentation on this asset hierarchy and all the different things you can do with it and how to edit it, and make sure you save, which I forgot to do while I was demoing. Um, but all this is up online as well. Let me jump back here.

And wow, it's almost like I knew, it was prescient. I took screenshots, so this deck can live with decent representations of what I just showed you, but here's that view of the assets, and the... This is a flat structure before I did anything, and here's where I did the first round before I did the 2.0 Whoo.

Okay, so key wrap up and takeaways. The data model, like, is important. I think that really helps with reporting and RBAC and all those other things I talked about. It's one of the... The flexibility of Dojo, I think, is one of its killer features. Um, we did hierarchy because it sort of reduces the cognitive load of people using Dojo.

Tags work, but you just have to remember and, uh, make sure your teammates follow that tagging scheme that you create. So it's, it's a little bit harder, but it's very doable. I've done that many times. Uh, we've then taken the hierarchy and made our reporting and our metrics understand it, so you can do interesting slices of that hierarchy after you've set it up.

Because we have APIs for all this stuff, y- you can get LLM assist you in doing this work, particularly if you have very complicated or tons and tons

of, of assets to deal with and you just don't wanna go through the drudgery. Dude, LLMs love doing drudgery work. Give it to them, it's fantastic. Uh, common patterns, I talked through those, and then RBAC.

RBAC is very important with this. I think I've beat that horse enough. And then key takeaways, plan before you start. You don't have to kill yourself here, but the more pre-planning you do, the better. There's, this is kind of a nuanced thing. Dojo will let you change. You saw me mess up the hierarchy and then fix it live on, on stage, so to speak.

So it, Dojo's flexible, but if you do a little thinking ahead of time, you can avoid painting yourself into corners that you have to go fix. I've never worked for an app- AppSec team that was the same across many of them in different sized businesses, so there's no right answer. That's just why we try to make Dojo as flexible as possible.

I think one of the crucial things you have to think about is where you care about deduplication, and do I care that, like in the branch example, that branch A is getting deduped with branch B or I want those separated or not? And the hierarchy gives you yet another security boundary for RBAC. And then questions.

Whoo. I'm gonna take a, a sip of something to drink and, uh, I will happily answer any questions people have