[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AE0XWSSSVJ8JT3FR6R9Q70":3,"skill-same:01M6AE0XWSSSVJ8JT3FR6R9Q70":128},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":70,"ownerHtmlUrl":71,"ownerBlogUrl":72,"ownerDescription":73,"updatedAt":74,"install":75,"resources":88},"01M6AE0XWSSSVJ8JT3FR6R9Q70","building-vulnerability-aging-and-sla-tracking",null,"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\u002Fremediation dashboards, or proving compliance with remediation timelines.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"sla","building vulnerability aging and sla tracking","cybersecurity","implement","dashboard","report","metrics","reporting","compliance","severity","kpi","vulnerability-management","sla-tracking","remediation-metrics","aging-report","risk-management","2026-11-10 10:12:30",false,"---\nname: building-vulnerability-aging-and-sla-tracking\ndescription: 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\u002Fremediation dashboards, or proving compliance with remediation timelines.\ndomain: cybersecurity\nsubdomain: vulnerability-management\ntags:\n- vulnerability-management\n- sla-tracking\n- remediation-metrics\n- aging-report\n- kpi\n- compliance\n- risk-management\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- ID.RA-01\n- ID.RA-02\n- ID.IM-02\n- ID.RA-06\nmitre_attack:\n- T1190\n- T1203\n- T1068\n---\n# Building Vulnerability Aging and SLA Tracking\n\n## Overview\nWith 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.\n\n\n## When to Use\n\n- When deploying or configuring building vulnerability aging and sla tracking capabilities in your environment\n- When establishing security controls aligned to compliance requirements\n- When building or improving security architecture for this domain\n- When conducting security assessments that require this implementation\n\n## Prerequisites\n- Vulnerability management platform with historical scan data\n- Asset inventory with criticality ratings\n- ITSM\u002Fticketing system for remediation tracking\n- Reporting platform (Splunk, Elastic, Power BI, Grafana)\n- Stakeholder agreement on SLA timelines and escalation procedures\n\n## Core Concepts\n\n### Standard Vulnerability SLA Framework\n\n| Severity | CVSS Range | Standard SLA | Aggressive SLA | CISA KEV SLA |\n|----------|-----------|-------------|----------------|-------------|\n| Critical | 9.0-10.0 | 14 days | 48 hours | BOD 22-01 due date |\n| High | 7.0-8.9 | 30 days | 7 days | 14 days |\n| Medium | 4.0-6.9 | 60 days | 30 days | N\u002FA |\n| Low | 0.1-3.9 | 90 days | 60 days | N\u002FA |\n| Informational | 0.0 | Best effort | Best effort | N\u002FA |\n\n### Adaptive SLA Modifiers\n\n| Factor | Modifier | Rationale |\n|--------|----------|-----------|\n| Internet-facing asset | -50% SLA | Higher exposure risk |\n| CISA KEV listed | Override to 48h | Active exploitation confirmed |\n| EPSS > 0.7 | -50% SLA | High exploitation probability |\n| Tier 1 (crown jewel) asset | -25% SLA | Maximum business impact |\n| Compensating control in place | +25% SLA | Risk partially mitigated |\n| Vendor patch unavailable | Exception with review date | Cannot remediate yet |\n\n### Key Performance Indicators (KPIs)\n\n| KPI | Formula | Target |\n|-----|---------|--------|\n| Mean Time to Remediate (MTTR) | Avg(remediation_date - discovery_date) | \u003C 30 days overall |\n| SLA Compliance Rate | (Vulns remediated within SLA \u002F Total vulns) * 100 | >= 90% |\n| Overdue Vulnerability Count | Count where age > SLA | Trending downward |\n| Vulnerability Aging Distribution | Count by age bucket (0-14d, 15-30d, 31-60d, 60+d) | Majority in 0-30d |\n| Remediation Velocity | Vulns closed per week | Trending upward |\n| Exception Rate | (Exceptions \u002F Total vulns) * 100 | \u003C 5% |\n\n## Workflow\n\n### Step 1: Define SLA Policy Document\n\n```\nVulnerability Remediation SLA Policy v1.0\n\n1. Scope: All information systems and applications\n2. Severity Classification: Based on CVSS v4.0\u002Fv3.1 base score\n3. SLA Timelines: See Standard SLA Framework table\n4. Adaptive Modifiers: Applied based on asset context\n5. Exception Process:\n   - Must be documented with business justification\n   - Requires compensating control description\n   - Maximum extension: 90 days (one renewal)\n   - CISO approval required for Critical\u002FHigh exceptions\n6. Escalation Path:\n   - 50% SLA elapsed: Automated reminder to asset owner\n   - 75% SLA elapsed: Escalation to manager\n   - 100% SLA elapsed (overdue): CISO notification\n   - 120% SLA elapsed: VP\u002FCTO escalation\n7. Metrics Reporting: Monthly to security committee\n```\n\n### Step 2: Build the Aging Calculation Engine\n\n```python\nimport pandas as pd\nfrom datetime import datetime, timedelta\n\nclass VulnerabilityAgingTracker:\n    \"\"\"Track vulnerability aging and SLA compliance.\"\"\"\n\n    SLA_DAYS = {\n        \"Critical\": 14,\n        \"High\": 30,\n        \"Medium\": 60,\n        \"Low\": 90,\n    }\n\n    def __init__(self, sla_overrides=None):\n        if sla_overrides:\n            self.SLA_DAYS.update(sla_overrides)\n\n    def calculate_aging(self, vulns_df):\n        \"\"\"Calculate aging metrics for each vulnerability.\"\"\"\n        today = datetime.now()\n\n        vulns_df[\"discovery_date\"] = pd.to_datetime(vulns_df[\"discovery_date\"])\n        vulns_df[\"remediation_date\"] = pd.to_datetime(\n            vulns_df[\"remediation_date\"], errors=\"coerce\"\n        )\n\n        vulns_df[\"age_days\"] = vulns_df.apply(\n            lambda row: (row[\"remediation_date\"] - row[\"discovery_date\"]).days\n            if pd.notna(row[\"remediation_date\"])\n            else (today - row[\"discovery_date\"]).days,\n            axis=1\n        )\n\n        vulns_df[\"sla_days\"] = vulns_df[\"severity\"].map(self.SLA_DAYS)\n        vulns_df[\"sla_deadline\"] = vulns_df[\"discovery_date\"] + \\\n            pd.to_timedelta(vulns_df[\"sla_days\"], unit=\"D\")\n\n        vulns_df[\"is_overdue\"] = vulns_df.apply(\n            lambda row: row[\"age_days\"] > row[\"sla_days\"]\n            if pd.isna(row[\"remediation_date\"]) else False,\n            axis=1\n        )\n\n        vulns_df[\"sla_compliance\"] = vulns_df.apply(\n            lambda row: row[\"age_days\"] \u003C= row[\"sla_days\"]\n            if pd.notna(row[\"remediation_date\"]) else None,\n            axis=1\n        )\n\n        vulns_df[\"days_overdue\"] = vulns_df.apply(\n            lambda row: max(0, row[\"age_days\"] - row[\"sla_days\"])\n            if row[\"is_overdue\"] else 0,\n            axis=1\n        )\n\n        vulns_df[\"sla_pct_elapsed\"] = (\n            vulns_df[\"age_days\"] \u002F vulns_df[\"sla_days\"] * 100\n        ).round(1)\n\n        return vulns_df\n\n    def generate_kpis(self, vulns_df):\n        \"\"\"Generate KPI summary from aging data.\"\"\"\n        open_vulns = vulns_df[vulns_df[\"remediation_date\"].isna()]\n        closed_vulns = vulns_df[vulns_df[\"remediation_date\"].notna()]\n\n        kpis = {\n            \"total_vulnerabilities\": len(vulns_df),\n            \"open_vulnerabilities\": len(open_vulns),\n            \"closed_vulnerabilities\": len(closed_vulns),\n            \"overdue_count\": open_vulns[\"is_overdue\"].sum(),\n            \"mttr_days\": closed_vulns[\"age_days\"].mean() if len(closed_vulns) > 0 else 0,\n            \"sla_compliance_rate\": (\n                closed_vulns[\"sla_compliance\"].mean() * 100\n                if len(closed_vulns) > 0 else 0\n            ),\n        }\n\n        kpis[\"overdue_by_severity\"] = (\n            open_vulns[open_vulns[\"is_overdue\"]]\n            .groupby(\"severity\")\n            .size()\n            .to_dict()\n        )\n\n        return kpis\n\n    def get_escalation_list(self, vulns_df):\n        \"\"\"Get vulnerabilities requiring escalation.\"\"\"\n        open_vulns = vulns_df[vulns_df[\"remediation_date\"].isna()].copy()\n\n        escalations = []\n        for _, vuln in open_vulns.iterrows():\n            pct = vuln[\"sla_pct_elapsed\"]\n            if pct >= 120:\n                level = \"VP\u002FCTO Escalation\"\n            elif pct >= 100:\n                level = \"CISO Notification\"\n            elif pct >= 75:\n                level = \"Manager Escalation\"\n            elif pct >= 50:\n                level = \"Owner Reminder\"\n            else:\n                continue\n\n            escalations.append({\n                \"cve_id\": vuln.get(\"cve_id\", \"\"),\n                \"severity\": vuln[\"severity\"],\n                \"age_days\": vuln[\"age_days\"],\n                \"sla_days\": vuln[\"sla_days\"],\n                \"days_overdue\": vuln[\"days_overdue\"],\n                \"sla_pct\": pct,\n                \"escalation_level\": level,\n                \"asset\": vuln.get(\"asset\", \"\"),\n                \"owner\": vuln.get(\"owner\", \"\"),\n            })\n\n        return pd.DataFrame(escalations)\n```\n\n### Step 3: Dashboard Visualization\n\n```python\n# Grafana\u002FKibana query examples for vulnerability aging\n\n# Age distribution histogram (Elasticsearch)\nage_distribution_query = {\n    \"aggs\": {\n        \"age_buckets\": {\n            \"range\": {\n                \"field\": \"age_days\",\n                \"ranges\": [\n                    {\"key\": \"0-7 days\", \"to\": 8},\n                    {\"key\": \"8-14 days\", \"from\": 8, \"to\": 15},\n                    {\"key\": \"15-30 days\", \"from\": 15, \"to\": 31},\n                    {\"key\": \"31-60 days\", \"from\": 31, \"to\": 61},\n                    {\"key\": \"61-90 days\", \"from\": 61, \"to\": 91},\n                    {\"key\": \"90+ days\", \"from\": 91},\n                ]\n            }\n        }\n    }\n}\n\n# SLA compliance trend (monthly)\nsla_trend_query = {\n    \"aggs\": {\n        \"monthly\": {\n            \"date_histogram\": {\"field\": \"remediation_date\", \"interval\": \"month\"},\n            \"aggs\": {\n                \"within_sla\": {\n                    \"filter\": {\"script\": {\n                        \"source\": \"doc['age_days'].value \u003C= doc['sla_days'].value\"\n                    }}\n                }\n            }\n        }\n    }\n}\n```\n\n## Best Practices\n1. Start with achievable SLA targets and tighten them as processes mature\n2. Adapt SLAs based on asset criticality and threat context, not just CVSS scores\n3. Automate escalation notifications to reduce manual tracking overhead\n4. Track MTTR trends month-over-month to demonstrate improvement\n5. Build exception workflows that require documented compensating controls\n6. Report SLA compliance to executive leadership monthly for accountability\n7. Include aging metrics in security committee and board-level reporting\n8. Integrate SLA tracking with ITSM ticketing for end-to-end remediation visibility\n\n## Common Pitfalls\n- Setting unrealistic SLA targets that teams cannot meet, causing SLA fatigue\n- Not adapting SLAs for asset criticality, treating all systems equally\n- Lacking exception processes, forcing teams to either ignore SLAs or request blanket waivers\n- Measuring only open vulnerability count without considering age and SLA compliance\n- Not tracking the SLA clock from discovery date (using report date instead)\n- Failing to re-baseline SLAs as team maturity improves\n\n## Related Skills\n- implementing-vulnerability-remediation-sla\n- building-executive-vulnerability-risk-report\n- implementing-security-metrics-and-kpis\n- performing-remediation-validation-scanning\n","# Building Vulnerability Aging and SLA Tracking\n\n## Overview\nWith 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.\n\n\n## When to Use\n\n- When deploying or configuring building vulnerability aging and sla tracking capabilities in your environment\n- When establishing security controls aligned to compliance requirements\n- When building or improving security architecture for this domain\n- When conducting security assessments that require this implementation\n\n## Prerequisites\n- Vulnerability management platform with historical scan data\n- Asset inventory with criticality ratings\n- ITSM\u002Fticketing system for remediation tracking\n- Reporting platform (Splunk, Elastic, Power BI, Grafana)\n- Stakeholder agreement on SLA timelines and escalation procedures\n\n## Core Concepts\n\n### Standard Vulnerability SLA Framework\n\n| Severity | CVSS Range | Standard SLA | Aggressive SLA | CISA KEV SLA |\n|----------|-----------|-------------|----------------|-------------|\n| Critical | 9.0-10.0 | 14 days | 48 hours | BOD 22-01 due date |\n| High | 7.0-8.9 | 30 days | 7 days | 14 days |\n| Medium | 4.0-6.9 | 60 days | 30 days | N\u002FA |\n| Low | 0.1-3.9 | 90 days | 60 days | N\u002FA |\n| Informational | 0.0 | Best effort | Best effort | N\u002FA |\n\n### Adaptive SLA Modifiers\n\n| Factor | Modifier | Rationale |\n|--------|----------|-----------|\n| Internet-facing asset | -50% SLA | Higher exposure risk |\n| CISA KEV listed | Override to 48h | Active exploitation confirmed |\n| EPSS > 0.7 | -50% SLA | High exploitation probability |\n| Tier 1 (crown jewel) asset | -25% SLA | Maximum business impact |\n| Compensating control in place | +25% SLA | Risk partially mitigated |\n| Vendor patch unavailable | Exception with review date | Cannot remediate yet |\n\n### Key Performance Indicators (KPIs)\n\n| KPI | Formula | Target |\n|-----|---------|--------|\n| Mean Time to Remediate (MTTR) | Avg(remediation_date - discovery_date) | \u003C 30 days overall |\n| SLA Compliance Rate | (Vulns remediated within SLA \u002F Total vulns) * 100 | >= 90% |\n| Overdue Vulnerability Count | Count where age > SLA | Trending downward |\n| Vulnerability Aging Distribution | Count by age bucket (0-14d, 15-30d, 31-60d, 60+d) | Majority in 0-30d |\n| Remediation Velocity | Vulns closed per week | Trending upward |\n| Exception Rate | (Exceptions \u002F Total vulns) * 100 | \u003C 5% |\n\n## Workflow\n\n### Step 1: Define SLA Policy Document\n\n```\nVulnerability Remediation SLA Policy v1.0\n\n1. Scope: All information systems and applications\n2. Severity Classification: Based on CVSS v4.0\u002Fv3.1 base score\n3. SLA Timelines: See Standard SLA Framework table\n4. Adaptive Modifiers: Applied based on asset context\n5. Exception Process:\n   - Must be documented with business justification\n   - Requires compensating control description\n   - Maximum extension: 90 days (one renewal)\n   - CISO approval required for Critical\u002FHigh exceptions\n6. Escalation Path:\n   - 50% SLA elapsed: Automated reminder to asset owner\n   - 75% SLA elapsed: Escalation to manager\n   - 100% SLA elapsed (overdue): CISO notification\n   - 120% SLA elapsed: VP\u002FCTO escalation\n7. Metrics Reporting: Monthly to security committee\n```\n\n### Step 2: Build the Aging Calculation Engine\n\n```python\nimport pandas as pd\nfrom datetime import datetime, timedelta\n\nclass VulnerabilityAgingTracker:\n    \"\"\"Track vulnerability aging and SLA compliance.\"\"\"\n\n    SLA_DAYS = {\n        \"Critical\": 14,\n        \"High\": 30,\n        \"Medium\": 60,\n        \"Low\": 90,\n    }\n\n    def __init__(self, sla_overrides=None):\n        if sla_overrides:\n            self.SLA_DAYS.update(sla_overrides)\n\n    def calculate_aging(self, vulns_df):\n        \"\"\"Calculate aging metrics for each vulnerability.\"\"\"\n        today = datetime.now()\n\n        vulns_df[\"discovery_date\"] = pd.to_datetime(vulns_df[\"discovery_date\"])\n        vulns_df[\"remediation_date\"] = pd.to_datetime(\n            vulns_df[\"remediation_date\"], errors=\"coerce\"\n        )\n\n        vulns_df[\"age_days\"] = vulns_df.apply(\n            lambda row: (row[\"remediation_date\"] - row[\"discovery_date\"]).days\n            if pd.notna(row[\"remediation_date\"])\n            else (today - row[\"discovery_date\"]).days,\n            axis=1\n        )\n\n        vulns_df[\"sla_days\"] = vulns_df[\"severity\"].map(self.SLA_DAYS)\n        vulns_df[\"sla_deadline\"] = vulns_df[\"discovery_date\"] + \\\n            pd.to_timedelta(vulns_df[\"sla_days\"], unit=\"D\")\n\n        vulns_df[\"is_overdue\"] = vulns_df.apply(\n            lambda row: row[\"age_days\"] > row[\"sla_days\"]\n            if pd.isna(row[\"remediation_date\"]) else False,\n            axis=1\n        )\n\n        vulns_df[\"sla_compliance\"] = vulns_df.apply(\n            lambda row: row[\"age_days\"] \u003C= row[\"sla_days\"]\n            if pd.notna(row[\"remediation_date\"]) else None,\n            axis=1\n        )\n\n        vulns_df[\"days_overdue\"] = vulns_df.apply(\n            lambda row: max(0, row[\"age_days\"] - row[\"sla_days\"])\n            if row[\"is_overdue\"] else 0,\n            axis=1\n        )\n\n        vulns_df[\"sla_pct_elapsed\"] = (\n            vulns_df[\"age_days\"] \u002F vulns_df[\"sla_days\"] * 100\n        ).round(1)\n\n        return vulns_df\n\n    def generate_kpis(self, vulns_df):\n        \"\"\"Generate KPI summary from aging data.\"\"\"\n        open_vulns = vulns_df[vulns_df[\"remediation_date\"].isna()]\n        closed_vulns = vulns_df[vulns_df[\"remediation_date\"].notna()]\n\n        kpis = {\n            \"total_vulnerabilities\": len(vulns_df),\n            \"open_vulnerabilities\": len(open_vulns),\n            \"closed_vulnerabilities\": len(closed_vulns),\n            \"overdue_count\": open_vulns[\"is_overdue\"].sum(),\n            \"mttr_days\": closed_vulns[\"age_days\"].mean() if len(closed_vulns) > 0 else 0,\n            \"sla_compliance_rate\": (\n                closed_vulns[\"sla_compliance\"].mean() * 100\n                if len(closed_vulns) > 0 else 0\n            ),\n        }\n\n        kpis[\"overdue_by_severity\"] = (\n            open_vulns[open_vulns[\"is_overdue\"]]\n            .groupby(\"severity\")\n            .size()\n            .to_dict()\n        )\n\n        return kpis\n\n    def get_escalation_list(self, vulns_df):\n        \"\"\"Get vulnerabilities requiring escalation.\"\"\"\n        open_vulns = vulns_df[vulns_df[\"remediation_date\"].isna()].copy()\n\n        escalations = []\n        for _, vuln in open_vulns.iterrows():\n            pct = vuln[\"sla_pct_elapsed\"]\n            if pct >= 120:\n                level = \"VP\u002FCTO Escalation\"\n            elif pct >= 100:\n                level = \"CISO Notification\"\n            elif pct >= 75:\n                level = \"Manager Escalation\"\n            elif pct >= 50:\n                level = \"Owner Reminder\"\n            else:\n                continue\n\n            escalations.append({\n                \"cve_id\": vuln.get(\"cve_id\", \"\"),\n                \"severity\": vuln[\"severity\"],\n                \"age_days\": vuln[\"age_days\"],\n                \"sla_days\": vuln[\"sla_days\"],\n                \"days_overdue\": vuln[\"days_overdue\"],\n                \"sla_pct\": pct,\n                \"escalation_level\": level,\n                \"asset\": vuln.get(\"asset\", \"\"),\n                \"owner\": vuln.get(\"owner\", \"\"),\n            })\n\n        return pd.DataFrame(escalations)\n```\n\n### Step 3: Dashboard Visualization\n\n```python\n# Grafana\u002FKibana query examples for vulnerability aging\n\n# Age distribution histogram (Elasticsearch)\nage_distribution_query = {\n    \"aggs\": {\n        \"age_buckets\": {\n            \"range\": {\n                \"field\": \"age_days\",\n                \"ranges\": [\n                    {\"key\": \"0-7 days\", \"to\": 8},\n                    {\"key\": \"8-14 days\", \"from\": 8, \"to\": 15},\n                    {\"key\": \"15-30 days\", \"from\": 15, \"to\": 31},\n                    {\"key\": \"31-60 days\", \"from\": 31, \"to\": 61},\n                    {\"key\": \"61-90 days\", \"from\": 61, \"to\": 91},\n                    {\"key\": \"90+ days\", \"from\": 91},\n                ]\n            }\n        }\n    }\n}\n\n# SLA compliance trend (monthly)\nsla_trend_query = {\n    \"aggs\": {\n        \"monthly\": {\n            \"date_histogram\": {\"field\": \"remediation_date\", \"interval\": \"month\"},\n            \"aggs\": {\n                \"within_sla\": {\n                    \"filter\": {\"script\": {\n                        \"source\": \"doc['age_days'].value \u003C= doc['sla_days'].value\"\n                    }}\n                }\n            }\n        }\n    }\n}\n```\n\n## Best Practices\n1. Start with achievable SLA targets and tighten them as processes mature\n2. Adapt SLAs based on asset criticality and threat context, not just CVSS scores\n3. Automate escalation notifications to reduce manual tracking overhead\n4. Track MTTR trends month-over-month to demonstrate improvement\n5. Build exception workflows that require documented compensating controls\n6. Report SLA compliance to executive leadership monthly for accountability\n7. Include aging metrics in security committee and board-level reporting\n8. Integrate SLA tracking with ITSM ticketing for end-to-end remediation visibility\n\n## Common Pitfalls\n- Setting unrealistic SLA targets that teams cannot meet, causing SLA fatigue\n- Not adapting SLAs for asset criticality, treating all systems equally\n- Lacking exception processes, forcing teams to either ignore SLAs or request blanket waivers\n- Measuring only open vulnerability count without considering age and SLA compliance\n- Not tracking the SLA clock from discovery date (using report date instead)\n- Failing to re-baseline SLAs as team maturity improves\n\n## Related Skills\n- implementing-vulnerability-remediation-sla\n- building-executive-vulnerability-risk-report\n- implementing-security-metrics-and-kpis\n- performing-remediation-validation-scanning\n",{"name":5,"tags":53,"author":54,"domain":34,"license":15,"version":55,"nist_csf":56,"subdomain":43,"description":7,"mitre_attack":61},[43,44,45,46,42,40,47],"mahipal","1.0",[57,58,59,60],"ID.RA-01","ID.RA-02","ID.IM-02","ID.RA-06",[62,63,64],"T1190","T1203","T1068","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fbuilding-vulnerability-aging-and-sla-tracking",4414,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":76,"prompt":86,"zipAvailable":87},[77,80,83],{"tool":78,"command":79},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill building-vulnerability-aging-and-sla-tracking",{"tool":81,"command":82},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill building-vulnerability-aging-and-sla-tracking",{"tool":84,"command":85},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill building-vulnerability-aging-and-sla-tracking","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002FSKILL.md",true,[89,95,101,106,110,114,118,124],{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"agents\u002Fopenai.yaml","REFERENCE","参考文档",139,"https:\u002F\u002Fgithub.com\u002FVortex375\u002Fseraph\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimplement\u002Fagents\u002Fopenai.yaml",{"path":96,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"assets\u002Ftemplate.md","ASSET","资产文件",1158,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002Fassets\u002Ftemplate.md",{"path":102,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002FLICENSE",{"path":107,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fapi-reference.md",1400,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002Freferences\u002Fapi-reference.md",{"path":111,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fstandards.md",1379,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002Freferences\u002Fstandards.md",{"path":115,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":116,"sourceHtmlUrl":117},"references\u002Fworkflows.md",1821,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002Freferences\u002Fworkflows.md",{"path":119,"resourceType":120,"resourceTypeDesc":121,"sizeBytes":122,"sourceHtmlUrl":123},"scripts\u002Fagent.py","SCRIPT","脚本",7133,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002Fscripts\u002Fagent.py",{"path":125,"resourceType":120,"resourceTypeDesc":121,"sizeBytes":126,"sourceHtmlUrl":127},"scripts\u002Fprocess.py",5810,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-vulnerability-aging-and-sla-tracking\u002Fscripts\u002Fprocess.py",[129,156,180,207,233,258],{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":136,"publishedAt":48},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[135],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[137,138,139,140,141,34,142,143,144,145,146,147,148,149,150,151,152,153,154,155],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","pr","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":163,"publishedAt":48},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[162],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[164,152,165,166,141,167,34,144,168,169,170,171,172,173,174,175,176,177,178,179],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":190,"publishedAt":48},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[186,189],{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[174,191,192,193,194,34,195,196,168,40,197,198,199,200,201,202,203,204,205,206],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":214,"publishedAt":48},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[213],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[215,216,217,34,218,219,220,221,222,223,224,225,226,227,228,229,171,230,231,232],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":234,"name":235,"nameZh":6,"description":236,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":237,"categories":238,"keywords":240,"publishedAt":48},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[239],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[241,242,243,34,244,245,246,43,47,247,248,249,250,251,252,253,254,255,256,257],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":259,"name":260,"nameZh":6,"description":261,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":262,"categories":263,"keywords":265,"publishedAt":48},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[264],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[141,266,34,267,268,269,270,271,272,41,273,202,274,203,275,276,277,278,279,280],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]