iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

Patch Management

By · Reviewed & last updated · Part of OWASP Top 10 Tutorial

Patch management is the boring control that prevents most real breaches. The question is not whether to patch, it is how to ship security patches as fast as feature work without breaking production. The pattern that works: SBOM + vulnerability scan in CI, Dependabot/Renovate PRs, automated tests, staged rollout, and a documented emergency-patch playbook.

A patch pipeline: SBOM, scan, auto-PR, emergency path

EXAMPLE
# 1) Generate an SBOM (Software Bill of Materials) on every build
# .github/workflows/sbom.yml
name: sbom
on:
  push: { branches: [main] }
  schedule: [{ cron: '0 6 * * 1' }]   # weekly drift check
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anchore/sbom-action@v0
        with: { format: cyclonedx-json, output-file: sbom.json }
      - uses: anchore/scan-action@v3
        with:
          path: ./sbom.json
          fail-build: true
          severity-cutoff: high

# 2) Auto-PRs for upgrades (Dependabot config)
# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: composer
    directory: '/'
    schedule: { interval: weekly }
    open-pull-requests-limit: 10
    groups:
      laravel:
        patterns: ['laravel/*', 'illuminate/*']
      dev-deps:
        dependency-type: development
  - package-ecosystem: npm
    directory: '/'
    schedule: { interval: weekly }
    versioning-strategy: increase
  - package-ecosystem: docker
    directory: '/'
    schedule: { interval: weekly }

# 3) PR template that forces a security signoff
# .github/pull_request_template.md
## What changed
## Tests
## Security review
- [ ] Diff touches dependencies → ran 'composer audit' / 'npm audit'.
- [ ] CVE summary attached if any.
- [ ] Rollback documented.

# 4) Emergency patch playbook (paste into runbooks/)
## Emergency security patch
1. Confirm CVE applies (component AND vulnerable code path actually used).
2. Branch from main: \\`git checkout -b hotfix/<cve>\\`.
3. Bump the affected package(s) to the patched version, run tests.
4. Open a PR labelled 'security'. Bypass normal review SLA via on-call.
5. Deploy to staging, run smoke + canary in production behind a flag.
6. Roll out at 5% → 25% → 100% with 10 minutes per step.
7. Post-mortem within 7 days: how did the dep land, what alerted us, what slowed us down?

# 5) Patch-status dashboard query (any vuln DB)
# Critical/High open > 7d  ->  page
# Medium open > 30d        ->  ticket
# Low open > 90d           ->  backlog

Why it matters

The metric that predicts breaches is mean-time-to-patch (MTTP), not patch volume. A team patching critical CVEs in 48 hours is dramatically safer than one that batches monthly updates. Optimise the pipeline for speed of the urgent one — automated PR, fast CI, easy rollback — and the routine ones come along for free.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
// Track dependencies in an SBOM.
// Define SLAs: Critical < 24h, High < 7d, Medium < 30d.
// Use Dependabot / Renovate to open PRs automatically.
Try it Yourself »

Discussion

Loading…