Patch Prioritization

Patch Prioritization & SLA Management -- SSVC 2.1 / EPSS v3 / CISA KEV

> Frameworks: SSVC 2.1 (CERT/CC), EPSS v3 (FIRST.org), CISA KEV (DHS/CISA) > Role: Security Engineer, vCISO > Time: 20-40 min > Output: Prioritized patch plan with SLA assignments, exception documentation, and risk acceptance artifacts

---

When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

Use this skill when managing a vulnerability remediation backlog, when assigning or validating patch SLAs, when a patch window needs to be scheduled against business constraints, when evaluating compensating controls as interim mitigation, or when processing risk acceptance or exception requests for deferred patches.

Do not use when: The task is initial CVE triage and severity scoring (use cve-triage), detection rule creation for unpatched systems (use detection-engineering), or SBOM-level dependency analysis (use sbom-analysis).

---

Context the Agent Needs

Before starting, collect or confirm:

• [ ] Vulnerability inventory: List of CVEs or vulnerability findings pending remediation, including scanner source (Qualys, Tenable, Rapid7, Snyk, Trivy)
• [ ] Current SLA assignments: Existing SLA tiers and deadlines for each finding, if previously triaged
• [ ] Asset inventory context: Business criticality, exposure (internet-facing, internal, air-gapped), owner, and environment (production, staging, dev) for affected systems
• [ ] Patch availability: Whether vendor patches, hotfixes, or workarounds exist for each CVE
• [ ] Change management constraints: Maintenance windows, freeze periods, change advisory board (CAB) schedules
• [ ] Compensating controls inventory: WAF rules, network segmentation, EDR policies, disabled features currently in place
• [ ] Compliance mandates: Applicable regulatory requirements (CISA BOD 22-01, PCI DSS 4.0 Requirement 6.3.3, HIPAA, FedRAMP)
• [ ] Historical EPSS data: EPSS score trends over 7/30/90 days if available (API: https://api.first.org/data/v1/epss)

If asset context is missing, assume internet-facing and business-critical, and flag assumptions in the output.

---

Process

Step 1: Inventory and Classify Pending Vulnerabilities

Organize all pending vulnerabilities into a structured inventory for prioritization.

1. Deduplicate findings across scanners (same CVE on same asset = single finding)
2. Enrich each finding with current EPSS score, CISA KEV status, and SSVC decision (reference cve-triage output if available)
3. Map each finding to an asset with business criticality and exposure context
4. Flag any findings past their current SLA deadline as SLA Breach

Framework mapping: Enterprise Vulnerability Management Policy

Vulnerability Inventory Entry:
- CVE ID:              [CVE-YYYY-NNNNN]
- Asset:               [hostname / IP / application name]
- Asset Criticality:   [Critical | High | Medium | Low]
- Exposure:            [Internet-facing | Internal | Air-gapped]
- Scanner Source:      [Scanner name and plugin/QID]
- CVSS 4.0 Base:       [0.0 - 10.0]
- EPSS Score:          [0.0 - 1.0] (as of [date])
- CISA KEV:            [Yes | No]
- SSVC Decision:       [Immediate | Out-of-Cycle | Scheduled | Defer]
- Patch Available:     [Yes (version) | No | Workaround Only]
- Current SLA:         [Tier and deadline]
- SLA Status:          [Within SLA | At Risk | Breached]

Step 2: Apply SLA Framework by Severity Tier

Assign or validate SLA tiers using the following matrix. SLA tiers are derived from SSVC 2.1 decision outcomes, cross-referenced with EPSS probability and CISA KEV status.

Framework mapping: SSVC 2.1 (CERT/CC), CISA BOD 22-01

Enterprise SLA Tier Matrix

| SLA Tier | Remediation Window | SSVC Decision | EPSS Threshold | KEV Status | CVSS 4.0 Range | |---|---|---|---|---|---| | P0 -- Emergency | 24 hours | Immediate | >= 0.7 OR active exploitation confirmed | Listed (ransomware: Known) | >= 9.0 Critical | | P1 -- Critical | 72 hours | Immediate or Out-of-Cycle | >= 0.4 | Listed | >= 7.0 High/Critical | | P2 -- High | 14 days | Out-of-Cycle | >= 0.1 | Not listed, PoC available | >= 7.0 High | | P3 -- Medium | 30 days | Scheduled | 0.01 - 0.1 | Not listed | 4.0 - 6.9 Medium | | P4 -- Low | 90 days | Scheduled or Defer | = 0.2 (absolute) or >= 200% (relative) in 30 days | Escalate one SLA tier immediately; flag for out-of-cycle patching | | Rising | EPSS increased by >= 0.05 (absolute) or >= 50% (relative) in 30 days | Monitor closely; prepare patch for next available window | | Stable | EPSS change = 0.05 in 30 days | May support risk acceptance for Scheduled/Defer tier findings |

EPSS Trend Analysis:
- CVE ID:              [CVE-YYYY-NNNNN]
- Current EPSS:        [score] ([percentile]th percentile)
- 7-day prior EPSS:    [score]
- 30-day prior EPSS:   [score]
- 90-day prior EPSS:   [score]
- Trend:               [Surging | Rising | Stable | Declining]
- Trend Impact:        [Escalate tier | Monitor | Maintain | Supports deferral]

Step 4: Compensating Controls Assessment

Evaluate whether compensating controls sufficiently mitigate the risk to justify extended remediation timelines or risk acceptance.

Framework mapping: NIST SP 800-53 Rev. 5 (CA-3, SI-2), PCI DSS 4.0 (Requirement 6.3.3, Appendix B Compensating Controls)

For each compensating control claimed, validate:

1. Control effectiveness: Does the control directly address the specific attack vector of the CVE?
2. Control coverage: Does the control protect all affected assets, or only a subset?
3. Control durability: Is the control persistent (e.g., network ACL) or ephemeral (e.g., manual process)?
4. Control verification: Can the control's effectiveness be independently verified or tested?
5. Residual risk: What risk remains after the compensating control is applied?

Compensating Control Evaluation Matrix

| Control Type | Example | Effectiveness Criteria | Max SLA Extension | |---|---|---|---| | Network segmentation | VLAN isolation, firewall rules blocking attack vector port/protocol | Prevents network path to vulnerable service; verified by scan | +14 days for P2/P3 | | WAF/IPS rule | Virtual patch rule targeting specific CVE exploit pattern | Rule tested against known PoC; bypass testing performed | +7 days for P1/P2 | | Feature/service disabled | Vulnerable component disabled or uninstalled | Component confirmed absent from runtime configuration | Reclassify to P4 or close | | EDR/XDR detection | Behavioral detection for exploitation indicators | Detection rule tested; alert routing confirmed | +7 days for P2 only | | Access restriction | MFA requirement, IP allowlisting, privilege reduction | Attack requires access that is now gated | +7 days for P2/P3 |

Compensating Control Assessment:
- CVE ID:              [CVE-YYYY-NNNNN]
- Control Type:        [Network | WAF | Feature Disabled | EDR | Access]
- Control Description: [Specific control details]
- Effectiveness:       [Full | Partial | Insufficient]
- Coverage:            [All affected assets | Subset ([N] of [M])]
- Verification:        [Tested on [date] | Unverified]
- Max SLA Extension:   [Days, per matrix above]
- Residual Risk:       [Description of remaining risk]

Step 5: Patch Window Scheduling

Map prioritized patches to available maintenance windows, respecting change management constraints.

Framework mapping: ITIL 4 Change Enablement, enterprise change management policy

1. Identify available maintenance windows within the SLA deadline for each finding
2. Group patches by system/application to minimize change windows
3. Assess patch dependency chains (e.g., OS patch required before application patch)
4. Evaluate rollback procedures and test coverage for each patch
5. Account for change freeze periods (fiscal close, peak traffic, regulatory audits)

Scheduling Priority Rules

| Priority | Scheduling Rule | |---|---| | P0 -- Emergency | Emergency change; does not require standard CAB approval. Execute within 24 hours. Post-implementation review within 48 hours. | | P1 -- Critical | Expedited change; CAB chair or delegate approval sufficient. Target next available window within 72 hours. | | P2 -- High | Standard change with elevated priority. Schedule in next regular maintenance window within 14 days. | | P3/P4 | Standard change. Bundle with regular patch cycle (monthly or quarterly). |

Patch Schedule Entry:
- CVE ID(s):           [List of CVEs addressed]
- Target System(s):    [Hostname(s) / application(s)]
- Patch Version:       [Vendor patch version or KB number]
- Scheduled Window:    [YYYY-MM-DD HH:MM - HH:MM TZ]
- Change Type:         [Emergency | Expedited | Standard]
- Change Ticket:       [Ticket ID]
- Rollback Plan:       [Description or "snapshot/restore"]
- SLA Deadline:        [YYYY-MM-DD]
- Days Remaining:      [N days]

Step 6: Risk Acceptance and Exception Management

For vulnerabilities that cannot be remediated within the SLA, document a formal risk acceptance or exception.

Framework mapping: NIST SP 800-39 (Risk Management), ISO 27005:2022 (Risk Treatment)

Risk Acceptance Criteria

A risk acceptance is only valid when ALL of the following conditions are met:

1. Business justification documented: A specific, verifiable reason why the patch cannot be applied within the SLA (system incompatibility, vendor dependency, business-critical freeze period)
2. Compensating controls in place: At least one compensating control assessed as "Full" or "Partial" effectiveness (see Step 4)
3. Residual risk quantified: The remaining risk after compensating controls is documented with potential business impact
4. Expiration date set: Every risk acceptance has a mandatory review/expiration date (maximum 90 days for P1-P2, 180 days for P3-P4)
5. Appropriate authority approval: Risk acceptance is signed by the appropriate level based on severity tier

Approval Authority Matrix

| SLA Tier | Approval Authority | Maximum Exception Duration | |---|---|---| | P0 -- Emergency | CISO or CIO (risk acceptance strongly discouraged) | 7 days; must be re-evaluated daily | | P1 -- Critical | CISO or designated security director | 30 days | | P2 -- High | Security manager or system owner (director-level) | 90 days | | P3 -- Medium | System owner (manager-level) | 180 days | | P4 -- Low | System owner | 365 days |

Exception Request Template

Risk Exception Request:
- Exception ID:        [EXC-YYYY-NNNN]
- Date Requested:      [YYYY-MM-DD]
- CVE ID(s):           [List]
- Affected System(s):  [List]
- Original SLA Tier:   [P0-P5]
- Original Deadline:   [YYYY-MM-DD]
- Requested Extension: [N days, new deadline YYYY-MM-DD]
- Business Justification: [Specific reason patch cannot be applied]
- Compensating Controls:  [Reference Step 4 assessment]
- Residual Risk:          [Impact description and likelihood]
- Review Date:            [YYYY-MM-DD, within maximum exception duration]
- Approver:               [Name, title]
- Approval Date:          [YYYY-MM-DD]
- Status:                 [Pending | Approved | Denied | Expired]

---

Findings Classification

Classify the overall patch posture into one of the following states:

| Classification | Definition | Criteria | |---|---|---| | Critical Backlog | Remediation backlog poses imminent organizational risk | Any P0/P1 findings past SLA OR >= 10 P2 findings past SLA | | Elevated Risk | Remediation backlog exceeds acceptable thresholds | Any P2 findings past SLA OR >= 20% of P3 findings past SLA | | On Track | Remediation is proceeding within SLA for all tiers | No findings past SLA; all P0/P1 addressed or in active remediation | | Healthy | Minimal outstanding findings; strong patch posture | No P0-P2 findings open; P3/P4 within SLA; exception rate < 5% |

---

Output Format

Produce a structured report with these exact sections:

## Patch Prioritization Report
**Date:** [YYYY-MM-DD]
**Skill:** patch-prioritization v1.0.0
**Frameworks:** SSVC 2.1, EPSS v3, CISA KEV
**Reviewer:** AI-assisted (human review required for P0/P1 actions and risk acceptances)

### Executive Summary
[3-5 sentences. State the total number of pending findings, breakdown by SLA tier,
count of SLA breaches, and overall patch posture classification. Highlight any P0/P1
findings requiring immediate action.]

### SLA Compliance Dashboard

| SLA Tier | Total Findings | Within SLA | At Risk (< 7 days) | Breached | Exception Granted |
|---|---|---|---|---|---|
| P0 - Emergency | [N] | [N] | [N] | [N] | [N] |
| P1 - Critical | [N] | [N] | [N] | [N] | [N] |
| P2 - High | [N] | [N] | [N] | [N] | [N] |
| P3 - Medium | [N] | [N] | [N] | [N] | [N] |
| P4 - Low | [N] | [N] | [N] | [N] | [N] |
| **Total** | **[N]** | **[N]** | **[N]** | **[N]** | **[N]** |

**Patch Posture:** [Critical Backlog | Elevated Risk | On Track | Healthy]

### EPSS Trend Alerts
[List any CVEs with Surging or Rising EPSS trends and recommended tier adjustments]

| CVE ID | Current EPSS | 30-day Prior | Trend | Recommended Action |
|---|---|---|---|---|
| [CVE-ID] | [score] | [score] | [Surging/Rising] | [Action] |

### Prioritized Patch Schedule

| Priority | CVE ID(s) | Target System | Patch | Scheduled Window | SLA Deadline | Status |
|---|---|---|---|---|---|---|
| P0 | [CVE-ID] | [system] | [version] | [date/time] | [date] | [Scheduled/Pending/Complete] |

### Compensating Controls in Effect
[List all active compensating controls with effectiveness ratings]

| CVE ID | Control Type | Effectiveness | SLA Extension | Expiration |
|---|---|---|---|---|
| [CVE-ID] | [type] | [Full/Partial] | [+N days] | [date] |

### Risk Exceptions
[List all active risk acceptance/exception records]

| Exception ID | CVE ID(s) | Original SLA | New Deadline | Approver | Status |
|---|---|---|---|---|---|
| [EXC-ID] | [CVE-IDs] | [tier] | [date] | [name] | [Approved/Pending] |

### Recommendations
1. [Highest-priority actionable recommendation]
2. [Second priority recommendation]
3. [Process improvement recommendation if applicable]

### References
- SSVC 2.1: https://certcc.github.io/SSVC/
- EPSS API: https://api.first.org/data/v1/epss
- CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Vendor advisories: [URLs as applicable]

---

Framework Reference

SSVC 2.1 (CERT/CC)

Stakeholder-Specific Vulnerability Categorization. Produces action-oriented decisions (Defer, Scheduled, Out-of-Cycle, Immediate) based on exploitation status, automatability, technical impact, and mission prevalence. Used as the primary driver for SLA tier assignment.

• Specification: https://certcc.github.io/SSVC/
• Repository: https://github.com/CERTCC/SSVC

EPSS v3 (FIRST.org)

Exploit Prediction Scoring System. Provides a daily-updated probability (0.0-1.0) that a CVE will be exploited in the wild within 30 days. Used for trend analysis and tier validation.

• Specification: https://www.first.org/epss/
• API: https://api.first.org/data/v1/epss
• Data: https://epss.cyentia.com/

CISA KEV (DHS/CISA)

Known Exploited Vulnerabilities catalog maintained by CISA. Contains CVEs with confirmed active exploitation. Federal agencies are bound by BOD 22-01 to remediate within CISA-specified deadlines.

• Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• BOD 22-01: https://www.cisa.gov/binding-operational-directive-22-01
• Machine-readable feed: https://www.cisa.gov/sites/default/files/feeds/knownexploitedvulnerabilities.json

---

Common Pitfalls

1. Treating CVSS as the sole prioritization signal. CVSS measures theoretical severity, not real-world exploitation likelihood. A CVSS 9.8 with EPSS 0.001 and no KEV listing may be lower priority than a CVSS 7.0 with EPSS 0.6 and active exploitation. Always use SSVC decision outcomes as the

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: UnitOneAI
• Source: UnitOneAI/SecuritySkills
• License: MIT
• Homepage: https://www.unitone.ai

Install and usage instructions live in the source repository linked above.