What's your answer to the patch tsunami?
We want to ask you something, and we mean it as a question, not a set-up for a pitch. The volume of vulnerabilities you are expected to assess and patch is rising, and the time you have to do it is shrinking. Both trends are being pushed by the same thing. So what are you actually doing about it?
The pressure is not imagined. AI has lowered the cost of two jobs that used to take skilled people real time: finding bugs in code, and turning a disclosed bug into a working exploit. In the 105 days from 1 April to 14 July 2026, our own tooling logged 94,513 new CVEs, roughly 900 a day. The trap is not the 900. Of those, only 173 were on CISA's confirmed-exploited list, and only around 1.1% had any public exploit code on record. The daily job is finding the handful that matter in a firehose of the ones that do not, without missing one and without burning the team out on the rest. We covered the numbers behind the shift in patching by severity is over. This is the other half: not what changed, but what we changed in response.
What we do
None of this is a finished system. It is the current state of a working setup, and we would genuinely like to compare notes.
Do not let the news be your radar. Plenty of good teams hear about vulnerabilities the way we all do, from The Register, Hacker News, or something crossing their LinkedIn feed. But the news only covers the dramatic fraction, and only once it is already news. The vendor bulletins lag too, often trailing the changelogs and the CVE feeds by days. The npm package or the PyPI library your own stack quietly depends on rarely gets an article at all, however badly it affects you. So we pull every relevant CVE from the feeds themselves, the National Vulnerability Database, the ecosystem advisories, GitHub's advisories, and CISA's exploited list, into one view, each entry summarised in plain English and scored for severity and exploit probability. We built StackFlag to do it, so the boring 99% that never makes the news still gets seen and sorted. Disclosure: StackFlag is our own tool, so treat that as an interested recommendation, not an independent one.
Watch the changelogs, not just the CVE feeds. A lot of security-relevant change never gets a CVE number: a quietly hardened default, a fixed auth bug described as a "stability improvement", a deprecated setting. We run changedetection.io self-hosted to monitor the changelogs and release notes of the software we depend on, so the CVE-adjacent risks surface too.
Democratise triage with an AI helper. This is the one we would most like other teams' views on. Anyone can raise a concern, and we do not want to discourage that, but a non-security colleague often cannot tell whether what they have spotted is urgent or noise. So we give them an AI helper that explains the vulnerability in plain terms and helps them assign a first-pass urgency. It does not replace the security review. It means more useful things get raised, better described, by more people.
Make triage visible: seen, evaluated, closed. The hidden cost in a busy team is duplicated effort: three people quietly assessing the same CVE because none can see the others already started. So every item carries a visible state, seen, evaluated, or closed, with who and why. Just as important, each one gets a plain-English summary up front, so a colleague can tell in a sentence whether it touches anything they own and discard it if it does not, rather than reading the whole advisory to find out. One assessment, recorded once, visible to everyone. It sounds mundane. It has saved us more hours than anything else on this list.
Keep the version and configuration inventory current. Most of the delay in responding to a vulnerability is not the patch. It is working out whether you are even affected: which version you run, on which systems, with which settings. Better inventories turn that from an afternoon of asking around into a query.
Patch on risk, not on reflex. Everything we already did still applies. Accelerated patching for the small set of things attackers are actually using, natural patching cadence for the rest, sorted by exposure rather than by the headline severity score.
And the layers behind all of that. Detection backstops for the case where something is exploited before we have patched it, and widening our coverage of the supply chain and the dependencies we pull in, because a growing share of the risk is in code we did not write. None of this replaces patching. It is the assumption that patching will sometimes be too slow, and the plan for when it is.
And then the honest last item: this is constantly evolving. What works this quarter will need revisiting next quarter, because the thing pushing the volume up is not slowing down. We expect to change this list, and we would rather change it in public.
Now your turn
That is our answer. We are more interested in yours. Some of you do this full-time and could teach us plenty, and we would genuinely like to hear it. We are just as interested in the smaller teams keeping the lights on without a dedicated security hire, fitting this around everything else. Either way: what actually works for you, and what have you tried that did not? Where does our list look naive, and what have we missed?
Come and tell us. We are on LinkedIn and Bluesky, and we read the replies. And if you would rather work through this for your own estate than post about it, get in touch.
← All filings