Patching as a process, not a panic

Every few months a serious vulnerability makes the news, and teams scramble to find out whether they are exposed. The scramble is the symptom. The real issue is that most organisations only think about patching when something forces them to, and by then they cannot answer the basic question: what are we actually running, and where? This article is about replacing that recurring panic with a quiet, owned process that keeps you ahead of the news instead of chasing it.

The problem

Outdated components — old libraries, unpatched operating systems, end-of-life runtimes — are the single most common finding in penetration tests and security audits. They are also the most common way real breaches begin, because a known vulnerability comes with a known, published method to exploit it. An attacker does not need to discover anything; they just need to find someone who has not patched yet.

The painful part is that patching is rarely blocked by difficulty. It is blocked by visibility. When the next big vulnerability lands, teams lose days simply trying to establish whether they use the affected component, in which services, and in which versions. That uncertainty is the vulnerability behind the vulnerability.

Why it happens

Patching slips for structural reasons, not because engineers do not care:

• Nobody owns it. Feature work has a product owner and a deadline. Patching has neither, so it loses every prioritisation contest until an incident forces it to the top.
• No inventory. Without a list of what runs where, patching is guesswork, and guesswork feels risky, so it gets postponed.
• Fear of breakage. Updating a dependency can break the build, so teams avoid it until they must, which means updates arrive in large, scary batches instead of small, boring ones.
• Two separate problems treated as one. Application dependencies and operating-system packages need different tooling and different owners, and teams that lump them together do neither well.

Start with an inventory you can trust

You cannot patch what you cannot see. The foundation of calm patching is a software bill of materials (SBOM): a generated, always-current list of every component and version in each service. Modern tooling produces this automatically from your build, so it stays accurate without manual effort.

Once you have the inventory, split the work cleanly into two tracks, because they are genuinely different:

Track	What it covers	Tooling that fits
Application dependencies	Libraries your code pulls in (npm, pip, Maven, Go modules)	Dependabot, Renovate, Snyk
Operating system & images	OS packages, base container images, AMIs	Managed patching, image rebuilds, scanners like Trivy

Make small updates automatic, big ones scheduled

The trick to avoiding scary batches is to make routine updates flow continuously. Tools like Dependabot or Renovate open pull requests as new versions are released; when your automated tests pass, a patch or minor update can merge with little ceremony. Because the changes are small and frequent, breakage is rare and easy to trace.

# .github/dependabot.yml — a steady drip of small, testable updates
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

Reserve human scheduling for the updates that genuinely need it: major version bumps, runtime upgrades, and anything with breaking changes. Those get a planned slot rather than an emergency.

For operating systems and base images, prefer rebuilding over patching in place. Rebuilding an image from an updated base and redeploying gives you a clean, repeatable result, and it fits how cloud infrastructure is meant to work: servers are replaced, not nursed.

Give it an owner and a cadence

The process only works if someone owns it and it runs on a rhythm. That does not mean a large team. It means a named owner, a regular review of what is outstanding, and a service-level target for how fast a critical patch must ship once it is available — for example, critical within days, high within a couple of weeks. Track it like any other work so it is visible, not invisible. In India, note that CERT-In directions expect organisations to act on and report certain security incidents within tight timelines, so a slow, ad-hoc patch process is also a compliance risk.

What to do this week

• Generate an SBOM for your most important service so you finally have an accurate list of what it runs.
• Turn on automated dependency pull requests (Dependabot or Renovate) for that service and let small updates start flowing.
• Split patching into two tracks — application dependencies and OS/images — and name an owner for each.
• Agree a simple target: how fast must a critical patch ship once it exists? Write it down.
• Identify any end-of-life runtime or operating system in production and put its replacement on the roadmap now, before it becomes an emergency.

When to bring in a partner

If keeping systems patched competes with shipping features and keeps losing, it is a strong candidate to hand to a managed team. Running inventory, automated patching, image rebuilds and OS updates as a background service is central to our managed cloud service, and it is one of the fastest ways to remove the finding that appears in almost every audit. A partner absorbs the ongoing toil so your engineers stay on the product, while your exposure to known vulnerabilities steadily drops.