Patch Management and Vulnerability Response
Last reviewed: August 2026
Overview
Section titled “Overview”Operating cloud infrastructure involves two recurring security tasks.
- Periodic patching — Regularly applying security updates to the OS, runtime, and middleware
- Vulnerability response — When a CVE is disclosed, assessing the scope of impact and applying an urgent patch or mitigation
These are separate processes, but since tools and pipelines overlap, they’re covered together here.
Periodic Patch Management
Section titled “Periodic Patch Management”Vendor Patch Management Services
Section titled “Vendor Patch Management Services”| Vendor | Service | Target | Characteristics |
|---|---|---|---|
| AWS | Systems Manager Patch Manager | EC2 (Linux/Windows) | Defines patch baselines, schedules maintenance windows, compliance reporting |
| Azure | Azure Update Manager | VM (Linux/Windows), Arc-connected servers | Agentless assessment, scheduled patching, pre/post scripts |
| Google Cloud | OS Patch Management | Compute Engine (Linux/Windows) | Patch Jobs + Patch Deployments |
| OCI | OS Management Hub | Compute (Oracle Linux/Windows) | Package management, scheduled jobs, compliance reporting |
Patch Process
Section titled “Patch Process”graph LR
A[Patch scan<br/>assessment] --> B[Baseline<br/>approve/exclude] --> C[Test environment<br/>apply+validate] --> D[Production<br/>rolling apply]
- Scan/assess — Check the list of missing patches on current instances
- Define baseline — Classify which patch categories to auto-approve (Critical, Security, etc.) and set an exclusion list
- Test application — Apply to a non-production environment first to verify compatibility
- Production rollout — Apply sequentially by group within a maintenance window. Halt on failure
Patching Strategies
Section titled “Patching Strategies”| Strategy | Description | Suitable environment |
|---|---|---|
| Immutable Infrastructure | Replace instances with a patched new AMI/image | Containers, Auto Scaling groups, serverless |
| In-place Patching | Apply patches directly to a running instance | Stateful servers (DB, legacy apps) |
| Blue-Green | Prepare a patched new environment, then switch traffic | When minimizing downtime is required |
Vulnerability Detection and Response
Section titled “Vulnerability Detection and Response”Vendor Vulnerability Scanning Services
Section titled “Vendor Vulnerability Scanning Services”These services overlap with the CWPP area of Security Posture Management. Here they’re covered from a patch-response perspective.
| Vendor | Service | Scan target | Characteristics |
|---|---|---|---|
| AWS | Amazon Inspector | EC2, ECR images, Lambda | Agentless automatic scanning. CVE + network reachability analysis |
| Azure | Microsoft Defender for Cloud | VM, containers, App Service, DB | Integrated CSPM + CWPP. Vulnerability assessment + security recommendations |
| Google Cloud | Security Command Center + Artifact Analysis | Compute Engine, GKE, Artifact Registry | Integrated vulnerability + misconfiguration + threat detection |
| OCI | Vulnerability Scanning | Compute, Container Registry | Agent-based host scanning + container image scanning |
Container Image Vulnerability Scanning
Section titled “Container Image Vulnerability Scanning”In container environments, detecting vulnerabilities at image build time is essential.
| Vendor | Registry scanning | CI/CD integration |
|---|---|---|
| AWS | ECR image scanning (integrated with Inspector) | Automatic scanning in CodeBuild/CodePipeline |
| Azure | Defender for Containers (ACR scanning) | Azure DevOps/GitHub Actions integration |
| Google Cloud | Artifact Analysis (Artifact Registry) | Automatic scan on Cloud Build triggers |
| OCI | Container Registry scanning | Integrated with DevOps service pipelines |
Vulnerability Response Process
Section titled “Vulnerability Response Process”graph LR
A[CVE disclosed] --> B[Impact assessment] --> C[Priority determined] --> D[Mitigate·patch] --> E[Verify] --> F[Deploy]
| Stage | Activity | Example tools |
|---|---|---|
| Detection | The vulnerability scanner matches CVEs | Inspector, Defender, SCC |
| Impact assessment | CVSS score + actual exposure (network reachability, whether used at runtime) | Inspector network reachability, Defender attack path analysis |
| Prioritization | Critical + externally exposed = respond immediately. Low + internal only = next regular patch cycle | CVSS + EPSS + business impact |
| Mitigation | Temporary measures before patching (WAF rule, network isolation, disabling the feature) | WAF, Security Group, feature flag |
| Apply patch | Regular patch process or an urgent hotfix | Patch Manager, image rebuild |
| Verify | Rescan for vulnerabilities after patching + confirm normal service operation | Rescan + smoke test |
Emergency Vulnerability (Zero-Day) Response
Section titled “Emergency Vulnerability (Zero-Day) Response”The response framework for urgent situations that can’t wait for the regular patch cycle.
| Step | Activity |
|---|---|
| 1. Receive alert | Monitor vendor security bulletins, CVE feeds, security news |
| 2. Identify scope | Immediately query the list of resources using the vulnerable package/version (leveraging SBOM) |
| 3. Immediate mitigation | Network isolation, WAF virtual patching, disabling the vulnerable feature |
| 4. Emergency patch | Apply the vendor patch release immediately (reduced testing may be acceptable, but always prepare a rollback plan) |
| 5. Post-verification | Rescan the entire environment, check for indicators of compromise (IOC) |
Automation Best Practices
Section titled “Automation Best Practices”- Golden image pipeline — Periodically build patched base images, and deploy all instances/containers from them
- Compliance dashboard — Real-time monitoring of the proportion of unpatched instances (target: 95%+ compliance)
- SLA-based patch deadlines — Critical: within 72 hours, High: within 7 days, Medium: within 30 days (adjust per organizational policy)
- Automatic ticket creation — Automatically create a Jira/ServiceNow ticket when a vulnerability is detected, for tracking
- Regular reporting — Monthly patch compliance rate, mean time to patch (MTTP), trend of unresolved vulnerabilities
Common Mistakes
Section titled “Common Mistakes”- Applying patches directly to production without testing — Compatibility issues cause service incidents. Always validate in a non-production environment first.
- Deciding priority by CVSS score alone — You need to also consider actual exploit likelihood (EPSS) and network exposure. A High CVE on an externally exposed server can be more urgent than a Critical CVE on an internal-only server.
- Not maintaining an SBOM, causing days of delay in identifying impact scope during an emergency CVE — Enable automatic SBOM generation in Inspector/Artifact Analysis.
Checklist
Section titled “Checklist”- Is the proportion of unpatched instances monitored in real time (target: 95%+ compliance)?
- Is a patch SLA defined for Critical vulnerabilities (e.g., within 72 hours)?
- Is there a golden image pipeline that periodically rebuilds container base images?