In a recent thread on a discussion forum, a group of developers discussed time lost on bug chasing. One developer lamented that he lost 5 days; another 5 years between the time it was discovered and the time it was finally resolved. Still another developer estimated that in an organization of 400 engineers, he and his team spent 300 hours per bug, based on an historical average over the past 3 years.
As someone who has been involved in these issues for longer than I care to admit, the tone and content of this thread was distressing. Modern risk frameworks and advanced metrics on time and loss opportunities have been around for decades, but you would never know it from watching these developers and senior IT managers go back and forth.
The core of the problem is culture. Development organizations claim sophistication without actually owning it. More and more are what counts—more time spent debugging and more bugs squashed, instead of the more effective less.
Those of you who have wondered why the heck you are spending days, weeks, months chasing vulnerabilities: I am talking to you. Not only are you wasting time, but you are also ignoring the fact that when it comes to bugs, most often only a small fraction of them is worth serious attention.
Turn More into Less
The approach I am suggesting breaks down to a three-step process. First, we have the scan of your development assets. This scan is the most basic risk assessment activity. Whether you are using an off-the-shelf product, a cloud-based tool, or a homebrewed solution, the scan reveals a list of vulnerabilities. The list is often shockingly long, creating the FUD reaction that sends teams off on a bug-chasing mission that costs time, money and, most of all, a loss of focus.
None of us want to be the next organization that blew it. We don’t want to see the hard work we’ve done turn into the next incursion that results in colossal loss. At the same time, we don’t want to keep doing the same things over and over again and expecting different results. We want to avail ourselves of the latest tools and methods that assure our team and the customers we serve are protected against this new generation of ever-more-sophisticated bad actors.
The good news is there is a new generation of applications like Qwiet AI that takes you beyond reachability. The key is not stopping at that ominous list of weaknesses that only hypothetically could turn into elevated systemic privileges and other nastiness down the road.
For instance, with a recent customer scan we uncovered 108 vulnerabilities. But when we cross-referenced them with our database of active threats, we reduced the list from 108 to six. That’s 95 percent gone. And it shows that context matters. Who is doing something, when it is being done, how often. All these factors represent context, which is the second step in our process.
Third, and most critical, is exploitability. Exploitability is focusing on the six vulnerabilities we have left. By drilling down on each of the items and doing further prioritization, we find that of the six vulnerabilities, only one has known exploits, based on the Exploit Prediction Scoring System (EPSS) score of 0.69. For those of you who are unfamiliar with EPSS, a score of 0.69 represents a real threat, and for additional context, we learn that there is active ransomware that uses this exploit.
The even better news is that this process, which took less than five minutes, is only the beginning. New tools like Qwiet AI are moving things forward even further, by augmenting contextual information about known exploits by incorporating AI so threat detection and resolution become an everyday task, revealing zero-day and pre-zero-day vulnerabilities in code, which your team can address head-on, rather than after it’s too late.
Reachability, exploitability—they can seem like the same thing, while being miles apart. Does your team know the difference, or are they just good at pretending? Either way, it’s time for you to stop wasting time.
