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)?
# 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.
- 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).