Security patching cadence for production applications

A security patching schedule for a production application has three speeds. Critical vulnerabilities that are being exploited get patched within days, sometimes hours. Routine dependency updates are applied in a monthly batch. Framework, runtime and major-version upgrades are planned quarterly because they need testing time. Underneath all three sits automated scanning in the CI pipeline, so that a new vulnerability in a package you already use is flagged the day it is published rather than the day someone exploits it. This article sets out that cadence, the tooling that makes it cheap, and how a small or mid-size company runs it without a security team.

Why cadence beats heroics

Most companies patch in one of two modes: never, until a customer or auditor asks; or in a panic, when a widely reported vulnerability makes the news. Both are expensive. The first accumulates a backlog so large that upgrading anything breaks everything. The second consumes the team for days at a time. A fixed cadence keeps the backlog small, so each update is a minor change with a small blast radius, and the critical path is a practised routine rather than an emergency. Vulnerability management for an SMB is mostly the discipline of doing a little, regularly.

Critical vulnerabilities: within days

A critical vulnerability is one that is being exploited in the wild, or is trivially exploitable in a component your application exposes. The trigger is a vendor advisory or a listing in a source such as CISA's Known Exploited Vulnerabilities catalogue. The response is a practised routine: confirm the component is in use and reachable, apply the patch on a branch, run the smoke tests, deploy to staging, deploy to production with rollback ready, and record what was done. If the patch cannot be applied quickly, mitigate: a firewall rule, a feature flag, disabling the affected endpoint. Mitigation first, fix second, is the same principle as in an SLA.

Dependency updates: monthly

Application dependencies, the packages in your manifest files, are where most vulnerabilities arrive, and where the monthly batch does its work. A dependency bot opens pull requests as new versions appear; once a month an engineer merges the batch, runs the full test suite, lets it soak on staging for a day and deploys. Grouping updates into one batch keeps the change reviewable and the deployment a single event. The rule that makes this sustainable is that a failing update is not skipped but investigated; a package that cannot be updated because of a breaking change goes on the quarterly list with a plan.

Lockfiles, pinning and reproducibility

Monthly batches only work if builds are reproducible. Lockfiles are committed, versions are pinned, container images are built from a pinned base and the build is run in CI, not on a laptop. A build that pulls whatever is newest today is unpatchable in any controlled sense, because you do not know what is running, and you cannot prove to an auditor what was running last month.

Frameworks, runtimes and end-of-life dates

A web framework several major versions behind, a language runtime past end of life, a database engine no longer receiving security fixes: these are the upgrades that teams defer for years because they are large. The cadence answer is to schedule a quarterly slot, keep a list of every component with its end-of-life date, and always be within one major version of current. Upgrading one major version at a time, every quarter, is routine. Upgrading four at once, after an auditor's deadline, is a project. Where a system is already far behind, the first step is a takeover audit to establish what is running and what is exposed.

Scanning in CI so nothing waits for an incident

Scanning is the mechanism that turns patching from a memory exercise into a pipeline step. Three scanners cover most applications: a dependency scanner that checks manifests and lockfiles against vulnerability databases; a container image scanner that checks the OS packages in the base image; and a static analysis pass for obvious code-level issues such as injection and hard-coded secrets. All three run on every pull request and on a nightly schedule against the main branch, because new vulnerabilities are published for old code. Findings above a severity threshold fail the build; findings below it are reported. Secrets scanning is run separately and blocks the commit.

Patch management software: what small teams actually need

There is a market for patch management platforms, and most of it is built for fleets of workstations rather than a handful of web applications. For a typical SMB application stack, the dependency bot built into your repository host, the scanners in your CI provider or a free open-source equivalent, and a monthly calendar reminder are enough. Spend money on a secrets manager and on staging that resembles production before spending it on a patching platform. The one tool worth adding early is an inventory: a single list of every application, its runtime, its framework versions and its owner, which makes the quarterly review a ten-minute job.

For AI components: models and vendor SDKs

LLM applications add a few items to the cadence. Vendor SDKs update frequently and sometimes change behaviour; they go in the monthly batch with the evaluation suite run alongside the tests. Model versions are pinned and upgraded deliberately, against the golden set, not by accepting the vendor's default. Self-hosted inference servers and GPU drivers have their own advisories and belong on the quarterly list. And prompt injection is a class of vulnerability that no scanner catches; it is managed through policy-gated actions and evals, as described in how to build an AI agent that is safe to run unattended.

A worked example

A field-service SaaS company with an in-app copilot had a codebase where the last dependency update predated the copilot itself. The framework was two majors behind, the container base image had not been rebuilt in over a year, and a vulnerability scan on the first day produced a list long enough to be discouraging. We did not try to clear it at once. Critical findings in exposed components were patched or mitigated in the first week. A dependency bot and CI scanning were switched on so the list stopped growing. The monthly batch began the following month, and the first framework major upgrade took the first quarterly slot. Within a few cycles the backlog was small enough that each batch was an hour's work, and the engineering lead could answer a customer's security questionnaire from the monthly report rather than from memory. The product is described in in-app copilot for a B2B SaaS.

Team and timeline

Setting up the cadence takes one engineer one to two weeks: inventory, scanners in CI, dependency bot, staging soak and the first critical fixes. Running it takes a few hours a month plus the quarterly upgrade slot, which is why it fits inside a Care Plan; Essential's ten hours a month cover the routine for a small system, and Standard or Enterprise cover larger estates and out-of-hours critical response. Pricing is on the pricing page. Applications too far behind to patch incrementally are candidates for legacy-to-AI modernisation, where the upgrade is planned rather than forced. The contract terms that make the cadence a commitment are in what should be in an AMC.

Before you start: a checklist

• An inventory of every application with runtime, framework versions and owner
• Reproducible builds: lockfiles committed, versions pinned, CI builds only
• Dependency, container and static scanners running on every pull request and nightly
• A dependency bot opening update pull requests
• A staging environment that resembles production for the monthly soak
• A tested rollback for every deployment
• A monthly calendar slot and a quarterly upgrade slot, owned by a named engineer
• A monthly report listing patches applied and findings outstanding

Glossary

• CVE: a public identifier for a known vulnerability
• Actively exploited: a vulnerability confirmed to be used in real attacks
• Lockfile: a file recording the exact dependency versions a build uses
• Base image: the container image your application image is built on
• Soak: running a change on staging for a period to catch problems before production
• End of life (EOL): the date after which a component receives no security fixes

Related reading

SLAs that mean something, Zero data egress: designing AI that never leaves your VPC and the security page cover the wider security posture.

Patch a little, every month, with scanners watching; the alternative is patching a lot, all at once, after something has gone wrong.