Patch management process is documented for critical updates

PCI-DSS 4.0 Req 6.3 requires that security vulnerabilities in all system components are identified and ranked by risk; Req 6.3.3 requires that all system components are protected from known vulnerabilities by installing applicable security patches. Without a documented patch policy with SLA timeframes, a critical CVE in a production dependency may sit unaddressed for weeks while your CDE remains exposed. CWE-1357 (Reliance on Uncontrolled Component) is the mechanism by which supply-chain vulnerabilities become active exploits. NIST SI-2 and SSDF RV.1 both require a defined remediation timeline tied to severity.

Create docs/patch-management.md defining at minimum two severity tiers with explicit SLA deadlines (e.g., critical: 48 hours, high: 7 days) and configure automated patching via Dependabot or Renovate. The document and the automation together satisfy PCI-DSS 4.0 Req 6.3.3.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: daily
      time: "02:00"
    open-pull-requests-limit: 5
    reviewers:
      - security-team

In the policy document, state explicitly: "Critical patches (CVSS 9.0+): applied within 48 hours. High patches (CVSS 7.0–8.9): applied within 7 days." Link the Dependabot config from the policy document so the audit trail from documented SLA to automated enforcement is traceable.

• ID: ecommerce-pci.monitoring-compliance.patch-management

• Severity: high

• What to look for: Search for patch management documentation files (look for "patch", "update", "maintenance" in docs/ and project root). Count the number of patch classification tiers defined (e.g., critical, high, medium, low). Check for SLA definitions with specific timeframes (e.g., "48 hours for critical"). Count automated patching configurations: Dependabot/Renovate configs, auto_minor_version_upgrade in Terraform, scheduled maintenance windows.

• Pass criteria: At least 1 documented patch management process exists. The document defines at least 2 patch severity tiers with specific SLA timeframes (e.g., "critical: 48 hours, high: 7 days"). At least 1 automated patching mechanism is configured (Dependabot, Renovate, or infrastructure auto-patching). Report: "X severity tiers defined, Y automated patching configs found."

• Fail criteria: No patch management documentation found, or documentation exists but lacks specific SLA timeframes for at least 2 severity tiers, or 0 automated patching mechanisms configured.

• Skip (N/A) when: Infrastructure fully managed by third-party (no infrastructure code, no dependencies to patch, fully serverless with no dependency management).

• Detail on fail: Specify the gap. Example: "No patch management documentation found. 0 Dependabot/Renovate configs. 0 automated patching mechanisms." or "docs/patch-management.md exists but defines only 1 severity tier with no SLA timeframe."

• Cross-reference: See ecommerce-pci.network-security.vulnerability-scanning (automated scanning), ecommerce-pci.monitoring-compliance.vendor-compliance (vendor update tracking).

• Remediation: Document patch management process. Create docs/patch-management.md:

  # Patch Management Policy
  
  ## Patch Classification
  - **Critical**: Security vulnerability (CVSS 9.0+) or active exploit. Apply within 48 hours.
  - **High**: Important security update (CVSS 7.0-8.9). Apply within 7 days.
  - **Medium**: Security enhancement (CVSS 4.0-6.9). Apply within 30 days.
  - **Low**: Non-security updates (CVSS < 4.0). Apply in next release cycle.
  
  ## Process
  
  1. **Monitoring** (continuous)
     - Subscribe to security advisories (NVD, vendor mailing lists)
     - Run automated scanning (Snyk, Dependabot, npm audit)
  
  2. **Assessment** (1-4 hours for critical patches)
     - Evaluate patch impact
     - Check for breaking changes
     - Verify compatibility
  
  3. **Testing** (4-24 hours)
     - Apply patch to development environment
     - Run regression tests
     - QA validation
  
  4. **Deployment** (24-48 hours for critical)
     - Deploy to staging
     - Final validation
     - Deploy to production (during low-traffic window if possible)
  
  5. **Verification** (post-deployment)
     - Confirm patch applied successfully
     - Monitor for issues
     - Update patch log
  
  ## Automation
  
  Dependencies are automatically updated via Dependabot:
  ```yaml
  # .github/dependabot.yml
  version: 2
  updates:
    - package-ecosystem: npm
      directory: /
      schedule:
        interval: daily
        time: "02:00"
      open-pull-requests-limit: 5
      reviewers:
        - security-team
      allow:
        - dependency-type: direct
        - dependency-type: indirect # include transitive
  

  OS and infrastructure patches applied automatically:

  # Terraform: Enable auto-patching for RDS
  resource "aws_db_instance" "main" {
    engine_version = "15.2"
    auto_minor_version_upgrade = true
    preferred_maintenance_window = "sun:02:00-sun:03:00"
    backup_retention_period = 30
  }