Patching on a schedule beats patching after an incident
Most compromised sites are not targeted. They are found by automated scanning that looks for a known vulnerability in a widely used component, and the vulnerability is usually one that was patched months earlier. The gap between a fix being published and being applied is the entire attack surface for that class of incident. Sites patched monthly on a schedule sit outside that window most of the time, and sites patched when somebody remembers do not.
The practical difficulty is that updates occasionally break things, which is why they get deferred. So updates go to staging first, the critical paths are checked, and only then are they applied to production with a rollback point in place. Security releases move faster than feature releases. Dependency inventories are kept so that the question of whether you are affected by a published vulnerability has an answer within minutes rather than a day of investigation.
Abandoned components are the other half of the problem. Plugins get orphaned, libraries stop being maintained, and a language or runtime version reaches end of life while the site continues to work. None of these produces a visible symptom. We track the support status of what your site depends on, including the runtime itself, and raise a replacement plan before the position becomes urgent, because migrating off an unmaintained component is far easier when it is not also an incident.
- Core, plugin and dependency updates applied on a schedule, with security releases expedited
- Updates tested on staging against the critical paths before they reach production
- A dependency inventory, so exposure to a published vulnerability can be answered quickly
- Support status tracked for plugins, libraries and the runtime version itself
- Replacement planned for abandoned components before the position becomes urgent