基于 Anthropic-Cybersecurity-Skills 构建漏洞老化与 SLA 合规跟踪体系：KPI 报告模板到自动化引擎的完整实战

基于 Anthropic-Cybersecurity-Skills 构建漏洞老化与 SLA 合规跟踪体系：KPI 报告模板到自动化引擎的完整实战

【免费下载链接】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

本指南围绕仓库技能包 building-vulnerability-aging-and-sla-tracking 及其配套的 合规报告模板 展开，讲述如何在漏洞管理场景中落地"漏洞老化（Aging）+ SLA 跟踪（Service Level Agreement）"体系：从制定分级 SLA 政策、设计老化计算引擎，到产出 KPI 汇总、老化分布与升级（Escalation）报表，再到按月向安全委员会汇报合规指标。读完本文，你将能够直接套用模板产出管理层可读的 SLA 合规月报，并借助仓库自带的 CLI 引擎自动化计算 MTTR、SLA 合规率、逾期数量和升级名单。

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

2024 年新增漏洞数量超过 30,000 个，同比增长 17%。面对如此规模，仅统计"未修复漏洞总数"远远不够——管理层真正关心的是漏洞从被发现到被修复花了多久，以及修复是否在约定的时限（SLA）内完成。漏洞老化（Vulnerability Aging）衡量的正是发现与修复之间的时间差；SLA 跟踪则把这一时间差与按严重度设定的期限进行比对，从而驱动升级流程与合规举证。

该技能在仓库中被标记为 vulnerability-management 子域，并映射到 NIST CSF 2.0 的 ID.RA-01、ID.RA-02、ID.IM-02、ID.RA-06（风险评估与改进）以及 MITRE ATT&CK 的 T1190、T1203、T1068（外部利用面入口相关技术），说明它同时服务于风险评估、持续改进和合规举证三条主线（见 SKILL.md 元数据）。

前置条件

在开始搭建前，需要具备以下数据与系统基础：

• 拥有历史扫描数据的漏洞管理平台（Nessus/Tenable、Qualys 等）；
• 带关键性（criticality）评级的资产清单；
• 用于修复跟踪的 ITSM/工单系统；
• 报表平台（Splunk、Elastic、Power BI、Grafana 等）；
• 利益相关方对 SLA 时限与升级流程的书面共识。

二、标准 SLA 框架：先定义"时限"

分级 SLA 基准表

仓库中的两份实现采用了略有差异的默认值，可在配置时二选一或按需覆盖：

• process.py 内置SLA_DAYS：Critical 14 / High 30 / Medium 60 / Low 90，与标准框架一致；
• agent.py 的SLA_DEFINITIONS则采用更细的三段式：remediation_days（修复时限）、patch_days（打补丁时限）、exception_max_days（例外最长天数），例如 Critical 为 7/15/30 天，Low 为 180/365/365 天。

参考 standards.md 的行业基准，"14/30/60/90 天"属于行业平均水平，而 PCI DSS 要求 30/30/90/90，CISA BOD 22-01 对 KEV 漏洞给出 2 周硬性期限。建议起步使用可达目标，随流程成熟度逐步收紧。

自适应 SLA 修正因子

单纯按 CVSS 分数一刀切会忽视资产上下文。仓库给出了常见修正因子，用于动态调整单条漏洞的 SLA：

三、SLA 政策文档与升级阶梯

政策文档模板

仓库在 SKILL.md 中给出了可直接改编的政策骨架：

Vulnerability Remediation SLA Policy v1.0 1. Scope: 所有信息系统与应用程序 2. Severity Classification: 基于 CVSS v4.0/v3.1 基础分 3. SLA Timelines: 见"标准 SLA 框架"表 4. Adaptive Modifiers: 依据资产上下文应用 5. Exception Process: - 必须以业务理由书面记录 - 需描述补偿性控制 - 最大延期：90 天（仅一次续期） - Critical/High 例外需 CISO 审批 6. Escalation Path: - SLA 消耗 50%: 自动提醒资产负责人 - SLA 消耗 75%: 升级至经理 - SLA 消耗 100%（逾期）: CISO 通知 - SLA 消耗 120%: VP/CTO 升级 7. Metrics Reporting: 每月向安全委员会汇报

升级阶梯（Escalation Ladder）

升级逻辑在代码中得到严格落地。以sla_pct_elapsed（SLA 已消耗百分比）为判据：

SLA % 消耗: 50% ──> 邮件提醒资产负责人 (Owner Reminder) 75% ──> 升级至负责人经理 (Manager Escalation) 100% ──> CISO 通知，标记逾期 (CISO Notification) 120% ──> VP/CTO 升级，要求例外 (VP/CTO Escalation)

对应实现见 process.py 的generate_escalations()：低于 50% 的漏洞直接跳过，其余按 120/100/75/50 阈值归类，并按sla_pct降序输出。此外 agent.py 的check_sla_compliance()还在 80% 处引入at_risk（有风险）状态，作为预警信号。

SLA 生命周期流转

workflows.md 描述了端到端流程：

漏洞发现 ──> 分配严重度+资产上下文 ──> 计算 SLA 截止日 │ │ 创建工单(ITSM) ──> 每日监控老化 ──> 触发升级

四、老化计算引擎：从公式到可运行代码

关键 KPI 定义

其中"SLA 时钟必须从发现日期起算，而非报告日期"，这是仓库明确点出的关键实现细节。

引擎核心逻辑

SKILL.md 给出了VulnerabilityAgingTracker类的完整实现，核心计算逻辑如下（与 process.py 的calculate_aging()一致）：

• 年龄计算：已修复漏洞取(修复日期 - 发现日期).days；未修复漏洞取(今天 - 发现日期).days；
• SLA 截止日：sla_deadline = discovery_date + sla_days；
• 逾期判定：仅未修复漏洞参与——age_days > sla_days；
• 合规判定：仅已修复漏洞参与——age_days <= sla_days；
• 衍生指标：days_overdue（逾期天数）、sla_pct_elapsed（SLA 消耗百分比，保留 1 位小数）。

值得注意的是 process.py 对未知严重度做了兜底：df["severity"].map(sla).fillna(90)，即未匹配到配置的严重度一律按 90 天 SLA 处理，避免空值导致计算崩溃。

直接运行 CLI 引擎

仓库提供的 process.py 开箱即用（依赖pip install pandas），支持三个子命令：

# 计算老化指标并输出报告 python process.py analyze --csv vulns.csv --output aging_report.csv # 生成 KPI 汇总 python process.py kpis --csv vulns.csv # 生成升级名单 python process.py escalations --csv vulns.csv --output escalations.csv

CSV 至少需要discovery_date、remediation_date、severity三列，可选cve_id、asset、owner列用于升级名单。escalations子命令会输出各升级级别的数量分布；kpis子命令则打印按严重度拆分的 MTTR 与 SLA 合规率、按年龄桶（0-7d / 8-14d / 15-30d / 31-60d / 61-90d / 90+d）的老化分布，以及逾期漏洞的 count/mean/max 统计。

agent.py 还内置了演示数据集，直接运行python agent.py即可看到 SLA 合规判定、仪表盘数据与 MTTR（含均值/中位数）的示例输出，适合先跑通整体语义再对接真实数据。

五、老化的年龄桶划分

模板与代码中出现了两套年龄桶口径，分别服务于报表展示与代码统计，需注意对齐：

模板口径（见 template.md）：0-7 天、8-14 天、15-30 天、31-60 天、61-90 天、90+ 天。

API 参考口径（见 api-reference.md 与 agent.py）：New 0-7、Recent 8-30、Aging 31-60、Old 61-90、Stale 91-180、Ancient 181-365、Critical Overdue 365+。

两类口径在语义上互补：报表桶粒度更细（前 30 天拆成三段），代码桶覆盖更长生命周期并命名了"逾期临界"级别。构建仪表盘时，SKILL.md 给出了 Elasticsearch 的 range 聚合示例，可直接将age_days字段按上述边界分组，也可用 date_histogram 按月绘制 SLA 合规趋势。

六、数据接入：Nessus 与 Qualys API

api-reference.md 给出了两类扫描平台的数据拉取方式：

Tenable.io（Nessus 云版）：

# 列出漏洞 curl -H "X-ApiKeys: accessKey=$ACCESS;secretKey=$SECRET" \ "https://cloud.tenable.com/workbenches/vulnerabilities" # 导出漏洞（可按严重度过滤） 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"

拉取到的数据经清洗后即可落入上一节 CSV 的列结构，进入老化引擎。

七、合规报告模板：如何填写与使用

模板 template.md 是三段式管理层月报，所有[N]占位符应由引擎计算的真实数值替换：

1. KPI 汇总表

该表的每个指标都能由process.py kpis直接产出：open_vulnerabilities、mttr_days、sla_compliance_rate、overdue_count，例外数量则需结合例外工单单独统计。

2. 老化分布表

这张表回答了"逾期风险集中在哪里"：若 Critical 大量堆积在 61-90 天与 90+ 桶，说明高危漏洞长期未处置，应直接触发 CISO 升级。

3. 升级汇总表

升级名单由process.py escalations生成，其中escalation_level字段直接对应四个等级，"Top Offending Team"（逾期最多的责任团队）可按输出中的owner/asset归属字段聚合得出。

月度汇报周期

workflows.md 给出四周期节奏：第 1 周收集扫描数据与老化指标，第 2 周生成 KPI 仪表盘，第 3 周向安全委员会汇报，第 4 周分配行动项并视情况调整 SLA。

八、最佳实践与常见陷阱

最佳实践

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

常见陷阱

• 设定团队无法达成的 SLA，导致"SLA 疲劳"；
• 不按资产关键性区分 SLA，对所有系统一刀切；
• 缺少例外流程，迫使团队要么无视 SLA、要么申请全量豁免；
• 只看未修复漏洞数量，不看年龄与 SLA 合规率；
• SLA 时钟不从发现日期起算（误用报告日期）；
• 团队成熟度提升后未重新校准 SLA。

九、合规标准对照

如需向审计方证明 SLA 机制合规，可对照 standards.md 中列出的标准：

• NIST SP 800-40 Rev 4：企业补丁管理规划指南；
• CIS Controls v8.1 Control 7：持续漏洞管理；
• PCI DSS v4.0 Req 6.3.3：安全补丁须在一个月内安装；
• BOD 22-01：CISA 对 KEV 漏洞的修复时限；
• ISO 27001:2022 A.8.8：技术漏洞的管理。

行业参考数据（standards.md）：2024 年新增 CVE 超 30,000 个、同比 +17%，各行业平均 MTTR 约 60 天，而顶尖组织 Critical 漏洞 MTTR 可低于 15 天——这也印证了本体系将 MTTR 目标设为 30 天是"行业平均之上、领先组织之下"的合理起点。

十、进一步深入

本技能属于仓库漏洞管理技能群，可继续阅读以下相邻技能形成闭环：

• implementing-vulnerability-remediation-sla：SLA 策略的落地与执行细节；
• 修复完成后可配合执行修复验证扫描，确保关闭的漏洞真实修复。

若需要将本技能映射到更大框架，仓库的 NIST CSF 映射（Identify/Improve 类目）与 MITRE ATT&CK 映射 提供了子域到控制框架的对照参考。

【免费下载链接】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