---
title: Vulnerability and patch response
slug: vulnerability-and-patch-response
summary: How to go from a CVE or scanner finding to a patched, verified fleet, with severity-based deadlines and a fast path for actively exploited bugs.
order: 19
updated: 2026-11-11
status: ready
---

Use this page when a scanner reports findings, a vendor advisory lands, or a widely exploited vulnerability is in the news. The job is to answer "are we exposed, where, and by when is it fixed?".

## Set deadlines by real risk

| Severity | Examples | Fix within |
| --- | --- | --- |
| Critical and known exploited | Listed in a known-exploited catalog, internet-facing | 48 h, emergency change |
| Critical | Remote code execution, no exploit seen yet | 7 days |
| High | Privilege escalation, auth bypass on internal service | 30 days |
| Medium and low | Everything else | Next regular patch cycle |

Raise the priority for internet-facing systems and anything inside a regulated scope. Lower it, with a written reason, when the vulnerable code path is not reachable.

## Triage a finding

- [ ] Which package and version, and which fixed version?
- [ ] Where is it: which images, hosts, functions, repos? Use the scanner's inventory, not memory.
- [ ] Is it reachable: internet-facing, behind auth, internal only?
- [ ] Is there a mitigation if a patch is not ready (WAF rule, config flag, disable feature)?

```bash
# Container image scan
trivy image --severity CRITICAL,HIGH --ignore-unfixed <registry>/<image>:<tag>

# Dependency scan of a repo
trivy fs --scanners vuln --severity CRITICAL,HIGH .

# Which running ECS tasks use an image (read-only)
aws --profile <readonly-profile> --region <region> ecs describe-task-definition \
  --task-definition <family> --query 'taskDefinition.containerDefinitions[].image'
```

## Patch

- [ ] Containers: bump the base image or package, rebuild, deploy through the normal pipeline with [blue-green](./blue-green-deploys-with-rollback.md).
- [ ] Hosts: patch through a managed process (for example SSM Patch Manager with patch baselines and maintenance windows), canary first.
- [ ] Managed services: schedule the engine or minor version upgrade, non-production first.
- [ ] Libraries: dependency bump MR; let CI prove tests pass.

## Verify

- [ ] Re-scan shows the finding closed.
- [ ] The running version (not just the repo) is the fixed one.
- [ ] Ticket records scope, fix date and evidence.

## Keep the base healthy

- [ ] Small base images (distroless or slim) mean fewer findings. Multi-stage builds keep build tools out of runtime images.
- [ ] Automated dependency update MRs (Renovate or Dependabot) with auto-merge for patch releases that pass tests in non-production repos.
- [ ] Rebuild images on a schedule even without code changes, so base fixes flow in.

## Pitfalls

- Patching the repo but not redeploying.
- Ignoring findings as "false positives" without a written reachability reason.
- Emergency patches with no rollback plan. Even emergency changes are logged and reversible (see [change control](./change-control-in-regulated-environments.md)).