CRA Flips the Script on Vulnerability Management
Vulnerability disclosure is nothing new—but CRA introduces a new twist: retroactive reporting. In this clip, Dario Lobozzo, GM of EMEA at Finite State, explains how regulations like the Cyber Resilience Act force organizations to track and report vulnerabilities after products are in the field. That means recalling issues from older versions, fixing them, disclosing them, and proving they’re no longer reachable—all as if it happened today.
•2:37•HD•0 views
CRA Flips the Script on Vulnerability Management
Transcript
Vulnerabilities aren't new. This is something that has existed in software development for quite some time. So there are some best practices that people can think about when it comes to validating vulnerabilities across your software supply chain.
The new challenge though is that regulations like CRA really do a number on flipping the timeline. It used to be that you would develop something, you would develop it the most secure that you believe you could. And then afterward, if you identify that there's a vulnerability in it, then you'll make a vulnerability disclosure. Cra is asking you to remember that there was a vulnerability in something after you've already released it into the wild. So you need to retroactively recall the vulnerabilities that exist, then report on them, then fix them, then tell the world how you fix them as if it all happened today.
So this backlog of vulnerability best practices is causing this It's actually causing a staffing shortage in the industry right now of people who can actually go and figure out this problem and do it in a way that's scalable and approachable. I do believe this is where technology can help quite a lot in helping you prioritize where you should remediate, help you add assurance to actually ensure that once you've remediated something, it stays remediated. And then back to the continuous vulnerability disclosure, being able to say the following versions have the following vulnerabilities. We recommend that you move to this version because these do not contain these vulnerabilities. They've been resolved.
These other vulnerabilities also exist, but we've identified that they are not reachable. So we didn't fix them. They are going to persist until our next architecture review, which is scheduled at XYZ timeframe.
Being able to have this kind of cohesive vulnerability picture that's both retroactive and future cast, that's a new problem. That's a new thing that CRA is kind of laying on organizations to try to figure out as opposed to the good old fashioned vulnerability best practice of, you know, monitor, report, etcetera. Now we need to not only monitor, but we need to investigate retroactively.