From 26,000 Vulnerabilities to 300: CRA Certification for Legacy Products
What happens when you have a legacy product—already in the field, five years on the market—and now you have to certify it for CRA? Learn how layering CVSS, EPSS, threat intelligence, and reachability analysis can reduce the noise and make CRA compliance achievable—even under tight deadlines.
•3:28•HD•0 views
From 26,000 Vulnerabilities to 300: CRA Certification for Legacy Products
Transcript
We have this big awful product, and we need to get it certified. And it's it already went out the door. It's been on the market for five years, and now I have to figure out how to get my CRA certification on this product. And I've identified that there are twenty six thousand vulnerabilities inside of this product. This is a real world example.
What do I do? I don't have twenty six thousand developers. I don't have twenty six developers that can handle this. They're all busy. I need to get this thing figured out. I need to do it before the reporting deadline.
There's only one way to do it. You have to prioritize. You have to find a way to figure out which signal matters in all of that noise.
The only way to accomplish that is to apply some sort of filter.
So the traditional means is to do a score, your CV. So we'll start with the tens.
That's not perfect because unfortunately, not all tens are applicable and some fives are actually more important than your tens because they've been weaponized or they are more exploitable than your tens. So we're gonna have to apply some technology to help us reason which things actually should be prioritized within the scoring themselves.
So we'll layer on an EPSS. Right? So now we have an EPSS. This is gonna tell me a little bit more information about which things I should prioritize. Good. Now we're getting somewhere.
Once you've identified which things are exploitable, and maybe you've got a threat intel feed like we like we do in finite state, they can tell you which things are actually weaponized by threat actors in the wild. So now I've got this the smaller set of exploitable vulnerabilities that are also weaponized. So maybe I have twelve hundred vulnerabilities. It's still too many. I still can't get twelve hundred done by the by the middle of twenty twenty six.
So I gotta go one step further. And that means that I have to figure out which of these are actually applicable, which ones are contextually reachable inside of my software.
And that's where you get to the layer where you can bring it from twenty six thousand vulnerabilities to three hundred.
Three hundred vulnerabilities, I can do it. It's still hard. It's still hard. I'm gonna have to go human validate that these three hundred are not false for whatever reason. But at least I have a high level of confidence. I have a technical audit trail of a piece of technology, the Finestate Platform, that's identified for me.
This is exploitable, this is reachable, this is how we believe it's reachable. This is the software library that you should go look at and the reason why we believe it exists and where we believe it exists in your code. Hand that to your developer, see what they can do, send the product back through the platform, see if we get down to two ninety nine. You do that across the board a few times. And I'm not saying this is easy. I'm just saying I've taken your priority list from twenty six thousand to three hundred and we can work together to get that down to zero.