4 MIN READ
Patching at scale amounts to the unglamorous work of security, and the security org that has the patching process right has solved the bulk of the vulnerability problem. The org that has it wrong has not, and the next critical CVE will not wait for the team to catch up. CISA KEV catalog added 174 vulnerabilities in 2025, and the median time from CVE publication to public exploit code dropped to 48 hours by the end of the year. The patching process that runs in weeks sits as the process the threat actor outruns.
Lineage worth knowing. The 2017 Equifax breach came down to an unpatched Apache Struts instance, the 2021 Kaseya VSA attack exploited a zero day in the on premise VSA appliance, the 2024 MoveIt Transfer campaign hit hundreds of organisations through a single CVE in a managed file transfer product. Three different years, three different products, the same shape: a known vulnerability, an unpatched system, a working exploit. The pattern has not changed. The volume has.
What the patching process actually is
The patching process runs through five stages, in roughly that order of maturity. Asset inventory sits at the front, with the security org needing the complete picture of what runs where across the cloud accounts, the on premises servers, the SaaS platforms, the shadow IT. Without the inventory, the patching process runs in the dark, and the dark sits as where the threat actor lives. From there the process moves into prioritisation, where CISA KEV gets watched first, the EPSS score gives the probability signal, and the internal context (which systems sit exposed, which hold sensitive data, which sit as business critical) sets the actual order. Testing sits as the next gate, with a representative environment, integration tests that catch the regressions, and a documented rollback plan. Deployment comes after, with staged rollout, canary deployment, and automated rollback, the whole sequence running in minutes rather than days. Verification closes the cycle, with the post deployment scan, the runtime detection, and the exception handling for the patch that could not be applied. Verification amounts to the proof the patch sits in place, the proof the audit will look for, and the proof most security orgs skip.
What the security org needs to have in place
Three capabilities turn the five stage process from a quarterly fire drill into a working week, with the SBOM and dependency graph handling what software runs on every system and which CVEs apply. CycloneDX and SPDX both work as the SBOM format, and tools like Snyk, Mend, and Anchore generate them at build time. Patch automation handles the actual deployment, with the CI/CD pipeline taking the patch, running the tests, deploying to the canary, monitoring the metrics, and rolling out or rolling back, all without a human in the loop. Exception handling covers the gaps: the legacy system that breaks on the patch, the vendor that has not released a fix, the business critical workload that cannot tolerate the downtime. The process that runs through the pipeline finishes in hours, while the one that runs through the change board finishes in weeks. Exception handling sits as what keeps the patch SLA from being missed silently and the audit from finding a dozen unremediated CVEs in the next cycle.
What the threat actor is doing in 2026
Three patterns show up in the 2026 incident data, in roughly that order of how fast each one moves. N day exploitation leads the way, with the CVE getting published, the exploit code landing in a public repository within 48 to 72 hours, and the threat actor having the working exploit before the security org has the patched system. The Mandiant 2025 M-Trends report puts the median time to exploitation at 5 days for the actively used CVEs. Supply chain compromise comes next, with the threat actor compromising the upstream library (the xz utils near miss in 2024 sat as the famous example, the Polyfill.io supply chain attack in 2024 sat as the working one), the malicious update shipping through the normal channel, and the SBOM not catching the compromise in real time. Configuration based exploitation sits as the third shape, with the threat actor exploiting the misconfigured system instead of the unpatched one. The org that has the CSPM tool catches the misconfiguration before the threat actor does. The org that does not has the unpatched system and the misconfigured system, and the threat actor walks through whichever door sits open.
The bottom line
SBOM, patch automation, exception handling. The five stage process runs in hours when the three capabilities exist, in weeks when they do not. The threat actor has the working exploit in 48 to 72 hours. Build the pipeline now, before the next critical CVE lands.
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.
