cve-responder queries your fleet for vulnerable images and patches them in bulk.
Critical CVE drops. You need to:
- Query the fleet - Which of your 500 deployments run the vulnerable image?
- Patch them all - Update every affected deployment to the fixed version
Your manifests are in Git. To find vulnerable deployments:
grep -r "log4j:2.14" ~/gitops-repos/
# Problems:
# - Helm values and Kustomize overlays hide actual images
# - Multiple repos, multiple branches
# - Results are files, not deploymentsTo patch:
- Find all affected files
- Edit each one
- Commit, PR, review, merge
- Wait for Argo/Flux to sync (2-10 min per cluster)
Total time: hours.
Query and bulk mutate via API:
# Query: Find affected units (seconds)
cub unit list --space '*' --where "Data CONTAINS 'log4j:2.14'"
# Mutate: Patch all of them (one command)
cub run set-image --image 'log4j:2.17' --where "Data CONTAINS 'log4j:2.14'" --space '*'
# Apply: Deploy immediately
cub unit apply --where "Data CONTAINS 'log4j:2.17'" --space '*'Total time: minutes.
Git is the source. CI syncs Git → ConfigHub. Normal changes go through Git.
Emergency flow:
- Query ConfigHub (what's affected?) — seconds
- Patch in ConfigHub (bulk update) — one command
- Apply to clusters — immediate
- Open PR to Git (sync back) — closes the loop
Git (source) ←─────── PR ────────┐
│ │
│ CI sync │ sync back
▼ │
ConfigHub (operational) ─────────┘
│
▼ apply
Cluster
The PR keeps Git consistent. When CI syncs the merged PR to ConfigHub, it's a no-op because ConfigHub already has the change.
┌─────────────────────────────────────────────────────────────┐
│ cve-responder │
├─────────────────────────────────────────────────────────────┤
│ CVE Monitor │ Scanner │ Patcher │
│ - NVD feed │ - Query ConfigHub │ - Bulk update │
│ - GitHub advisories │ - Match images │ - Apply │
│ - Custom feeds │ - Report affected │ - Git PR │
└─────────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
CVE Feeds ConfigHub API Git API
│
▼
Kubernetes
# Using ConfigHub SDK
units, _ := client.Units().List(ctx, &confighub.UnitListOptions{
Space: "*",
Where: fmt.Sprintf("Data CONTAINS '%s'", vulnerableImage),
})# Bulk image update
cub run set-image \
--image "library/nginx:1.25-patched" \
--where "Data CONTAINS 'nginx:1.24'" \
--space '*-prod-*'# Immediate apply to all affected
cub unit apply --where "Labels.cve-patched = 'CVE-2024-1234'" --space '*'# Export patched config and open PR
cub unit get-data trade-service --space prod-us > manifests/prod-us/trade-service.yaml
git add . && git commit -m "CVE-2024-1234: patch nginx to 1.25"
gh pr create --title "CVE-2024-1234 patch" --body "Auto-generated by cve-responder"What cve-responder provides:
- Query speed: Find affected deployments in seconds vs. hours of grep
- Patch speed: Bulk update without per-file edits
- Immediate apply: Skip the PR/merge/sync cycle for emergencies
- Audit trail: ConfigHub tracks who changed what when
What it does NOT provide:
- CVE detection in running containers (use Trivy, Grype, etc.)
- Image scanning (integrates with existing scanners)
- Magic - you still need to know the patched image version
When to use it:
- Critical CVE requiring immediate patching across multiple clusters
- Scheduled vulnerability remediation at scale
- Any bulk image update operation
When NOT to use it:
- Single deployment patch (just edit Git directly)
- Non-urgent updates (normal GitOps flow is fine)
Not yet implemented. This SPEC defines the requirements.
- ConfigHub SDK (Go)
- ConfigHub CLI (
cub) - GitHub API (for PR creation)
- CVE feed access (NVD, GitHub Advisories)