Patch Verification

Overview

Patch verification is the process of confirming that a security patch has been successfully applied to a target system. Without proper verification, organizations cannot ensure that remediation efforts have actually closed the identified vulnerabilities, leaving residual risk unaddressed.

Verification Methods

Registry Check

On Windows systems, registry keys serve as reliable indicators of installed updates. Verifiers should check HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and the Windows Update history via Get-HotFix or wmic qfe list. Look for the specific KB article number associated with the patch.

File Version Check

Cross-reference the installed binary version against the patched version published by the vendor. For example, after applying a patch for OpenSSL, verify that libssl.so (or libssl.dll) reports the expected patched version string. Use Get-ItemProperty on Windows or strings, dpkg -L, or rpm -q --filesbypkg on Linux to locate the binary and check its version metadata.

Package Manager Query

On Debian-based systems, run dpkg -l | grep <package> or apt list --installed to confirm the patched package version. On RHEL-based systems, use rpm -q <package>. For containerized environments, inspect the image layers with docker history or skopeo inspect to verify the patch layer is present.

Vulnerability Re-scan

After applying the patch, perform a targeted vulnerability scan against the remediated host using the same scanner (e.g., Nessus, Qualys, OpenVAS) that originally identified the finding. Confirm that the specific plugin or CVE no longer triggers. Automated re-scans should be scheduled within 24 - 48 hours of patch application.

Rollback Plan

Every patch deployment must include a documented rollback plan. At minimum, the plan should cover:

• Reverting the package to its previous version (e.g., apt-get install <package>=<old-version>)
• Restoring from a pre-patch system backup or snapshot
• Re-deploying the original virtual machine image
• Communicating the rollback to stakeholders via the change management system

Rollback procedures should be tested in a non-production environment before production deployment.

Staged Rollout

Patches should follow a staged deployment path to minimize blast radius:

If any stage fails verification, the patch is rolled back before proceeding to the next stage.

Patch Validation Testing

Beyond confirming version numbers, validation tests should exercise the patched component's core functionality to ensure it still works correctly. For a web server patch, this means verifying that HTTP requests return expected status codes, TLS handshakes complete successfully, and authentication flows are unaffected.

Regression Testing

Execute a predefined regression test suite covering the patched module's dependencies and interfaces. Automated CI/CD pipelines should include regression testing as a mandatory gate before a patch moves from staging to production. Any regression failure blocks the rollout and triggers a review.

Change Management (ITIL)

Patch verification activities must be integrated into the ITIL change management process:

1. Change Request - Submit a request describing the patch, affected systems, expected impact, and rollback plan.
2. Change Advisory Board (CAB) - Review and approve the change request for production deployment.
3. Change Implementation - Apply the patch following the approved plan.
4. Post-Implementation Review (PIR) - Within 5 business days, review verification results, incidents, and lessons learned.

All verification evidence (screenshots, scan reports, log excerpts) should be attached to the change record for audit readiness.