Transcript

00:00 Welcome and Agenda
01:01 What Is the CRA
01:45 Scope Fines and Classification
03:59 Key Dates and Core Duties
04:53 SBOM and Reporting Workflow
06:33 DefectDojo CRA Readiness
06:59 Locations Framework for SBOMs
08:32 Reporting Feature and End to End Flow
10:03 Getting Data In and Triage
11:22 Deduplication and Enrichment
14:16 Remediation SLAs and Verification
15:19 Practical Next Steps to Comply
17:28 New PSIRT Engine Preview
20:14 Q&A and Closing

 Hi everyone. Happy Wednesday. Thanks for joining us today. My name is Greg Anderson. I'm the CEO and, uh, creator of DefectDojo.

And, uh, we've been getting a lot of questions around the, the CRA and so we wanted to put a webinar together to, uh, talk to the community. About, uh, what it means in, um, preparing this presentation. We have tried to look, uh, specifically of the letter of the law. There is a ton of blogs out around the CRA and so we wanted to make sure that, um, everything we were pulling from was directly from the actual regulations and annexes that, um, have been published.

And so, um. With that said, here's kind of what I've paired to prepared today, uh, deep diving specifically on what do these regulations actually mean who's subject to them and, and how you achieve them. 

What Is the CRA

And so, uh, starting with thirst, like what is the CRA? There's this new, um, Cyber Resiliency Act in Europe and.

We've seen a, a ton of regulations in cybersecurity come and go. There have been, you know, some regulations in the past that people have been concerned about, and then they didn't turn into fruitful things that change our industry. Uh, we believe that CRA will be different because it's heavily inspired by GDPR and, you know, GDPR.

Is one of the most successful, uh, regulations in changing behavior. And so when it comes to the CRA, I think we will see the exact same things that happen with GDPR happen with the CRA. 

Scope Fines and Classification

So, when we talk to customers, the concern today is primarily in Europe. And then, what happened with GDPR is once this regulation actually came into enforcement and there was some notoriety about enforcement actions against Google and Facebook, uh, the world kind of woke up to this regulation.

And so, um. Really the key takeaway about fines, penalties, and scope is that they are very similar in GDPR. They're meant to be scary. They're meant to be high, to actually drive enforcement. And this applies, uh, not just to EU companies, but any company that's doing business in Europe. One of the things that I've found really interesting about this regulation that I haven't seen a ton of people talk about is there are, uh, classifications that define how you have to do the reporting and to what extent, um, the thing that we have like painstakingly gone over with regard to classification.

Is who gets to decide your classification. And from the regulation, everything says that the company gets to select. And so, um, oftentimes there's a difference between what these things actually say and how it's enforced. And I think this will likely be one of them because they've done, there's a section where they try to essentially spell out all the possible categories, but you essentially get to self-identify.

So, uh, what, what I think we'll see tested is, uh, who gets to go into the self-assessment category. That's, um, what I expect to see. And so, kind of my joke is, well, I, I think we're just going to be a gaming company that produces vulnerability management software. Can you do that? Can you get away with it?

I'm, I'm sure the practical answer is no. But like, we just didn't see it in the regulation today. So, don't do this. But I don't know, in, in terms of just looking for like interesting loopholes, this was one of the ones that, that stuck out to us. But if you're on the consumer side, if you fall into this default category, um, congratulations.

Like you won't have to do a lot of work. If you unfortunately don't belong in that category there there are some things that, that need to be done to comply with the regulation. 

Key Dates and Core Duties

And so, um, when we talk about the key dates, like this is something that is already coming. Reporting obligations start this year, and then full compliance where the fines kick in is, um, later.

And so, excuse me, I expect that. We'll continue to see primarily you know, Europeans driving interest around this today. And then I think there will likely be a panic in the rest of the world starting around the actual enforcement date in, um, December. And so, outside of the reporting requirements, these are kind of the key things that you need to do.

It's hyperfocused on. Vulnerability management. Uh, it gives you things like remediation timelines, which we'll talk about. It also requires maintaining a complete sbo m in specific formats and then other key elements that your vulnerability management program has to have. And in some cases, uh, companies will have to prove.

SBOM and Reporting Workflow

So when we look at the SBO M requirements, um, in addition to maintaining a total inventory, the other thing that the regulation is really big on is what specific formats you have to be able to export in. And so, um, those today are a Cyclone DX or, um, the Linux Foundation standard. And so, with regard to those, like both will be exportable in that format, uh, from DefectDojo, and we'll get to that in a little bit.

But, uh, with regard to reporting obligations, there's basically a three step process. So the first is. You have to notify these regulating authorities 24 hours after initial discovery. And then, uh, within 72, you have to make a determination on exploitability, et cetera, and actual impact. And then, uh, with regard to the final report, there's also remediation requirements that go along with the 14 day timeline.

And then, so this is kind of what the reporting workflow looks at, um, at a high level with regard to what you have to do and when from the initial report to giving a full report to, uh, remediation. And then we already talked about it a little bit. The penalties are pretty wild on paper just as GDPR was.

I don't know if these are exactly in line with GDPR, but they're incredibly close. Uh, again, we expect the regulating authorities to take all of these pretty seriously. And then, you know, normally. Um, what we saw with GDPR was there was, uh, an example made of certain companies in the beginning that, uh, drove adoption around the world.

Once those enforcement actions achieved notoriety. 

DefectDojo CRA Readiness

And then, so finally, like, how do we actually deal with these things? How do we comply with these things in practice? Um, when we look at DefectDojo's capabilities, um, we're like 90% of the way there. And so we'll talk about the two changes that we're making and how close that they are to be in complete compliance and make people that have to, um, deal with this regulation, make the process as simple.

As easy as possible. 

Locations Framework for SBOMs

And so, um, the two enhancements that we need to make is first on SBO management. Today when we look at vulnerability data, we are only tracking, um, components that are vulnerable. And there's other things that we're doing to enhance the global view. And so, um, the goal is we have this new framework called the locations framework that is.

Eminently slated for release. Um, this is one of the biggest changes to DefectDojo that we've ever done because it changes some of the really core pieces of the platform. If you're already using the platform today, if you're, you're familiar with DefectDojo. You'll probably know that there's a concept of an endpoint.

And so what we did is we replaced that model with something called locations. And the goal of locations is to, um, span data on anywhere vulnerabilities can be found. Endpoints has kind of been Frankenstein already to account for some of these, but this is, uh, an incredible clean, uh, re-implementation of that.

So we still have things like, uh. Endpoints, but we also now have one that is dedicated to SBOs, um, and it's meant to give a global view. Across all assets in the composition of global assets, and you'll also be able to upload to these directly. So rather than just tracking things that are vulnerable, we're going to a system where you can produce, um, complete SBOs for any asset vulnerable or not for the sake of complying with this regulation.

Reporting Feature and End to End Flow

Then the other thing we're looking to build into the platform is direct management of the reporting access. So this is a super, super early mockup. Um, we've only kicked around different mockups on what this can look like. None of the code has been, uh, written yet for this feature specifically. But, uh, this isn't a particularly difficult feature to do.

Submitting data, uh, essentially an email for the purposes of reporting, and then managing and tracking that is, um, is a really easy feature to do to say the least. And so once we're done with locations, which is slated for, uh, it's, it's very, very soon not to, cause any angst with our engineering team.

But I expect this as a feature we'll see in the timeline of, um, weeks. It's something we've been working on now for almost a year, but. It just happened to align really well with, uh, what the CRA is bringing out, uh, additionally. And then just to walk through the process, kind of start to finish at a high level.

This is how we see it in Dojo. So bringing in your data, triaging the results, deduplicating those from all the different tools. We then enrich that with, uh, threat intel and other exploitability information so that you can look at the risk or if you need to report on the risk for regulation purposes.

Uh, you can do that, how things get remediated and then verifying they actually got fixed. And so, uh, to walk through that process. 

Getting Data In and Triage

When it comes to importing things into DefectDojo, this is an area we try to be ultra flexible on because just everyone tends to get data in differently has been our experience.

So I, I personally always like to start with the API connectors because. I'm lazy, to be honest with you. This is the easiest way to get data in, but it requires that, you know, you can access the tool and that it comes in a reasonable format. This is pulling data directly from your tools so you never have to do anything.

And then we also offer, um, like push options via our CLI. You can even add things directly from the UI if you want to, but we try to make getting data in as quickly and easily as possible. So that people can do the work that they need to do quickly. And then, uh, with regard to triage, this is something that the platform does automatically as well.

Every time you bring a scan in, for those that are new to Dojo, we have this function called reimport. The goal of reimport is to automatically compare, uh, what changed in scans to keep the results clean and accurate with regard to what's open or what hasn't been fixed or has been fixed. And so you can see that, uh, in the right with regard to the action history for each scan that came in.

Deduplication and Enrichment

And then with regard to ddu, DDU is a secondary mechanism that, um, looks at data after it's in to identify duplicates and mark them as such. And so just to show you what that actually looks like in the platform, again, for anyone that's new to Dojo or doesn't have experience that may joining us today, uh, when we look at the statuses here on the top, you'll notice that one of these.

Has been marked as inactive and duplicate. And then what that looks like from a metadata perspective and, um, with regard to the, the pro edition of Dojo, like all of these things can be changed in terms of these strategies. So we can customize, how deduplication at the same tool level works, but also cross tool.

You can also change, uh, the reimport comparisons that makes these decisions on what will be closed or what will be created or what will be left untouched. And then the next step is the enrichment process. So, what Dojo will do on, on the commercial edition is go out and pull threat until every 24 hours about all vulnerabilities.

And that populates, uh, this dashboard here, which is focused on risk. Um, we have two different views of risk. We call, uh, one priority and one is called risk. Um, for those that are looking to absolutely sort IE what is the absolute worst finding on a numerical level? That's what priority is used for. And then risk is like the executive level view of four classifications from, um, needs action to low to help me make, to help people make, uh, risk-based decisions on vulnerability data.

And so we have both kind of these dashboards that are meant to show your top assets by risk, your top components by risk, which will be SBOs, and then, um. Yeah, your top host by risk category as well. And then just looking at the individual level, you get these little colorful circles here that help define, um, the risk of individual findings.

Uh, we also let people customize this. That's an area we try to be really unique. My, my experience is if you ask 10 security leaders what metrics they want or how they want things to work, you'll typically get 12 answers. And so this is kind of a, a gross oversimplification of how this risk scoring works.

Like one of the things I don't think the custom calculator does as well is when you have a finding that is publicly reachable and on 10 endpoints versus 50, how do you make that easy to configure for the user from a calculation perspective? This does let people create their own risk scoring mechanisms.

And then at the top of the prioritization multipliers, that's us essentially, uh, giving suggestions on what should maybe be the risk thresholds based on your customizations. But, um, again, you can use our proprietary one. You can create your own, totally your choice. 

Remediation SLAs and Verification

Then, um, with regard to remediation for the CRA specifically, we recommend creating custom SLA levels that align with the regulation and assigning those as appropriate to your assets.

And then, the other thing on remediation, we, we do have a ton of AI features that are easy to work with for things like auto remediation. We also have auto remediation partners. Um, we're looking at kind of the best ways to achieve that for customers in, in a practical sense. We're, we're big fans I think of, of Claude overall today.

And so, um, we see a lot of people using the MCP to pull data down and then create suggestions for, um, how to fix things or do additional security intel. And then finally verify which, uh, reimport will handle for you. Reimport will, um, look at your scan data. And automatically determine, um, if something has been fixed.

Um, or you can also go and market as such manually, but that exists, um, in any version of Dojo that you use, open Source, pro, et cetera. 

Practical Next Steps to Comply

And then, um, finally just kind of to recap, so. What do we actually do beyond Dojo to make these programs a reality? Um, I think the first step is inventorying your products to understand how these things, uh, apply to the CRA and then establish how you are going to get these SBOs into your vulnerability management program and platform for tracking.

And then the next things are, if you're familiar with Dojo, doing all the standard Dojo things of. Bringing your vulnerability data in. The suggestion we have specifically around SLAs and workflows is defining, uh, certain SLAs that align exactly with the CRA requirements. I imagine, we'll, we'll probably create a fixture for Dojo to autopopulate that for people that want it.

And then finally, um, just monitor and reporting and making sure that you stay in compliance and look at the dashboards, et cetera, to make sure that's the case and take appropriate action. Um, the other thing we've suggested is just like, okay, from a high level, yes, this is something I have to deal with.

What should I do today versus tomorrow, et cetera. And so, um, you know, in an ideal world, it would be nice to have all these things today, but as, um. People who started on the other side of sec, the security equation before becoming a vendor. We understand that, you know, everyone is resource constrained, especially in today's times.

Um, security teams unfortunately have never been less resourced. So if you haven't started, like that's okay. This is something we're working on for ourselves as well. And full transparency, but we just try to break down, like how do you take these baby steps to, uh, get your company where it needs today?

How do you give something to leadership so that it's, uh, digestible and easy to action? And this is what the team has come up with and, and likewise we're doing for ourselves and full transparency so that we're ready when this regulation kicks in and we're doing, um, everything that's appropriate and is required.

And so we can both, you know, help customers but also. Make sure we're in compliance for ourselves. 

New PSIRT Engine Preview

And then, um, the final thing I wanted to show in this presentation is tangentially related to the CRA, but not exactly and always listening to customers and always looking at where we can improve and what we can do better.

You know, the CRA was one thing that's come up a lot recently, but the other. Piece of this conversation that is kind of hand in hand with the CR regulation is, is PSIRT management. I did PSIRT at TIBCO forever ago, and I always feel like PSIRT teams never have any tools to work with. I feel like it's an incredibly important function that.

Uh, largely ignored by the industry with very few exceptions compared to scanning, compared to GRC, et cetera. It's just kind of neglected. And so that's something that we wanted to change. And so we've created this new PCer engine where the goal is to go from threat feed to finding and decision across any threat feed.

And so, uh, the primary goal of the PSIRT engine is to take data. From any threat feed that you want and turn it into findings for action and help you to make the decision on am I actually vulnerable to some new piece or an alert or not? And so, um. This is another, like, massive innovation. I'm, I'm really excited that the team has created this and I think it solves something that's been largely ignored.

You know, we've seen a massive amount of spikes in terms of what people have to deal with from these different threat feeds. And so, um, yeah, I'm, I'm incredibly excited for this and, there, there's been a, a lot of amazing people that have worked on this, but this has primarily been led by, uh, Tracy Walker, who some of you know, um, this is really, you know, his creation.

He's the, the, the mastermind behind this feature. And so, you know, when we started, we were just talking about 14 different feeds, but now I think we're up to 40 with this. But the goal is, um, you never have to be blindsided again when a new. Security advisory comes out, are you impacted? What does it impact?

And, uh, can you bring that in automatically, et cetera. And so the first person will see this. Next week we've developed it. Is it next week? It's soon. Um, we developed this, you know, hand in hand with, uh, the customer that originally brought the use case to us. And we'll roll it out to everyone. Soon.

Soon. I, I don't wanna say an official date 'cause I know I'll get held to it, but, uh, like a couple of months at the latest is, I expect when, you know, every customer will get to see this new part of the platform and use it. And so, um. 

Q&A Closing

Yeah, I think that's the majority of my presentation. I'm happy to take any questions that you have if you want to, um, check out the platform or just, uh, collaborate with us in our new Slack community.

Whether you are an open source user or pro user, we appreciate, you know, everyone in the community and thank you very much for making the, the time today and attending. It's greatly appreciated and we're happy to answer any questions that you have.