Earlier this year, Hadrian released its third annual offensive security benchmark report and the findings were striking enough to warrant a dedicated conversation. In this recap of our webinar From Noise to Action, Head of Product Marketing Alex Wells sits down with Greg Olmstead from Nubelo Engineering to unpack what the data actually means for security teams on the ground.
From the prioritisation paralysis caused by scanner overload, to the uncomfortable gap between how fast organisations think they remediate and how fast they actually do, Alex and Greg cover the issues that keep security leaders up at night and what it takes to move from reactive noise to deliberate action.
Watch the full webinar here.
The prioritization problem
Alex Wells: Let's start with what might be one of the most uncomfortable findings in the report. We looked at the scanner output across over 300 organizations and we found that only 0.47% of results turned out to actually be exploitable. So that's less than half a percent. And yet 95% of security leaders told us they're struggling to prioritize risk effectively.
Greg Olmstead: Prioritization is difficult when dealing with a deluge of poorly contextualized issues. Security personnel may face hundreds of thousands of issues with rankings that are not contextualized for their specific company or verified. Scanners have detected a vulnerable kernel or package on the system, but on investigation, less than half a percent of those are actually exploitable. "Exploitable" involves many factors beyond just being exposed to the internet. Without knowing what to prioritize, security becomes a giant punch list of spreadsheets and chasing tickets, which is ineffective.
Alex Wells: What are some strategies for adding context to those signals?
Greg Olmstead: It is easier to inspect virtual environments like the cloud than physical environments. To understand exploitability, organizations must ask whether libraries are loaded into memory, whether they are part of the active kernel, and whether they are truly exposed to the internet without protection in front of them. Building the layer cake of verifying exploitability is something that organizations are doing when they get serious about reducing their task queue. But it takes a lot of engineering effort and a lot of maintenance to keep that running and keep it from creating false positives, but even worse, false negatives. Better tools help, but currently no one has perfectly solved the problem as it requires changing how security policy is run.
Alex Wells: Is moving to modern vulnerability scanners the key to solving the prioritization problem?
Greg Olmstead: Tooling is of course one part of the solution, but it is treating a symptom rather than a cause. Changing the way that we think about exposure and vulnerabilities in 2026 is really key. Distributed systems have become so large that vulnerabilities will always appear. Simply reducing the number of vulnerabilities from 100,000 to 90,000 does not measurably increase security. Programs must shift their focus to risk reduction and exposure validation.
Alex Wells: What happens when organizations focus on exploitability over severity scores like CVSS?
Greg Olmstead: CVSS scores still matter but must be viewed through the lens of which problems actually require action given limited resources. If security remediation is seen as an expense, leaders want proof that it reduces real risk. Identifying ten items out of 100,000 that are exposed and on an attack path to crown jewels resonates with executives far more than reporting thousands of 10/10 CVSS scores.
The remediation gap
Alex Wells: 94% of teams believe that they can remediate a zero-day within 5 days. But from scanning that we have done, we have seen that the actual average for exposed exploitable vulnerabilities is closer to 38 days. That is about a 3x gap between the perceived responsiveness and the reality.
Greg Olmstead: The gap exists due to a theory versus reality disconnect, and a widening understanding gap between practitioners and leadership as seniority increases. Remediating within 5 days is difficult because security teams must deal with the software maintainers' processes, which may not align with security deadlines. For most businesses, security operations are a bolt-on rather than a core ethos, and the reality of tickets being extended and chased for weeks is exactly what that 38-day figure reflects.
Alex Wells: Where does the remediation process get stuck the most?
Greg Olmstead: A lot of these remediations don't exist in a vacuum. The service touches 18 other services, and there are five software platforms that interact with that service. Remediation may fix one product but break another. In modern microservice architectures, change management involves many interconnected teams, making point-focused security remediation difficult to reconcile with standard workflows.
Alex Wells: How can a leader actually reduce that gap?
Greg Olmstead: There needs to be a concerted effort that involves engineering leadership, product leadership, and business leadership. If you reach out to the engineering folks and you say, "Here's a spreadsheet of all the remediations I need you to do," then this gap is going to continue to grow. Success comes when security is baked into the product development workflow.
Assessment tools and quality of data
Alex Wells: 93% of organizations are running vulnerability scanners. 87% are conducting manual penetration testing, with two-thirds doing so on a quarterly basis at most. And yet despite these common tools, organizations are not seeing reduced risk.
Greg Olmstead: We are still using tools from 30 years ago for 2026 security problems. Security architects are overwhelmed by a deluge of options from new vendors daily. Enterprises don't want another pane of glass. These folks already have enough on their plate. Procurement and training can take a year, by which time the industry has shifted again.
Alex Wells: There is a phrase I keep coming back to: "visibility is the new vulnerability." Too much data distracts from what actually matters.
Greg Olmstead: There is a challenge of both non-actionability and overactionability, where thousands of findings are sent to teams on ephemeral VMs that will disappear in an hour. The data is technically actionable but not valuable. And some tool providers use high numbers of findings as a selling point, which makes the problem worse.
Alex Wells: How do you make the cultural shift to set some data aside and focus on higher priorities?
Greg Olmstead: Language matters. Instead of "stop looking," use "deprioritize" or "re-evaluate." Consider the contrast: a 10/10 CVSS vulnerability on an isolated, ephemeral machine with no proprietary data versus a 7/10 box connected to the internet with a path to a customer database. Traditional tooling always puts the 10/10 higher, but the 7/10 is the real risk. I could literally show you how to exploit this today and how to cause a real problem for your organization today.
Measuring success and security champions
Alex Wells: Let's talk about CTEM, Continuous Threat Exposure Management. We are seeing some leaders measure success by asset discovery rather than reduction in exploitable exposure. How do you approach measurement?
Greg Olmstead: One of the most effective things I have done is use security champions, volunteers in engineering teams who act as liaisons to the security apparatus. It was a huge force multiplier. But it only worked after we got our measurement right, giving champions a clear picture of what to focus on rather than a 10,000-item deluge. And the incentives were not always monetary. Many were ambitious people looking to stand out or learn an invaluable domain for their careers.
The impact of AI
Alex Wells: 97% of engineers, according to GitHub reporting, say they are using AI coding tools at work. There is more AI code going into production than ever before, and threat actors are using AI too. Tools like CyberStrike AI were used in live campaigns within eight weeks of release.
Greg Olmstead: The more that AI does for us, the less that we are checking the things that it does for us. Coders will tell you they are checking less of the code that comes out of their chosen AI coding tool. AI is the democratization of security threats, similar to ransomware as a service. Now a script kiddie has access to tools that put them above seasoned malware authors. Organizations must understand how AI is used internally across coding, operations, and sales reports. Risk will increase exponentially for those that don't set guardrails and back them with enforcement.
Alex Wells: What about Model Context Protocol services, MCP, as a new type of exposure?
Greg Olmstead: MCP is a double-edged sword. It can provide a security boundary around internal APIs, but if built insecurely, it can cause information leakage. Humans are reactive and often don't think about classes of problems like indirect prompt injection until it is right in front of them. We need to maybe slow down the shoving of AI into every corner of our product until we understand the risk that we are creating by doing so.
Making risk real for the business
Alex Wells: On Hadrian's data quality: we use a "hacker in the loop" approach with a team of bug bounty hunters who act as a vetting and triage center to filter noise, targeting zero false positives. How do you create urgency for non-zero-day exposures?
Greg Olmstead: Framing it as "this is how many dollars we are putting at risk" or "this could lead to irreparable reputational harm" tends to resonate. Security is everybody's job. We are all in the security boat together. Organizational culture must help move everyone to the same side of the table rather than having security and engineering at odds.
Closing remarks
In this webinar, Alex and Greg unpacked some of the most pressing challenges facing security teams today, from the weight of an unmanageable backlog to the gap between how fast organisations think they remediate and how fast they actually do. Along the way, they shared some of the latest offensive security insights from Hadrian's annual offensive security benchmark report, including the striking finding that only 0.47% of scanner results are actually exploitable, and the 38-day average remediation time that far outpaces what most teams believe. The conversation made one thing clear: most programs are operating without a full picture of where they stand, and that gap tends to be wider than anyone expects. If you are curious where your organisation stands, take our security maturity model assessment and find out.
