Skip to content

Latest commit

 

History

History
162 lines (121 loc) · 4.98 KB

File metadata and controls

162 lines (121 loc) · 4.98 KB

cve-responder SPEC

What It Does

cve-responder queries your fleet for vulnerable images and patches them in bulk.

The Problem

Critical CVE drops. You need to:

  1. Query the fleet - Which of your 500 deployments run the vulnerable image?
  2. Patch them all - Update every affected deployment to the fixed version

Why This Is Hard With GitOps

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 deployments

To patch:

  1. Find all affected files
  2. Edit each one
  3. Commit, PR, review, merge
  4. Wait for Argo/Flux to sync (2-10 min per cluster)

Total time: hours.

What ConfigHub Provides

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.

How It Works With Git

Git is the source. CI syncs Git → ConfigHub. Normal changes go through Git.

Emergency flow:

  1. Query ConfigHub (what's affected?) — seconds
  2. Patch in ConfigHub (bulk update) — one command
  3. Apply to clusters — immediate
  4. 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.

Architecture

┌─────────────────────────────────────────────────────────────┐
│                     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

Core Operations

1. Scan for Vulnerable Images

# Using ConfigHub SDK
units, _ := client.Units().List(ctx, &confighub.UnitListOptions{
    Space: "*",
    Where: fmt.Sprintf("Data CONTAINS '%s'", vulnerableImage),
})

2. Patch Affected Units

# Bulk image update
cub run set-image \
  --image "library/nginx:1.25-patched" \
  --where "Data CONTAINS 'nginx:1.24'" \
  --space '*-prod-*'

3. Apply Changes

# Immediate apply to all affected
cub unit apply --where "Labels.cve-patched = 'CVE-2024-1234'" --space '*'

4. Sync Back to Git

# 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"

Value Proposition (Honest Assessment)

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)

Implementation Status

Not yet implemented. This SPEC defines the requirements.

Dependencies

  • ConfigHub SDK (Go)
  • ConfigHub CLI (cub)
  • GitHub API (for PR creation)
  • CVE feed access (NVD, GitHub Advisories)