Every so often a client forwards us a news article about a security vulnerability and asks whether their site is affected. It is one of our favorite messages to answer, because the answer is almost always the same: yes, we saw it, and the patch was applied before the article was written. Then everyone goes back to their day.
That short exchange says a lot about how we think security maintenance should feel from the client side. Not alarming, not dramatic, not an invoice with the word urgent on it. Just a routine that was already running before you thought to ask about it.
This article explains what that routine actually consists of. Not to impress anyone with process, but because we think clients sleep better when they understand what is happening on their behalf, and because patching is one of those services that works best when it is visible in explanation and invisible in practice.
Two streams, one habit
Security updates reach a website from two directions, and it helps to keep them apart.
The first stream is the application itself: Drupal core and the contributed modules a site uses. The Drupal security team publishes advisories on a predictable weekly rhythm, and module maintainers release fixes alongside them. This is one of the quiet strengths of Drupal as a platform. Security work is coordinated, published in the open, and announced in advance, which means an attentive team can build a calm routine around it instead of reacting to surprises.
The second stream sits underneath the application: the operating system packages, the PHP runtime, the web server, all the software your site stands on. Vulnerabilities appear there too, on their own schedule, and they matter just as much even though they never mention Drupal by name.
Both streams are our job. A site is only as current as the least maintained layer beneath it, so treating one stream carefully while ignoring the other would be tidying half a room.
The application side: updates as a rhythm
For Drupal core and modules, our routine is built around the advisory calendar. When security releases are published, we review what applies to each site we look after, apply the updates, and run each site through its checks before the change goes live. Because our deployments are tracked releases with a clear way back, a security update travels the same safe path as any other change: it is applied, verified, and recorded, and the deployment history shows exactly when it landed.
Verification deserves its own sentence, because applying an update is the easy half. Sites differ, and a fix that is trivial on one site can interact with a customization on another. Our releases give us room to check each site properly before the update goes live, and staging environments let anything unusual be exercised away from production first. The update that reaches your visitors has already run somewhere that looks exactly like your site, because it effectively is your site, one step earlier.
The point of the rhythm is that nothing about it is improvised. We are not deciding, in the moment, whether this advisory is worth the effort. Every applicable advisory gets handled, every time, as part of the ordinary flow of maintenance. Judgment goes into how a specific update is verified for a specific site, not into whether patching happens at all.
The platform side: rebuilt at the base, rolled out everywhere
For the layers underneath the application, we run our own hosting platform, and every site on it runs inside hardened containers built from base images we maintain centrally. When a vulnerability appears in the runtime or the system packages, we do not visit servers one by one. We rebuild the base images once, with the fixes in place, and roll the refreshed images out across every hosted site as a routine operation.
This is the part of the service clients rarely think about, and it is where central maintenance earns its keep. One rebuild covers the whole fleet. Every site benefits from the same fix at the same standard, including the sites whose owners never read security news at all. There is no such thing as the forgotten server that quietly fell behind, because no server is patched as an individual favor. The platform moves together.
What you experience: nothing, on purpose
From the client side, all of this compresses into a simple experience. Patches arrive as part of normal service. There is no emergency phone call, no separate line item for panic work, no window where you are asked to decide whether a security fix fits this month. The cost and the effort are already inside the maintenance relationship, spread evenly, the way insurance should be.
We think this is the honest way to price security work, because urgency is mostly a symptom of postponement. A patch applied on the week it is published is a small, calm task. The same patch deferred for a long time grows into a project, because updates stack on top of each other and each layer of delay adds testing surface. By keeping every site current as a habit, we keep every individual update small, and small updates do not need to be emergencies.
Why we refuse to sell fear
Security is an easy topic to dramatize, and we deliberately do not. You will not hear us describe the internet as a war zone or use a scary headline to hurry a decision. Not because the risks are imaginary, but because fear is a poor foundation for a long relationship, and because the truthful version of this story is genuinely reassuring: software has vulnerabilities, researchers find them, maintainers fix them, and maintenance teams apply the fixes. That cycle has been turning for decades. The only question that matters for your site is whether someone is reliably doing the last step.
When that someone exists, security news changes character. An advisory stops being a threat and becomes a work item. A headline stops being a reason to worry and becomes a reason to check the deployment history, where the answer is usually already sitting.
This is just what maintenance looks like
None of what we have described is heroic, and that is the point. Patching is not a special event in a well-run maintenance practice. It is the practice. The same weekly attention, the same central rebuilds, the same quiet rollouts, repeating whether or not anything newsworthy happened, so that on the weeks when something newsworthy does happen, nothing about our behavior needs to change.
If you own a site and you are not sure who is doing this work for it, that is worth a conversation, and it does not have to be with us. Ask whoever looks after your site how updates reach it, on what rhythm, and how they would know a layer had fallen behind. Good answers exist, and you deserve to hear one. And if you would like to talk through how we would look after yours, we are easy to reach, and the first conversation costs nothing.