The dangerous window in your business is not the one between a breach and the day you notice it. It is the one between a vendor publishing a fix and you applying it. That window used to be forgiving. Automation, and now language models sitting on top of it, have squeezed it hard enough that a monthly patch cadence is no longer a policy, it is an exposure.
Nobody hand-crafts a proof of concept from a terse advisory any more, and nobody hand-writes the scanner that finds every machine running the affected build. Both halves of that job got cheap at once. Here is the mechanism, why legacy systems absorb the first wave, and what patch velocity has to become.
What actually changed between disclosure and exploitation
The work of turning a public advisory into a working exploit got cheaper, not cleverer. Diffing a patch, reading the changed function and shaping a request that trips the old code path is a mechanical task. Machines are good at mechanical tasks. The queue of flaws that are known but not yet weaponised now drains far faster than it used to.
- ▸A patch is a confession. A fix published as source, or as a binary you can compare against the previous build, points at exactly which function was wrong. Attackers read the fix backwards to the bug it hides.
- ▸The advisory is a specification. Records in the NIST National Vulnerability Database carry affected versions, attack vector and required privileges. That is most of what you need to shape a first test request.
- ▸The attack classes have not changed. Injection, deserialisation, authentication bypass, path traversal, all old news. What changed is the fuse length. The CISA Known Exploited Vulnerabilities catalogue records which flaws are confirmed exploited in the wild, and it is the list to check before you argue that a patch can wait.
How automation compresses each step of the attacker workflow
The chain is discovery, fingerprinting, exploitation, then scaling. Every step used to need a skilled human with time to spare. Every step is now a script with a model in the loop, so one operator can move from reading an advisory to holding a foothold inside a single working session.
- ▸Target discovery is a database lookup. Internet-wide scan data is already collected and indexed by third parties. Nobody scans the internet to find you, they query a result set that already contains you.
- ▸Fingerprinting is pattern matching. Version strings, header order, favicon hashes, default error pages, the wording of a login form. All of it ties a host to a build with almost no interaction.
- ▸Exploit adaptation is text editing. A proof of concept written for one framework gets rewritten for another, with different parameter names and encodings, and the attacker iterates until something comes back.
- ▸The scaling step is what hurts you. The sweep is not aimed at your company. It is aimed at a fingerprint, and you match it. Being small, local or boring protects nobody, because nothing in that pipeline checks who you are.
- ▸Social engineering scales the same way. Pretexts and voice cloning are cheap at volume now, and a stolen session token walks an attacker past the patched front door entirely.
Why slow-patching legacy systems get hit first
Because they are the easiest match in the sweep. Attackers optimise for return on effort. An unsupported system offers a public, tested exploit, no vendor fix racing them to the finish, usually no monitoring to catch the first attempt, and an owner who will not notice for weeks. That is the whole calculation.
- ▸The exploit is already written. For anything a few years old the research phase is finished and refined. There is no lead time between deciding to attack you and being able to.
- ▸There is no fix to race. Once support ends, exposure only accumulates. Check the real dates rather than a supplier's assurance, on the Microsoft product lifecycle and on PHP supported versions.
- ▸They are load-bearing. The finance system, the scheduling tool, the customer portal. Fragile, exposed and essential is the combination ransomware crews price their demands against.
- ▸Nobody owns them. If the answer to "who patches that" is the name of someone who left, you already have the finding. Our WordPress security reality check shows how this plays out on the commonest small business stack.
The patch window your business actually has
Assume hours to days for anything internet-facing, not weeks. The shape is consistent: an advisory appears, mass scanning for the affected fingerprint follows quickly, and whoever is still exposed when the sweep arrives gets compromised. You do not negotiate with that sequence, you finish before it.
- ▸Edge software does not belong in the monthly maintenance window. Anything reachable from the public internet needs its own fast lane: firewalls, VPN concentrators, mail gateways, file transfer appliances, CMS platforms, admin panels.
- ▸Take the feed from the source. Subscribe to CISA Cybersecurity Advisories and route them to a named person on duty, not a shared inbox nobody reads on Fridays.
- ▸Treat confirmed exploitation as an interrupt. If a flaw in software you run is being exploited in the wild, that is not a ticket for next sprint. That is today, out of hours if necessary.
What patch velocity has to become
Patch velocity is not a number you write into a policy, it is a capability with four parts: you know what you run, you get told the day it matters, you can deploy without convening a committee, and you can prove the fix landed. Miss any one of the four and the other three will not save you.
- ▸An inventory that regenerates itself. Produced by the build, not typed into a spreadsheet, listing every component and version in production. If you cannot answer "do we run that" in minutes, your clock starts late every time.
- ▸Automated dependency and base image updates. Proposed continuously, tested automatically, merged on a schedule rather than through a heroic quarterly effort.
- ▸A deploy path measured in minutes. Rehearsed weekly on ordinary changes so it is boring by the time it is urgent. Teams that deploy rarely deploy badly under pressure.
- ▸A pre-approved emergency route. One named person authorises an out-of-band patch without a change board. Write that down before you need it.
- ▸Verification instead of assumption. Re-check the running version from outside, confirm the fingerprint changed, close the ticket on evidence. Our guide to what website maintenance should actually include sets out the difference between a supplier who patches and one who invoices.
The systems you cannot patch fast, and what to do instead
Some systems genuinely cannot move quickly: a vendor-locked appliance, a customised ERP, a CMS carrying twenty plugins and a bespoke theme. Pretending otherwise wastes a year. Those need compensating controls plus a dated exit plan, because controls buy time and nothing else.
- ▸Take it off the public internet. Put remote access behind a VPN or identity-aware proxy so an unauthenticated scanner never reaches the vulnerable code path. That one move defeats most opportunistic exploitation.
- ▸Virtual patching at the edge. A rule at the reverse proxy that blocks the specific request shape buys days while you plan the real fix. It is a tourniquet, not a treatment, and it needs an expiry date.
- ▸Segment for blast radius. The legacy box should not reach your file server, your backups or your identity provider. Assume it will be owned and design for that day.
- ▸Harden the credentials around it. Infostealers and credential stuffing bypass patching entirely, so remote access needs phishing-resistant MFA and short session lifetimes.
- ▸Put a date on the exit. A compensating control with no replacement date is a permanent decision made quietly. Our migration playbook covers making that move without losing your search rankings.
How to tell whether you actually got faster
Measure the clock, not the effort. Four timestamps describe your real posture: when the advisory was published, when you knew, when the fix was deployed everywhere, and when you verified the exposure was closed. Everything else is activity reporting dressed as security.
- ▸Time to know. From publication to a named person being aware. If this runs to weeks, no amount of deployment speed rescues you.
- ▸Time to deploy. From awareness to the last affected system updated, including the one nobody remembered.
- ▸Time to verify. Independent confirmation, checked from outside your own network.
- ▸Coverage. The share of the estate that appears in the inventory at all. Unknown systems are unpatched systems.
- ▸Run a drill. Pick a real advisory for software you run, start the clock, go end to end. The first attempt always exposes the same three things: no inventory, an unreachable owner, and a deploy path nobody has used this quarter. Our small business website security checklist is where to start.
Why this is an architecture problem, not a discipline problem
Patch speed is a property of how your systems are built, not of how much your team cares. Systems that are boring to update get updated. A pile of hand-edited files on a production server will never be fast, whatever the policy promises, because every change is a gamble nobody wants to take on a Friday.
- ▸Everything comes from a repository. No live edits on production, ever. If you cannot rebuild the server from source, you cannot patch it with confidence.
- ▸Rebuild rather than repair. Ephemeral infrastructure turns patching into redeployment, a routine you already run weekly.
- ▸Carry fewer dependencies. Every library is a future advisory with your name on it.
- ▸Automated tests are the safety rail. They let you ship a security update without a week of manual regression testing first.
How TuniCyberLabs helps
We modernise the systems slowing you down, then build the pipeline that keeps them current: a component inventory generated by your build, automated dependency updates with tests behind them, a deploy path measured in minutes, edge hardening for whatever cannot move yet, and a dated migration plan for the legacy pieces that have to go. We work across the EU and North Africa, and we hand over systems your own team can run.
Tell us what you are running and we will tell you honestly how much time you have: talk to our engineers.