本文へ移動
cccskills
無料GitHub で公開

building-vulnerability-aging-and-sla-tracking

Implement a vulnerability aging dashboard and SLA tracking system that measures time-to-remediation against severity-based deadlines (e.g. 14 days critical, 30 days high, 60 days medium, 90 days low), with automated escalations and compliance metrics reporting. Use when designing SLA policies, building aging/remediation dashboards, or proving compliance with remediation timelines.

インストール方法を見る

含まれるファイル(8)

  • SKILL.md10.8 KB
  • assets/template.md1.1 KB
  • LICENSE11.0 KB
  • references/api-reference.md1.4 KB
  • references/standards.md1.3 KB
  • references/workflows.md1.8 KB
  • scripts/agent.py7.0 KB
  • scripts/process.py5.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Building Vulnerability Aging and SLA Tracking

Overview

With over 30,000 new vulnerabilities identified in 2024 (a 17% increase from the prior year), organizations must track how long vulnerabilities remain unpatched and whether remediation occurs within defined Service Level Agreements (SLAs). Vulnerability aging measures the time between discovery and remediation, while SLA tracking enforces severity-based deadlines. Industry benchmarks indicate standard SLAs of 14 days for critical, 30 days for high, 60 days for medium, and 90 days for low vulnerabilities, though more aggressive timelines (24-48 hours for actively exploited critical CVEs) are increasingly common. This skill covers designing SLA policies, building aging dashboards, implementing automated escalations, and generating compliance metrics.

When to Use

  • When deploying or configuring building vulnerability aging and sla tracking 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

  • Vulnerability management platform with historical scan data
  • Asset inventory with criticality ratings
  • ITSM/ticketing system for remediation tracking
  • Reporting platform (Splunk, Elastic, Power BI, Grafana)
  • Stakeholder agreement on SLA timelines and escalation procedures

Core Concepts

Standard Vulnerability SLA Framework

SeverityCVSS RangeStandard SLAAggressive SLACISA KEV SLA
Critical9.0-10.014 days48 hoursBOD 22-01 due date
High7.0-8.930 days7 days14 days
Medium4.0-6.960 days30 daysN/A
Low0.1-3.990 days60 daysN/A
Informational0.0Best effortBest effortN/A

Adaptive SLA Modifiers

FactorModifierRationale
Internet-facing asset-50% SLAHigher exposure risk
CISA KEV listedOverride to 48hActive exploitation confirmed
EPSS > 0.7-50% SLAHigh exploitation probability
Tier 1 (crown jewel) asset-25% SLAMaximum business impact
Compensating control in place+25% SLARisk partially mitigated
Vendor patch unavailableException with review dateCannot remediate yet

Key Performance Indicators (KPIs)

KPIFormulaTarget
Mean Time to Remediate (MTTR)Avg(remediation_date - discovery_date)< 30 days overall
SLA Compliance Rate(Vulns remediated within SLA / Total vulns) * 100>= 90%
Overdue Vulnerability CountCount where age > SLATrending downward
Vulnerability Aging DistributionCount by age bucket (0-14d, 15-30d, 31-60d, 60+d)Majority in 0-30d
Remediation VelocityVulns closed per weekTrending upward
Exception Rate(Exceptions / Total vulns) * 100< 5%

Workflow

Step 1: Define SLA Policy Document

Vulnerability Remediation SLA Policy v1.0

1. Scope: All information systems and applications
2. Severity Classification: Based on CVSS v4.0/v3.1 base score
3. SLA Timelines: See Standard SLA Framework table
4. Adaptive Modifiers: Applied based on asset context
5. Exception Process:
   - Must be documented with business justification
   - Requires compensating control description
   - Maximum extension: 90 days (one renewal)
   - CISO approval required for Critical/High exceptions
6. Escalation Path:
   - 50% SLA elapsed: Automated reminder to asset owner
   - 75% SLA elapsed: Escalation to manager
   - 100% SLA elapsed (overdue): CISO notification
   - 120% SLA elapsed: VP/CTO escalation
7. Metrics Reporting: Monthly to security committee

Step 2: Build the Aging Calculation Engine

import pandas as pd
from datetime import datetime, timedelta

class VulnerabilityAgingTracker:
    """Track vulnerability aging and SLA compliance."""

    SLA_DAYS = {
        "Critical": 14,
        "High": 30,
        "Medium": 60,
        "Low": 90,
    }

    def __init__(self, sla_overrides=None):
        if sla_overrides:
            self.SLA_DAYS.update(sla_overrides)

    def calculate_aging(self, vulns_df):
        """Calculate aging metrics for each vulnerability."""
        today = datetime.now()

        vulns_df["discovery_date"] = pd.to_datetime(vulns_df["discovery_date"])
        vulns_df["remediation_date"] = pd.to_datetime(
            vulns_df["remediation_date"], errors="coerce"
        )

        vulns_df["age_days"] = vulns_df.apply(
            lambda row: (row["remediation_date"] - row["discovery_date"]).days
            if pd.notna(row["remediation_date"])
            else (today - row["discovery_date"]).days,
            axis=1
        )

        vulns_df["sla_days"] = vulns_df["severity"].map(self.SLA_DAYS)
        vulns_df["sla_deadline"] = vulns_df["discovery_date"] + \
            pd.to_timedelta(vulns_df["sla_days"], unit="D")

        vulns_df["is_overdue"] = vulns_df.apply(
            lambda row: row["age_days"] > row["sla_days"]
            if pd.isna(row["remediation_date"]) else False,
            axis=1
        )

        vulns_df["sla_compliance"] = vulns_df.apply(
            lambda row: row["age_days"] <= row["sla_days"]
            if pd.notna(row["remediation_date"]) else None,
            axis=1
        )

        vulns_df["days_overdue"] = vulns_df.apply(
            lambda row: max(0, row["age_days"] - row["sla_days"])
            if row["is_overdue"] else 0,
            axis=1
        )

        vulns_df["sla_pct_elapsed"] = (
            vulns_df["age_days"] / vulns_df["sla_days"] * 100
        ).round(1)

        return vulns_df

    def generate_kpis(self, vulns_df):
        """Generate KPI summary from aging data."""
        open_vulns = vulns_df[vulns_df["remediation_date"].isna()]
        closed_vulns = vulns_df[vulns_df["remediation_date"].notna()]

        kpis = {
            "total_vulnerabilities": len(vulns_df),
            "open_vulnerabilities": len(open_vulns),
            "closed_vulnerabilities": len(closed_vulns),
            "overdue_count": open_vulns["is_overdue"].sum(),
            "mttr_days": closed_vulns["age_days"].mean() if len(closed_vulns) > 0 else 0,
            "sla_compliance_rate": (
                closed_vulns["sla_compliance"].mean() * 100
                if len(closed_vulns) > 0 else 0
            ),
        }

        kpis["overdue_by_severity"] = (
            open_vulns[open_vulns["is_overdue"]]
            .groupby("severity")
            .size()
            .to_dict()
        )

        return kpis

    def get_escalation_list(self, vulns_df):
        """Get vulnerabilities requiring escalation."""
        open_vulns = vulns_df[vulns_df["remediation_date"].isna()].copy()

        escalations = []
        for _, vuln in open_vulns.iterrows():
            pct = vuln["sla_pct_elapsed"]
            if pct >= 120:
                level = "VP/CTO Escalation"
            elif pct >= 100:
                level = "CISO Notification"
            elif pct >= 75:
                level = "Manager Escalation"
            elif pct >= 50:
                level = "Owner Reminder"
            else:
                continue

            escalations.append({
                "cve_id": vuln.get("cve_id", ""),
                "severity": vuln["severity"],
                "age_days": vuln["age_days"],
                "sla_days": vuln["sla_days"],
                "days_overdue": vuln["days_overdue"],
                "sla_pct": pct,
                "escalation_level": level,
                "asset": vuln.get("asset", ""),
                "owner": vuln.get("owner", ""),
            })

        return pd.DataFrame(escalations)

Step 3: Dashboard Visualization

# Grafana/Kibana query examples for vulnerability aging

# Age distribution histogram (Elasticsearch)
age_distribution_query = {
    "aggs": {
        "age_buckets": {
            "range": {
                "field": "age_days",
                "ranges": [
                    {"key": "0-7 days", "to": 8},
                    {"key": "8-14 days", "from": 8, "to": 15},
                    {"key": "15-30 days", "from": 15, "to": 31},
                    {"key": "31-60 days", "from": 31, "to": 61},
                    {"key": "61-90 days", "from": 61, "to": 91},
                    {"key": "90+ days", "from": 91},
                ]
            }
        }
    }
}

# SLA compliance trend (monthly)
sla_trend_query = {
    "aggs": {
        "monthly": {
            "date_histogram": {"field": "remediation_date", "interval": "month"},
            "aggs": {
                "within_sla": {
                    "filter": {"script": {
                        "source": "doc['age_days'].value <= doc['sla_days'].value"
                    }}
                }
            }
        }
    }
}

Best Practices

  1. Start with achievable SLA targets and tighten them as processes mature
  2. Adapt SLAs based on asset criticality and threat context, not just CVSS scores
  3. Automate escalation notifications to reduce manual tracking overhead
  4. Track MTTR trends month-over-month to demonstrate improvement
  5. Build exception workflows that require documented compensating controls
  6. Report SLA compliance to executive leadership monthly for accountability
  7. Include aging metrics in security committee and board-level reporting
  8. Integrate SLA tracking with ITSM ticketing for end-to-end remediation visibility

Common Pitfalls

  • Setting unrealistic SLA targets that teams cannot meet, causing SLA fatigue
  • Not adapting SLAs for asset criticality, treating all systems equally
  • Lacking exception processes, forcing teams to either ignore SLAs or request blanket waivers
  • Measuring only open vulnerability count without considering age and SLA compliance
  • Not tracking the SLA clock from discovery date (using report date instead)
  • Failing to re-baseline SLAs as team maturity improves

Related Skills

  • implementing-vulnerability-remediation-sla
  • building-executive-vulnerability-risk-report
  • implementing-security-metrics-and-kpis
  • performing-remediation-validation-scanning

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Extract and decrypt Windows DPAPI-protected secrets (Credential Manager, browser logins/cookies, Wi-Fi credentials, KeePass keys) online or offline using SharpDPAPI, SharpChrome, Mimikatz, or Impacket's dpapi.py, including domain-wide decryption via the DPAPI backup key. Use during authorized red-team credential-access engagements after gaining a foothold or when triaging DPAPI blobs pulled from a host.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Anthropic-Cybersecurity-Skills3.4万2026年8月31日 更新

Take over Active Directory accounts by writing attacker-controlled public keys to msDS-KeyCredentialLink (Shadow Credentials) with pyWhisker, Whisker, or Certipy, then authenticate via PKINIT to recover the target's NT hash without a password reset. Use when BloodHound shows GenericWrite/GenericAll/AddKeyCredentialLink over a target, as a stealthier alternative to ForceChangePassword, during authorized red-team engagements.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Anthropic-Cybersecurity-Skills3.4万2026年8月31日 更新

Prepare a defense-contractor environment for CMMC Level 2 certification: scope CUI and FCI, implement the 110 NIST SP 800-171 Rev 2 security requirements across 14 families, compute the SPRS score with the DoD Assessment Methodology, manage a compliant POA&M, and ready the organization for a C3PAO assessment. Use when an organization handles Controlled Unclassified Information (CUI) under a DoD contract, when a contract carries DFARS clause 252.204-7012/7019/7020/7021, when preparing for or responding to a CMMC assessment, when computing or improving an SPRS score, when building a System Security Plan or POA&M for 800-171, or when scoping which systems are in the CUI boundary. Keywords: CMMC, CMMC Level 2, NIST 800-171, SP 800-171 Rev 2, CUI, FCI, SPRS, DFARS 7012, C3PAO, POA&M, System Security Plan, DoD Assessment Methodology, 110 controls, defense industrial base, DIB, FedRAMP equivalency.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Anthropic-Cybersecurity-Skills3.4万2026年8月31日 更新

Create forensically sound bit-for-bit disk images with dd or dcfldd on a Linux forensic workstation, preserving evidence integrity through hash verification (MD5/SHA) during acquisition. Use when imaging a suspect drive, USB device, or memory card for investigation, preserving volatile disk evidence during incident response, or producing a verified copy for legal or law-enforcement proceedings before any destructive analysis.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Anthropic-Cybersecurity-Skills3.4万2026年8月31日 更新

Detect dangerous ACL misconfigurations in Active Directory using ldap3 to identify GenericAll, WriteDACL, and WriteOwner abuse paths

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Anthropic-Cybersecurity-Skills3.4万2026年8月31日 更新

Perform static analysis of Android APK malware using apktool for resource decompilation, jadx for Java source recovery, and androguard for manifest inspection, dangerous permission-combination detection, and identification of obfuscated code, dynamic code loading, and reflection-based API calls. Use to statically triage a suspicious APK without executing it or to build mobile malware detection rules.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Anthropic-Cybersecurity-Skills3.4万2026年8月31日 更新

mukul975 のスキルをすべて見る

このスキルの問題を報告する