Use when building automated alerting for vulnerability remediation SLA breaches with severity-based timelines, escalation workflows, and compliance reporting dashboards.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Use when building automated alerting for vulnerability remediation SLA breaches with severity-based timelines, escalation workflows, and compliance reporting dashboards.
Vulnerability remediation SLAs define maximum timeframes for addressing security findings based on severity. This skill covers building an automated alerting system that tracks remediation timelines, detects SLA breaches, sends escalation notifications, and generates compliance reports. Industry-standard SLA targets are: Critical (24-48 hours), High (15-30 days), Medium (60 days), Low (90 days).
When to Use
Trigger phrases:
"implementing vulnerability sla breach alerting"
"Build automated alerting for vulnerability remediation SLA breaches with severit"
When deploying or configuring implementing vulnerability sla breach alerting capabilities in your environment
When establishing security controls aligned to compliance requirements
When building or improving security architecture for this domain
When conducting security assessments that require this implementation
Prerequisites
Python 3.9+ with requests, pandas, jinja2, smtplib libraries
Vulnerability management platform with API access (DefectDojo, Qualys, Tenable)
SMTP server or webhook endpoint (Slack, Microsoft Teams, PagerDuty)
Database for SLA tracking (PostgreSQL or SQLite)
SLA Policy Definition
This section covers sla policy definition for implementing vulnerability sla breach alerting.
Ensure all prerequisites are met before proceeding
Follow the documented workflow steps in sequence
Record results and any anomalies encountered during this phase
Scope the task — define objectives, boundaries, and success criteria
Gather information — collect all necessary data and context before proceeding
Execute the core workflow — follow the domain-specific steps methodically
Validate results — verify outputs against expected outcomes or baselines
Document findings — record results, anomalies, and recommendations
Step 1: Database Schema for SLA Tracking
CREATE TABLE vulnerability_sla (
id SERIAL PRIMARY KEY,
cve_id VARCHAR(20) NOT NULL,
finding_id VARCHAR(100) NOT NULL,
asset_hostname VARCHAR(255),
severity VARCHAR(20) NOT NULL,
cvss_score DECIMAL(3,1),
discovered_at TIMESTAMPNOT NULL,
sla_deadline TIMESTAMPNOT NULL,
remediated_at TIMESTAMP,
status VARCHAR(20) DEFAULT'open',
owner_email VARCHAR(255),
escalation_level INTEGERDEFAULT0,
last_alert_sent TIMESTAMP,
created_at TIMESTAMPDEFAULTCURRENT_TIMESTAMP
);
CREATE INDEX idx_sla_status ON vulnerability_sla(status);
CREATE INDEX idx_sla_deadline ON vulnerability_sla(sla_deadline);
CREATE INDEX idx_sla_severity ON vulnerability_sla(severity);
Step 2: SLA Breach Detection Logic
from datetime import datetime, timedelta, timezone
import yaml
defload_sla_policy(policy_path="sla_policy.yaml"):
withopen(policy_path, "r") as f:
return yaml.safe_load(f)
defget_sla_tier(cvss_score, policy):
for tier_name, tier in policy["sla_tiers"].items():
if tier["cvss_min"] <= cvss_score <= tier["cvss_max"]:
return tier_name, tier
return"low", policy["sla_tiers"]["low"]
defcalculate_sla_deadline(discovered_at, cvss_score, policy):
tier_name, tier = get_sla_tier(cvss_score, policy)
deadline = discovered_at + timedelta(days=tier["remediation_days"])
return deadline, tier_name
defcheck_sla_status(discovered_at, sla_deadline, remediated_at=None):
now = datetime.now(timezone.utc)
if remediated_at:
if remediated_at <= sla_deadline:
return"remediated_within_sla"return"remediated_breach"if now > sla_deadline:
overdue_days = (now - sla_deadline).days
returnf"breached_{overdue_days}d_overdue"
remaining = sla_deadline - now
total_sla = sla_deadline - discovered_at
pct_elapsed = ((total_sla - remaining) / total_sla) * 100if pct_elapsed >= 80:
return"approaching_breach"return"within_sla"
This section covers sla metrics dashboard for implementing vulnerability sla breach alerting.
Ensure all prerequisites are met before proceeding
Follow the documented workflow steps in sequence
Record results and any anomalies encountered during this phase
Key Performance Indicators
defcalculate_sla_metrics(db_connection, period_start, period_end):
metrics = {
"total_findings": 0,
"remediated_within_sla": 0,
"sla_breach_count": 0,
"mean_time_to_remediate": {},
"sla_compliance_rate": 0.0,
"current_overdue": 0,
}
# Query findings in period grouped by severity
query = """
SELECT severity, COUNT(*) as total,
SUM(CASE WHEN remediated_at <= sla_deadline THEN 1 ELSE 0 END) as within_sla,
AVG(EXTRACT(EPOCH FROM (COALESCE(remediated_at, NOW()) - discovered_at))/86400) as avg_days
FROM vulnerability_sla
WHERE discovered_at BETWEEN %s AND %s
GROUP BY severity
"""return metrics
When NOT to Use
You need to test the implementation (use performing-* skills)
Task is about configuring existing tools (use configuring-* skills)
You need to analyze security events (use analyzing-* skills)
Task is about building detection rules (use building-* skills)
