A cybersecurity vendor that misses a vulnerability can face a very direct question after an incident: Why didn’t you warn us? Few vendors are asked the harder one. You warned us about thousands of critical vulnerabilities. Why were the ones that mattered still open?The industry has spent a decade arguing about prioritization, about which findings deserve attention first. That argument matters, but it stops one step short. A prioritized list is still a list of open vulnerabilities. The work that actually reduces exposure starts after the list, when someone in IT has to change a production system. Most security products have very little to say about that part.Their default answer is to patch. Patching is the right long-term fix, and also the slowest one available. A patch has to be tested against every application that depends on the system. It needs a change window, and sometimes a reboot the business won’t schedule for weeks. Some legacy systems have no patch at all. Meanwhile the time between disclosure and exploitation keeps shrinking, and frontier AI models are shrinking it further. A security program that can only close exposures as fast as the patch cycle allows will keep falling behind.I spent years on Israel’s National Red Team looking at networks from the attacker’s side. From there, a vulnerability is never a single point. An exploit is a chain of conditions. The vulnerable service has to be running. It has to be reachable from somewhere the attacker can get to. It may need specific credentials, a particular configuration or a feature that someone switched on. Every one of those conditions is a place to break the chain. The patch removes one link, often the hardest one to remove, and rarely the only one.Many of the vulnerabilities we exploited stayed open because everyone was waiting for the patch. The patch was scheduled, delayed or blocked by a dependency. The conditions around it could have been changed in an afternoon: a firewall rule that allowed too much, a management interface exposed to the wrong segment, a service nobody used. Nobody had connected the vulnerability to those conditions, so nobody changed them.This is where “we warned you” falls short. A warning names the vulnerability, attaches a severity score and tells IT the matter is urgent. It leaves them to work out what to do. When the only option on the table is an emergency patch, IT pushes back for good reasons: the chance of breaking production, the cost of downtime, the queue of other urgent requests. Security escalates, and the vulnerability stays open while the teams negotiate.A useful recommendation looks different. Take a server with a critical remote code execution flaw in a service exposed to the user network. A warning says to patch the server. A mitigation-focused recommendation shows that the service is reachable from two segments through one specific rule. Restricting that rule closes the path today, and the patch can follow in the next maintenance window. IT gets a change it can make without downtime. Security gets the exposure closed this week rather than next month.The same logic works in reverse. If the vulnerable service sits behind a firewall rule that blocks every path to it, there is no case for an emergency patch. That rule is already doing the work of a fix and should be tracked as one. If someone changes it, the vulnerability needs a fresh assessment.The volume problem will only grow. Discovery is accelerating for defenders and attackers alike, and no team can patch every new vulnerability as it appears. Fortunately, they don’t need to. Typically only about 1% of vulnerabilities are reachable in a given environment, and those are the ones that need closing now. For each of them, the question is which condition to remove. Very often the fastest answer is a configuration change, a segmentation adjustment or a service turned off, with the patch following on the normal schedule.In any product evaluation, security teams can test whether a tool helps them fix vulnerabilities or only find them. Pick a critical finding and ask the vendor to show the attack path, the change that closes it and proof that the change worked. A severity score is a claim. Evidence is something IT can verify before touching production.”We warned you” leaves the vulnerability where it was. The vendor’s job is to help close it.Roy Rajwan is co-founder and CPO of Astelia.
——————————————————-
Click Here For The Original Source.
