Time to Patch (Security Vulnerabilities)

Overview

Time to Patch measures the elapsed time from when a security vulnerability is disclosed (or detected) to when your team successfully deploys a patch to production. It's a critical metric for security posture, compliance, and risk management.

Why It Matters

• Security risk: Unpatched vulnerabilities are attack vectors
• Compliance: Many regulations (SOC 2, PCI DSS, HIPAA) require timely patching
• Brand reputation: Security breaches damage customer trust
• Financial impact: Breaches are expensive (average $4.45M per incident)
• Legal liability: Negligence in patching can lead to lawsuits
• Competitive advantage: Strong security builds customer confidence

Types of Vulnerabilities

By Severity (CVSS Score)

| Severity | CVSS Score | Target Time to Patch | Examples | |----------|-----------|-------------------|----------| | Critical | 9.0-10.0 | < 24 hours | Remote code execution, SQL injection | | High | 7.0-8.9 | < 7 days | Authentication bypass, privilege escalation | | Medium | 4.0-6.9 | < 30 days | XSS, information disclosure | | Low | 0.1-3.9 | < 90 days | Minor information leaks |

By Source

Direct Dependencies:

• Libraries/packages your code imports directly
• Easier to patch (update version in package.json)
• Higher priority (directly exposed)

Transitive Dependencies:

• Dependencies of your dependencies
• Harder to patch (may require upstream fixes)
• Lower priority (indirect exposure)

Operating System:

• OS-level vulnerabilities
• Patched through system updates
• Infrastructure team responsibility

Container Images:

• Base image vulnerabilities
• Requires rebuilding and redeploying containers
• DevOps team responsibility

How to Measure

Timeline

Vulnerability Lifecycle:
────────────────────────────────────────────────────────────
Disclosure → Detection → Triage → Fix → Test → Deploy → Verify
    ↓            ↓          ↓       ↓      ↓       ↓        ↓
  CVE          Alert    Assess   Code   QA    Prod    Scan
  published    fires    priority  change        live    clear
    │←─────────── Time to Patch ──────────────────────→│

Calculation

Time to Patch = Deployment Time - Disclosure Time

Example:
- Vulnerability disclosed: Monday 9:00 AM
- Patch deployed: Tuesday 2:00 PM
- Time to Patch: 29 hours (1.2 days)

Severity: Critical (CVSS 9.8)
Status: ✓ Met 24-hour SLA

What to Track

Start Time (choose one):

• Public disclosure: CVE publication date (recommended)
• Detection: When your scanner found it
• Notification: When security team was alerted

End Time:

• Production deployment: When patch is live (recommended)
• Verification: When vulnerability scan confirms fix

Recommended Visualizations

1. Histogram by Severity

Best for: Understanding patch time distribution

2. Trend Line (P50, P95 by Severity)

Best for: Tracking improvement over time

3. Gauge (Current Status)

Best for: Executive dashboards

Target Ranges

Industry Standards

| Framework | Requirement | |-----------|------------| | PCI DSS | Critical: < 30 days, High: < 90 days | | SOC 2 | Documented remediation timeline | | HIPAA | "Reasonable and appropriate" timeframe | | NIST | Critical: < 15 days, High: < 30 days | | CIS | Critical: < 15 days, High: < 30 days |

Best Practice Targets

| Severity | Target | Acceptable | Excellent | |----------|--------|-----------|-----------| | Critical (9-10) | < 24 hours | < 3 days | < 12 hours | | High (7-8.9) | < 7 days | < 14 days | < 3 days | | Medium (4-6.9) | < 30 days | < 60 days | < 14 days | | Low (0-3.9) | < 90 days | < 180 days | < 30 days |

By Environment

Production (highest priority):

• Critical: < 24 hours
• High: < 7 days

Staging:

• Critical: < 48 hours
• High: < 14 days

Development:

• Lower priority, can be included in regular updates

How to Improve

1. Automated Detection

Dependency Scanning:

# GitHub Actions - Dependency scanning
name: Security Scan
on: [push, pull_request]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      - name: Fail on high/critical
        run: |
          if [ "$SNYK_SEVERITY" == "critical" ] || [ "$SNYK_SEVERITY" == "high" ]; then
            exit 1
          fi

Continuous Monitoring:

• Snyk: Real-time monitoring of npm, PyPI, Maven, etc.
• Dependabot: Automated PRs for vulnerable dependencies
• WhiteSource: Enterprise security scanning
• GitHub Security Advisories: Native GitHub alerts

2. Automated Patching

Auto-merge low-risk updates:

# Dependabot auto-merge
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 10
    reviewers:
      - "security-team"
    # Auto-merge patch versions
    auto-merge:
      - dependency-name: "*"
        update-types: ["version-update:semver-patch"]

Renovate Bot Configuration:

{
  "extends": ["config:base"],
  "schedule": ["after 10pm every weekday"],
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security", "priority-high"]
  },
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true
    }
  ]
}

3. Prioritization Framework

Decision Matrix:

                High Exploitability
                        │
    Low Exposure        │        High Exposure
    Low Severity        │        High Severity
    → Schedule          │        → URGENT
────────────────────────┼────────────────────────
    Low Exposure        │        High Exposure
    High Severity       │        Low Severity
    → Priority          │        → Monitor
                        │
                Low Exploitability

Triage Questions:

1. Severity: What's the CVSS score?
2. Exposure: Is vulnerable code in production?
3. Exploitability: Is there a known exploit (exploit-db)?
4. Mitigation: Can we apply temporary mitigations?
5. Fix availability: Is a patch available?

4. Fast-Track Process

Emergency Patch Process:

1. Detect (0-30 min): Automated alert fires
2. Triage (30-60 min): Security team assesses severity
3. Fix (1-4 hours): Update dependency version
4. Test (1-2 hours): Automated tests + smoke tests
5. Deploy (30 min): Fast-track deployment (skip non-critical checks)
6. Verify (30 min): Rescan to confirm fix

Total Time: 4-8 hours for critical vulnerabilities

5. Reduce Dependencies

Minimize Attack Surface:

• Audit dependencies: Remove unused packages
• Choose well-maintained libraries
• Prefer dependencies with few transitive deps
• Use dependency freeze for stable versions

# Find unused dependencies
npm-check -u

# Audit dependency tree
npm ls --all

# Check for vulnerabilities
npm audit

Common Pitfalls

❌ Ignoring Low Severity Vulnerabilities

Problem: They pile up and become unmanageable Solution: Dedicate time each sprint to patch medium/low issues

❌ Waiting for Perfect Test Coverage

Problem: Delays critical security patches Solution: Fast-track critical patches, add tests after if needed

❌ No Rollback Plan

Problem: Bad patch takes down production Solution: Ensure rollback works before deploying security patches

❌ Patching Without Testing

Problem: Breaking changes slip through Solution: Automated tests + smoke tests, even for urgent patches

❌ Not Tracking Transitive Dependencies

Problem: Vulnerable indirect dependencies go unnoticed Solution: Use tools that scan full dependency tree

Implementation Guide

Week 1: Instrumentation

# Install security scanning
npm install --save-dev snyk

# Run initial scan
snyk test

# Review vulnerabilities
snyk monitor

Week 2: Establish Baselines

• Document all current vulnerabilities
• Calculate current time to patch (historical)
• Set up alerting for new vulnerabilities
• Define SLAs by severity

Week 3: Automation

# CI/CD integration
- name: Security Scan
  run: |
    snyk test --severity-threshold=high
    npm audit --audit-level=high

Week 4: Process

• Create security runbook
• Define on-call rotation for security issues
• Establish communication channels (#security-alerts)
• Document escalation procedures

Dashboard Example

Security Team View

┌──────────────────────────────────────────────┐
│ Time to Patch (Critical Vulnerabilities)     │
│ Average: 18 hours         ✓ Under 24h SLA    │
│ ██████████████████████░░░░░░░░░░ Good        │
│                                              │
│ Open Vulnerabilities:                        │
│ • Critical (9-10):  2  ⚠️ URGENT             │
│ • High (7-8.9):     8  ⚠️ Priority           │
│ • Medium (4-6.9):   23 Monitor               │
│ • Low (0-3.9):      45 Backlog               │
│                                              │
│ This Month:                                  │
│ • Patched: 12 vulnerabilities                │
│ • Avg Time: 18 hours                         │
│ • SLA Compliance: 92%                        │
└──────────────────────────────────────────────┘

Detailed View

Recent Critical Vulnerabilities
─────────────────────────────────────────────────────────
CVE ID         CVSS  Package        Detected   Patched  Time
─────────────────────────────────────────────────────────
CVE-2024-1234  9.8   log4j          Jan 15     Jan 15   8h   ✓
CVE-2024-2345  9.1   axios          Jan 20     Jan 21   22h  ✓
CVE-2024-3456  9.0   express        Jan 25     OPEN     72h  ⚠️
─────────────────────────────────────────────────────────

Breakdown by Stage (Avg):
Detection:      2 hours   (11%)
Triage:         3 hours   (17%)
Development:    8 hours   (44%)
Testing:        3 hours   (17%)
Deployment:     2 hours   (11%)
────────────────────────
Total:          18 hours

Related Metrics

• Vulnerability Count: How many open vulnerabilities?
• Exposure Time: Days vulnerable code is in production
• Patch Coverage: % of vulnerabilities patched vs. accepted risk
• Security Debt: Accumulated unpatched vulnerabilities
• Deployment Frequency: Ability to deploy patches quickly
• Change Failure Rate: Quality of patches (do they break things?)

Tools & Integrations

Vulnerability Scanners

• Snyk: Multi-language support, great GitHub integration
• Dependabot: Free for GitHub, automatic PRs
• WhiteSource (Mend): Enterprise-grade, compliance focus
• Sonatype Nexus: Java/Maven ecosystem
• GitHub Advanced Security: Native GitHub scanning
• JFrog Xray: Artifact scanning

Container Scanning

• Trivy: Fast, accurate, open-source
• Clair: Container vulnerability scanning
• Anchore: Policy-based container analysis
• Docker Scout: Docker's official scanner

OS/Infrastructure

• AWS Inspector: EC2 and container scanning
• GCP Security Command Center: GCP resource scanning
• Azure Security Center: Azure resource scanning
• Wazuh: Host-based intrusion detection

Questions to Ask

For Leadership

• Are we meeting our SLAs for critical vulnerabilities?
• Do we have unpatched critical vulnerabilities in production?
• Are we compliant with security frameworks (PCI, SOC 2)?
• Do we need to invest in faster deployment capabilities?

For Security Teams

• What's blocking us from patching faster?
• Are dependencies up to date?
• Do we have good test coverage for quick validation?
• Are we monitoring all attack surfaces?

For Engineering Teams

• How quickly can we deploy an emergency patch?
• Do we have a rollback plan?
• Are we regularly updating dependencies?
• Can we reduce our dependency count?

Success Stories

FinTech Startup

• Before: 10-day average for critical patches
• After: 8-hour average for critical patches
• Changes:
  • Implemented automated dependency scanning
  • Fast-track deployment process for security patches
  • On-call security rotation
  • Pre-approved emergency change process
• Impact: 94% reduction in time to patch, zero security incidents

SaaS Platform

• Before: 50+ unpatched high/critical vulnerabilities
• After: 0 unpatched critical, avg 3 high vulnerabilities
• Changes:
  • Dependabot auto-merge for patch versions
  • Security Champions program
  • Weekly vulnerability review meetings
  • 20% sprint capacity for dependency updates
• Impact: Passed SOC 2 audit, customer trust improved

Advanced Topics

Zero-Day Vulnerabilities

Response Protocol:
1. Immediate assessment (< 1 hour)
2. Apply temporary mitigation (< 4 hours)
3. Monitor for exploit attempts
4. Deploy patch when available
5. Conduct post-incident review

Supply Chain Attacks

• Verify package integrity (checksums, signatures)
• Use private registries for critical dependencies
• Implement Software Bill of Materials (SBOM)
• Monitor for suspicious dependency updates

Bug Bounty Programs

• Coordinate disclosure with security researchers
• Have clear patching SLAs in policy
• Communicate fixes to researchers
• Track time to patch for bounty submissions

Conclusion

Time to Patch is a critical security metric that measures your organization's ability to respond to vulnerabilities. Elite teams patch critical vulnerabilities within 24 hours through automated detection, fast-track processes, and high deployment frequency. Start measuring today, automate vulnerability detection, establish clear SLAs by severity, and practice emergency patch procedures. Remember: every hour a critical vulnerability remains unpatched increases your risk exponentially.

Quick Start Checklist:

• [ ] Install vulnerability scanner (Snyk, Dependabot)
• [ ] Run initial scan, document baseline
• [ ] Set up automated alerts for new vulnerabilities
• [ ] Define SLAs by severity
• [ ] Create fast-track patch process
• [ ] Practice emergency patch deployment
• [ ] Measure and track time to patch