A Field Guide to Patching at Scale

Patching at scale is the unglamorous work of security. The defender who has the patching process right has solved 80 percent of the vulnerability problem. The defender who has it wrong has not. Here is what the process looks like…

A long row of identical small black network appliances on a steel shelf, each with a colored dot sticker: most green, a few red.

Patching at scale is the unglamorous work of security. The defender who has the patching process right has solved 80 percent of the vulnerability problem. The defender who has it wrong has not. The patching process is not exciting. The patching process does not win awards. The patching process, when done well, prevents the breach that would have made the headlines. Here is what the patching process looks like at scale, in 2026, and what the defender needs to have in place before the next critical CVE lands.

What the patching process actually is

Five stages, in roughly that order of maturity. The first serves as inventory. The defender has the complete asset inventory, across the cloud, the on premises, the SaaS, the shadow IT. The inventory is updated continuously. The inventory acts as input to every other stage. The defender who does not have the inventory is patching in the dark. The second functions as prioritisation. The defender has the vulnerability scoring, with the CISA KEV catalog, with the internal context (which systems are exposed, which systems hold sensitive data, which systems are critical). The prioritisation runs on the intake, on the change, on the weekly review. The third serves as testing. The defender has the test environment, with the representative workloads, with the integration tests, with the rollback plan. The testing runs before the patch reaches production. The fourth acts as deployment. The defender has the deployment automation, with the staged rollout, with the canary deployment, with the automated rollback. The deployment runs in minutes, not in days. The fifth functions as verification. The defender has the post deployment check, with the vulnerability scan, with the runtime detection, with the exception handling. The verification confirms the patch is in place and the system is working.

What the defender needs to have in place

Three capabilities, in priority order. The first serves as SBOM and the dependency graph. The defender knows what software is running on every system, and the defender knows which CVEs apply to that software. The SBOM is generated at build time, updated at deploy time, queried at patch time. The dependency graph tells the defender what else gets affected by patching one component. The second acts as patch automation. The defender has the CI/CD pipeline that takes the patch, runs the tests, deploys to the canary, monitors, rolls out, or rolls back. The patch automation is what makes the 5 stage process run in hours instead of weeks. The third functions as exception handling. The defender has the documented process for the patch that cannot be applied (the legacy system that breaks, the vendor that has not released a fix, the business critical workload that cannot tolerate the downtime). The exception handling is what keeps the patch SLA from being missed silently.

What the attacker is doing in 2026

Three patterns, in roughly that order of speed. The first serves as n day exploit. The CVE is published. The exploit code lands in the public repository within 48 to 72 hours. The attacker has the working exploit before the defender has the patched system. The defender who does not have the patching process right acts as defender who gets hit by the n day exploit. The second functions as supply chain CVE. The attacker compromises the upstream library, the upstream library ships the malicious update, the defender pulls the malicious update into the build, the defender ships the malicious build to production. The defender has the SBOM. The SBOM does not catch the upstream compromise in real time. The defender needs the dependency scanning tool that flags the suspicious update. The third is the configuration based exploit. The attacker exploits the misconfigured system, not the unpatched system. The defender who has the CSPM tool catches the misconfiguration. The defender who does not has the unpatched system plus the misconfigured system.

A patching at scale flow chart with inventory, prioritisation, testing, deployment, verification as the five stages, dark navy background, cyan and red.
Patching at scale in 2026: 5 stages (inventory, prioritisation, testing, deployment, verification), 3 capabilities (SBOM, patch automation, exception handling). The defender who has the process responds in hours. The one who does not responds in weeks.

The bottom line

Inventory, prioritisation, testing, deployment, verification. The 5 stage process runs in hours when the 3 capabilities exist. The 5 stage process runs in weeks when the 3 capabilities are missing. The attacker has the working exploit in 48 to 72 hours. The defender has to patch in the same window. Build the process now, before the next critical CVE.

Sources & Further Reading

All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.

Spotted an error? Email the editor. Corrections are issued with a visible correction note.

Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.

Continue reading