Security patch management: patching against an attacker's clock

Security patch management is the discipline that decides how fast a published vulnerability must be fixed on your assets, obtains the fix, applies it, and proves the exposure is gone. It sits between two neighboring practices. Vulnerability management is the wider risk program that finds weaknesses and chooses treatments. Patch management is the maintenance system that acquires, tests, and deploys updates on a schedule. Security patch management is the part where the deadline comes from the adversary rather than the maintenance calendar.

NIST SP 800-40 Rev. 4 defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades, and frames it as preventive maintenance — an ongoing cost of running technology. Security patching keeps every one of those steps and adds a clock to them. The clock is set by evidence about attackers, and it can shorten while work is already in progress.

The security patch pipeline

disclosure → identification → enrichment → urgency decision
                                                  ↓
   evidence ← verification ← application ← fix acquisition

Disclosure is the moment a flaw becomes public, or becomes known to a vendor under a deadline. Identification attaches a shared name to it — a CVE ID. Enrichment adds the machine-readable facts that later decisions consume: how much control an attacker gains, whether the attack can be automated, whether anyone is exploiting it. Urgency decision converts those facts plus your own asset context into a due date. Fix acquisition obtains a vendor fix, a mitigation, or a workaround. Application installs it under whatever change process the deadline allows. Verification confirms the vulnerable condition no longer exists on the asset. Evidence is what remains afterwards for audit, exception tracking, and the next cycle.

Each stage produces an input for the next, and every stage can fail quietly. A missing CVE ID means the flaw never enters the queue. Missing enrichment means the deadline defaults to something conservative. An unverified deployment means a dashboard reports compliance while the vulnerable code is still loaded.

Where vulnerability identity comes from

A CVE ID is assigned by a CVE Numbering Authority (CNA) — an organization authorized to assign identifiers for vulnerabilities in its own agreed scope. A CNA can be a software vendor, an open-source project, a coordination center, a bug bounty provider, or a research group. Once the CNA populates the record with a description and at least one public reference, the record moves from Reserved to Published. Records that should no longer be used move to Rejected and stay visible so consumers know the identifier is invalid.

The CVE Record Format also supports an Authorized Data Publisher (ADP) container, which lets a second organization attach data to a record it did not create. CISA uses that mechanism for its Vulnrichment program: it assesses new and recent CVEs and adds SSVC decision points, and adds CWE and CVSS data to higher-risk records where possible. This matters operationally, because a remediation deadline that depends on "is this automatable?" needs somebody to answer that question at scale, on every record, quickly.

The National Vulnerability Database (NVD) synchronizes with the CVE List and augments it with product names, impact metrics, and search. Vendor advisories remain the authority on which of their own product versions are affected and what to install.

Machine-readable advisories: CSAF and VEX