Anthropic-Cybersecurity-Skills 实战指南：构建漏洞老化（Vulnerability Aging）与 SLA 跟踪体系的行业标准、基准与落地实现

Anthropic-Cybersecurity-Skills 实战指南：构建漏洞老化（Vulnerability Aging）与 SLA 跟踪体系的行业标准、基准与落地实现

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读

本文以 Anthropic-Cybersecurity-Skills 仓库中skills/building-vulnerability-aging-and-sla-tracking技能包为核心，系统讲解如何构建一套漏洞老化与 SLA 跟踪体系。文章从 NIST、CIS、PCI DSS、BOD 22-01、ISO 27001 等监管与行业标准出发，结合仓库内提供的 SLA 基准表、2024 年漏洞统计、策略模板、Python 计算引擎与报告模板，覆盖「策略设计 → 老化计算 → 升级告警 → 可视化报表」的完整落地链路。读完本文，你将能够：定义按严重级别区分的修复 SLA、实现漏洞老化计算引擎与 KPI 生成、搭建升级阶梯与月度合规报告，并为审计提供可追溯的指标依据。

一、为什么需要漏洞老化与 SLA 跟踪

2024 年公开披露的新 CVE 数量超过 30,000 个，同比增幅达 17%（数据来源：references/standards.md）。在如此大的漏洞吞吐量下，仅仅统计"开放漏洞数量"远远不够——安全团队真正需要回答的问题是：每个漏洞在被发现后多久得到修复？是否在其严重级别对应的服务级别协议（SLA）期限内完成修复？

漏洞老化（Vulnerability Aging）衡量从发现到修复的时间跨度，SLA 跟踪则依据严重级别强制执行修复期限。行业基准显示，通用 SLA 通常设定为：Critical 14 天、High 30 天、Medium 60 天、Low 90 天；而针对被积极利用的关键 CVE，24～48 小时的激进时限也日趋常见。与此同时，全行业平均修复时间（MTTR）约为 60 天，而表现最好的组织可将关键漏洞的 MTTR 控制在 15 天以内——这正是 SLA 制度拉开差距的地方。

该技能包在 SKILL.md 的元数据中将其映射至 NIST CSF 2.0 的ID.RA-01、ID.RA-02、ID.RA-06、ID.IM-02及 MITRE ATT&CK 的T1190、T1203、T1068，说明该能力同时服务于风险评估、响应度量与合规证明三项目标。

二、行业标准全景（核心基准）

references/standards.md列出了构建 SLA 制度时应当对齐的核心行业标准：

从源码结构看，该技能包在设计上刻意与这些标准对齐：标准 SLA 框架中的 CISA KEV 列直接对应 BOD 22-01 的期限覆盖逻辑，而异常流程、升级路径与月度指标上报等设计则回应了 PCI DSS 与 ISO 27001 对"可证明的修复流程"的要求。

行业 SLA 基准表

说明：standards.md 中亦收录了 Tenable Cyber Exposure 研究、Nucleus Security SLA 指南、Phoenix Security SLA 框架等外部基准资料（原文为外链，此处不再展开 URL），用于在设定目标前横向对标同行业水平。

2024 年漏洞统计（设定目标的依据）

• 新增 CVE 总量：30,000+
• 同比增幅：17%
• 全行业平均 MTTR：约 60 天
• 顶级组织关键漏洞 MTTR：< 15 天

这组数字的意义在于：若你的组织 MTTR 高于 60 天，说明修复节奏落后于行业平均；若关键漏洞 MTTR 大于 15 天，则存在被监管方（如 PCI DSS 30 天、BOD 22-01 两周）判为不合规的现实风险。

三、标准 SLA 框架与自适应修饰符

在设定组织内部 SLA 时，SKILL.md 提供了四级框架，并按"标准 / 激进 / CISA KEV"三档给出目标值：

注意：standards.md 的行业基准表与 SKILL.md 的标准框架表数值一致（14/30/60/90），二者相互印证。

自适应 SLA 修饰符

仅仅按 CVSS 分数一刀切会带来大量误配。仓库给出了基于资产上下文调整 SLA 的修饰符规则：

从references/api-reference.md看，仓库还提供了一组更细的修复/补丁双轨 SLA定义（该表同时被scripts/agent.py中的SLA_DEFINITIONS常量复现）：

两种口径可结合使用：修复 SLA 用于安全团队自身考核（快速处置），补丁 SLA 用于跟踪厂商补丁落地；而 exception_max 则为异常审批提供了硬上限。

四、第一步：制定 SLA 策略文档

任何指标制度都必须先有"宪法"。SKILL.md 给出了一份可直接裁剪的 SLA 策略模板：

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

关键点：异常必须附带业务理由与补偿性控制说明，且 Critical/High 的异常需 CISO 批准，最多延长 90 天且仅允许续期一次——这与references/workflows.md中的升级阶梯（Escalation Ladder）完全对应。

五、SLA 生命周期工作流

references/workflows.md定义了三条核心工作流：

Workflow 1：SLA 生命周期

┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ Vulnerability │────>│ Assign Severity │────>│ Calculate SLA │ │ Discovered │ │ + Asset Context │ │ Deadline │ └──────────────────┘ └──────────────────┘ └──────────────────┘ │ │ v v ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ Create Ticket │────>│ Monitor Aging │────>│ Trigger │ │ (ITSM) │ │ (Daily) │ │ Escalations │ └──────────────────┘ └──────────────────┘ └──────────────────┘

Workflow 2：升级阶梯

SLA % Elapsed: 50% ──> Email reminder to asset owner 75% ──> Escalation to owner's manager 100% ──> CISO notification, marked overdue 120% ──> VP/CTO escalation, exception required

Workflow 3：月度上报循环

Week 1: Collect scan data and aging metrics Week 2: Generate KPI dashboard Week 3: Present to security committee Week 4: Action items assigned, SLA adjustments if needed

值得注意的是，scripts/agent.py的check_sla_compliance()还引入了一个"临险"（at_risk）状态：当age > remediation_days * 0.8时即标记为at_risk，这相当于在 50%/75% 阶梯之外增加了一条"80% 预警线"，让团队在逾期前提前介入。

六、第二步：实现老化计算引擎

方式一：SKILL.md 中的核心类

SKILL.md 提供了VulnerabilityAgingTracker类（需pandas），其核心逻辑：

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)

要点解析（与scripts/process.py的实现相互印证）：

• age_days：已修复漏洞取remediation_date - discovery_date；未修复漏洞按"今日 − 发现日"持续累计，这正是老化（aging）的本义；
• sla_deadline：以discovery_date为起点计算，而非扫描报告日期——SKILL.md 在 Common Pitfalls 中明确强调"不要用报告日期代替发现日期"，否则 SLA 时钟会被错误推迟；
• is_overdue：仅对未修复漏洞判定逾期，已关闭漏洞不再计入逾期；
• sla_pct_elapsed：老化百分比是升级阶梯的唯一驱动变量。

方式二：开箱即用的 CLI 脚本

仓库在scripts/process.py中提供了一个可直接运行的命令行工具，仅依赖 pandas：

pip install pandas python process.py analyze --csv vulns.csv --output aging_report.csv python process.py kpis --csv vulns.csv python process.py escalations --csv vulns.csv --output escalations.csv

其中analyze输出带老化列的报告并打印 KPI；kpis打印含 MTTR、SLA 合规率、按严重级别明细、年龄分布与逾期统计的控制台报告；escalations生成按sla_pct降序排列的升级清单。其内部SLA_DAYS与 SKILL.md 的 14/30/60/90 一致，且对未知严重级别默认回退为 90 天（fillna(90)），保证脏数据不会使程序崩溃。

另一个轻量实现scripts/agent.py则面向 Agent/API 场景：提供check_sla_compliance()（输出within_sla / at_risk / overdue / exception_active / exception_expired / resolved六态）、build_aging_report()（老化桶分布）、calculate_mttr()（按严重级别的均值/中位数）与generate_sla_dashboard()（合规率看板数据），并在__main__中内置了 5 条演示漏洞数据，可直接运行验证逻辑。

七、老化桶（Aging Buckets）与风险评分

references/api-reference.md给出了一套语义化的老化桶命名，便于报告与沟通：

该文件还给出了综合风险评分公式：

Risk Score = CVSS * age_factor * asset_criticality

即在 CVSS 基础上叠加"时间老化因子"与"资产关键度"，避免高价值资产上的陈旧低危漏洞被指标淹没。对应的数据源接入示例同样在 api-reference.md 中给出：

# Nessus (Tenable.io)：列出漏洞 curl -H "X-ApiKeys: accessKey=$ACCESS;secretKey=$SECRET" \ "https://cloud.tenable.com/workbenches/vulnerabilities" # Nessus (Tenable.io)：导出关键/高危漏洞 curl -X POST -H "X-ApiKeys: accessKey=$ACCESS;secretKey=$SECRET" \ "https://cloud.tenable.com/vulns/export" \ -d '{"filters":{"severity":["critical","high"]}}' # Qualys：漏洞知识库列表 curl -u "user:pass" -X POST \ "https://qualysapi.qualys.com/api/2.0/fo/knowledge_base/vuln/" \ -d "action=list&details=All&published_after=2024-01-01"

这些 API 用于把扫描数据灌入老化引擎，再由 ITSM 工单系统承载修复动作，实现端到端闭环。

八、KPI 定义与看板可视化

核心 KPI

看板查询（Elasticsearch 示例）

SKILL.md 给出了可直接用于 Kibana/Grafana 的聚合查询：

# 年龄分布直方图（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 合规率月度趋势 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" }} } } } } }

月度报表模板

仓库在assets/template.md提供了可直接套用的报告模板，包含三张表：

• KPI Summary：本期/上期/目标/趋势四列对比，覆盖 Total Open、MTTR、SLA Compliance Rate（≥90%）、Overdue Count、Exception Count（<5%）；
• Aging Distribution：按年龄桶（0-7d / 8-14d / 15-30d / 31-60d / 61-90d / 90+）× 严重级别的二维计数矩阵；
• Escalation Summary：Owner Reminder (50%) / Manager Escalation (75%) / CISO Notification (100%) / VP/CTO Escalation (120%+) 各级数量与责任团队排行。

配合process.py中generate_kpis()的年龄桶输出（0-7d, 8-14d, 15-30d, 31-60d, 61-90d, 90+d），即可自动生成该模板所需的大部分数据。

九、最佳实践与常见陷阱

最佳实践

1. 从可达成的 SLA 目标起步，随流程成熟再逐步收紧（避免"SLA 疲劳"）；
2. 依据资产关键度与威胁上下文调整 SLA，而非只看 CVSS 分数；
3. 自动化升级通知，减少人工跟踪开销；
4. 按月跟踪 MTTR 趋势以证明改进；
5. 构建要求提供文档化补偿性控制的异常流程；
6. 每月向高管层汇报 SLA 合规率以建立问责机制；
7. 将老化指标纳入安全委员会与董事会级报告；
8. 将 SLA 跟踪与 ITSM 工单集成，实现修复端到端可见。

常见陷阱

• 设定团队无法达成的激进 SLA，导致指标疲劳与数据失真；
• 不按资产关键度适配 SLA，所有系统一视同仁；
• 缺少异常流程，迫使团队要么无视 SLA、要么申请 blanket waiver（一揽子豁免）；
• 只统计开放漏洞数量，忽略年龄与 SLA 合规维度；
• 未从发现日期启动 SLA 时钟（误用报告日期）；
• 团队成熟后不重新设定 SLA 基线。

十、与相关技能衔接

该技能可与仓库内其他漏洞管理技能组合成完整体系：implementing-vulnerability-remediation-sla（SLA 制度落地）、building-executive-vulnerability-risk-report（高管层风险报告）、implementing-security-metrics-and-kpis（指标体系）、performing-remediation-validation-scanning（修复后验证扫描）。老化与 SLA 跟踪解决"是否按时修复"的问题，而验证扫描则闭环回答"修复是否有效"。

结语

漏洞老化与 SLA 跟踪不是一张 Excel 表，而是一套由**标准对齐（NIST/CIS/PCI/BOD 22-01/ISO 27001）→ 目标设定（14/30/60/90 基准）→ 策略制定（异常与升级规则）→ 自动化计算（老化引擎 + KPI）→ 可视上报（看板与月度报告）**组成的治理闭环。本技能包提供了从策略模板、Python 计算引擎到报表模板的完整参考实现，你可以直接基于scripts/process.py与assets/template.md快速搭建原型，再结合自身扫描平台与 ITSM 系统投入生产。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills