18.2 Software Updates and Patch Management Basics
Patch Like a Schedule, Not an Event
Every supplier runs its own rhythm. Microsoft ships security updates on the second Tuesday of each month with out-of-band releases for actively exploited flaws; Apple and Adobe follow their own cycles; Chrome and Firefox patch on a rolling basis with silent background updates sometimes within days, because browser bugs are the most-phished attack surface; Linux distributions publish security-only advisories, with enterprise releases backporting fixes into long-lived package versions and rolling releases moving whole upstream versions. End-of-life branches stop receiving fixes entirely, which turns "still supported?" into the first question of any inventory. Practical scheduling means aligning maintenance windows, reboot budgets, and change freezes to these cadences so patches land the week they are published rather than the quarter.
Signature Verification Is the Real Trust Anchor
An update path is a code-delivery supply chain, so you must never trust the transport alone. Packages carry detached or embedded signatures produced with the vendor's private key; the client validates them against a trusted keyring installed at build time. Windows Update and installers rely on Authenticode chain validation to a trusted root; RPM checks GPG signatures declared in the package header; apt and dpkg verify repository Release files signed by distribution keys. That is why an unsigned mirror or a stripped signature must fail closed -- the payload is dropped and an alert fires -- and why repo key rotation, pinned TLS to your internal mirror, and refusal of version downgrades all belong in the same policy. A valid signature from the wrong key is exactly as dangerous as none.
Rings, Automation, and Ordering
Manual patching does not scale past a handful of hosts, so deployment goes through configuration management and update services such as WSUS or Intune, Ansible, or Puppet. Rollouts are ringed: ring 1 is IT and security pilot machines, ring 2 a broader cross-section of app and hardware models, ring 3 the general estate, plus a deferred ring for business-critical systems with tight windows. Automation auto-approves low-risk categories, blocks vendor-listed "known bad" builds, and orders reboots inside agreed maintenance windows, with dependency sequencing so a runtime, driver, and dependent application move together rather than in isolation.
Compliance Reporting and Managed Exceptions
The output of a mature programme is not "patches sent" but per-host evidence: expected version versus installed version, patch success and failure codes, reboot-required state, and a percentage patch rate per ring and per owner. Where a system genuinely cannot be patched -- an appliance, a validated clinical or industrial controller -- the exception is a ticket with a named compensating control, an accountable owner, and an expiry date that forces re-review. Exceptions without dates silently become permanent risk.
Architecture Diagram
Key Takeaways
- Each supplier has its own cadence -- monthly, quarterly, or continuous auto-update -- and EOL branches stop getting fixes.
- Verify signatures against a trusted keyring (Authenticode, RPM GPG, signed apt Release); TLS alone is not enough.
- Fail closed on unsigned, wrong-key, or downgraded payloads, and alert on the drop.
- Ring 1 pilots, ring 2 broad sample, ring 3 general, plus a deferred ring for critical systems, driven by automation.
- Measure per-host compliance and treat unpatchable systems as dated exceptions with an owner and compensating control.