阅读中文版本

Security Patch SLA Tracking Workflow

Track vulnerability patches against severity-based SLAs so high-risk findings are remediated within the agreed window.

Overview

Ensure vulnerabilities are patched within defined SLAs by severity.

This workflow is reusable across teams and environments; adapt the commands to your tooling while keeping the sequence and checkpoints intact.

Environment and prerequisites

• A vulnerability tracker
• Severity-based SLA policy
• Asset ownership data

Procedure

1. Ingest findings with severity

Import vulnerability findings and assign asset owners.

Expected state: Every finding has a severity and owner.

2. Apply SLA deadlines

Compute a remediation deadline from severity per policy.

Expected state: Each finding has a due date.

3. Report against SLA

Track open findings by SLA breach risk and escalate impending breaches.

Expected state: At-risk patches get attention before breach.

4. Verify remediation

Confirm the fix actually removes the finding rather than hiding it.

Expected state: Closed findings are verified remediated.

# compute an SLA due date by severity
python sla.py --severity high --found 2026-10-01

Verification

Confirm closure records show verified remediation and that breach rates trend down.

Decision points

Patch everything or risk-prioritize?

• Prioritize by severity and exposure
• Patch all equally

Recommendation: Prioritize by severity and exposure where patch capacity is limited.

Auto-close on scanner disappearance?

• Verify remediation
• Auto-close

Recommendation: Verify remediation; scanner disappearance can mean the asset moved.

Common failures

• No SLA means high-risk findings linger.
• Auto-close without verification hides real risk.
• Unknown owners stall remediation.