漏洞老化与 SLA 追踪工作流实战：基于 Anthropic-Cybersecurity-Skills 构建修复时效治理体系

本文基于本仓库 building-vulnerability-aging-and-sla-tracking 技能包（位于 skills/building-vulnerability-aging-and-sla-tracking/SKILL.md），系统讲解漏洞老化（Aging）与 SLA 追踪的三条核心工作流：SLA 全生命周期管理、升级阶梯（Escalation Ladder）与月度报告循环。读完本文，你将掌握如何制定严重度驱动的修复时限策略、用可复用的 Python 引擎计算老化与合规指标、按 50%/75%/100%/120% 阈值自动升级处理、并落地月度 KPI 汇报机制，为合规审计（如 PCI DSS、CIS、ISO 27001）提供量化证据。

一、核心概念：老化与 SLA 的度量基础

在进入三条工作流之前，先建立度量语言。**漏洞老化（Vulnerability Aging）**衡量漏洞从发现到修复之间流逝的时间；**SLA 追踪（SLA Tracking）**则强制按严重度执行修复截止期限。两者结合，才能回答管理层最关心的问题："漏洞多久能被修掉、有没有超期、超期多少天"。

标准 SLA 框架

技能文档给出了行业通用与激进两档基线（SKILL.md）：

严重度	CVSS 区间	标准 SLA	激进 SLA	CISA KEV SLA
Critical	9.0–10.0	14 天	48 小时	BOD 22-01 截止日
High	7.0–8.9	30 天	7 天	14 天
Medium	4.0–6.9	60 天	30 天	N/A
Low	0.1–3.9	90 天	60 天	N/A
Informational	0.0	尽力而为	尽力而为	N/A

仓库中的 references/api-reference.md 还给出了一套更细的双阶段口径（修复 SLA / 补丁 SLA / 异常上限），例如 Critical 为 7 天修复、15 天打补丁、异常最长 30 天——实际落地时可作为标准表的备选档位。

自适应 SLA 修饰因子

仅凭 CVSS 分数定 SLA 是远远不够的。技能文档定义了 6 个基于资产与威胁上下文的修饰因子（SKILL.md）：

因子	修饰	理由
暴露在互联网的资产	SLA -50%	暴露风险更高
命中 CISA KEV 清单	覆盖为 48 小时	已确认被在野利用
EPSS 评分 > 0.7	SLA -50%	被利用概率高
Tier 1（皇冠明珠）资产	SLA -25%	业务影响最大
存在补偿性控制	SLA +25%	风险已被部分缓解
厂商补丁不可用	异常+复审日期	当前无法修复

这一设计在 scripts/process.py 中得到印证：引擎把 SLA_DAYS 定义为按严重度映射的字典，并通过 sla_config 参数支持运行时覆盖——修饰因子本质上就是对这份映射的调整。

KPI 体系

KPI	公式	目标
平均修复时间 MTTR	Avg(修复日期 − 发现日期)	整体 < 30 天
SLA 合规率	(SLA 内修复数 / 总数) × 100%	≥ 90%
超期漏洞数	计数满足 年龄 > SLA	趋势下降
老化分布	按 0–14/15–30/31–60/60+ 天分桶计数	多数落在 0–30 天
修复速度	每周关闭的漏洞数	趋势上升
异常率	(异常数 / 总数) × 100%	< 5%

二、Workflow 1：SLA 全生命周期

原文档（references/workflows.md）给出了生命周期主流程：

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

这条链路的每一步都有可落地的具体动作：

第 1 步：定义 SLA 政策文档。 技能文档给出了可直接照抄修改的政策模板（SKILL.md），要点包括：范围覆盖所有信息系统与应用；严重度基于 CVSS v4.0/v3.1 基础分；异常流程必须附业务理由与补偿性控制说明、最大延期 90 天且仅可续期一次、Critical/High 异常需 CISO 批准；升级路径与下文阶梯一致；每月向安全委员会汇报指标。

第 2 步：构建老化计算引擎。 技能文档提供了 VulnerabilityAgingTracker 类的完整实现（SKILL.md），核心逻辑如下：

• calculate_aging()：统一解析发现/修复日期，age_days 对已修复漏洞取"修复日−发现日"，未修复漏洞取"今天−发现日"；随后算出 sla_days、sla_deadline、is_overdue、sla_compliance、days_overdue 与 sla_pct_elapsed（老化百分比）。
• generate_kpis()：区分开/闭漏洞，产出总数、超期数、MTTR、SLA 合规率，并按严重度汇总 overdue_by_severity。
• get_escalation_list()：直接服务于第三条工作流的升级触发。

引擎默认值即标准 SLA（Critical 14 天 / High 30 天 / Medium 60 天 / Low 90 天），且构造函数接受 sla_overrides 字典来注入修饰因子后的定制值。

第 3 步：接入数据源。 从扫描平台拉取漏洞清单。仓库的 references/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"

可直接运行的命令行引擎

除文档中的类实现外，仓库还提供了完整的 CLI 脚本 scripts/process.py，依赖仅 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、severity 列；remediation_date、cve_id、asset、owner 列用于补全报告。analyze 子命令在保存报告的同时会打印 KPI 摘要（含各严重度 MTTR 与合规率、按 0–7/8–14/15–30/31–60/61–90/90+ 天分桶的老化分布、超期严重度统计），可直接贴在汇报材料中。从源码可见，未识别严重度默认按 90 天 SLA 兜底（process.py 中的 .fillna(90)），避免脏数据导致计算中断。

三、Workflow 2：升级阶梯（Escalation Ladder）

当漏洞进入老化周期后，需要按 SLA 消耗比例逐级升级。原文档（references/workflows.md）定义了四级阶梯：

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

这一阶梯在引擎代码中被完整实现。文档版 get_escalation_list() 与 CLI 版 generate_escalations()（scripts/process.py）逻辑一致：对每个未修复漏洞计算 sla_pct_elapsed，>=120% 归入 VP/CTO 升级、>=100% 归入 CISO 通知、>=75% 归入经理升级、>=50% 归入资产负责人提醒，其余不触发；输出列包含 cve_id、严重度、年龄、SLA 天数、超期天数、SLA 百分比、升级级别、资产与负责人，并按 SLA 百分比降序排序，方便按优先级处理。

值得注意的是升级阶梯与 SLA 政策模板中的升级路径逐条对应（50% 自动提醒负责人 → 75% 升级到经理 → 100% 超期通知 CISO → 120% VP/CTO 升级），实现上完全一致，可直接作为自动化通知的判定依据。

更细的合规状态机

仓库还提供了一个面向 API/Agent 的轻量实现 scripts/agent.py，其 check_sla_compliance() 在"合规/超期"二元之外增加了 at_risk（消耗 80% 以上）、exception_active / exception_expired（异常期与异常超期）、resolved 五种状态；同时提供 calculate_mttr()（按严重度输出均值/中位数）、build_aging_report()（按老化分桶×严重度交叉统计）、generate_sla_dashboard()（合规率 + 按严重度明细）。它的 SLA 定义（agent.py）使用 remediation/patch/exception 三字段结构，对应 api-reference 中的双阶段口径。

老化分桶口径

api-reference 与 agent.py 把老化分布定义为七档桶：New（0–7 天）、Recent（8–30 天）、Aging（31–60 天）、Old（61–90 天）、Stale（91–180 天）、Ancient（181–365 天）、Critical Overdue（365+ 天）。这比仪表盘常用的六档分桶更细，适合需要突出"僵尸漏洞"（超半年未修）的场景。

四、Workflow 3：月度报告循环

原文档（references/workflows.md）定义了月度汇报节奏：

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

对应地，技能包提供了开箱即用的报告模板 assets/template.md，包含三张可直接填数的表：

• KPI 汇总表：本期/上期/目标/趋势四列，覆盖总开放漏洞数、MTTR（目标 < 30 天）、SLA 合规率（目标 ≥ 90%）、超期数（目标 0）、异常数（目标 < 5%）。
• 老化分布表：按 0–7、8–14、15–30、31–60、61–90、90+ 天分桶 × Critical/High/Medium/Low 严重度交叉计数。
• 升级汇总表：Owner Reminder（50%）、Manager Escalation（75%）、CISO Notification（100%）、VP/CTO Escalation（120%+）四级计数与最严重团队。

第 2 步的 KPI 仪表盘可直接用引擎输出投喂。技能文档还给出了 Grafana/Kibana 侧的聚合查询示例（SKILL.md）：Elasticsearch 的 range 聚合按 age_days 生成 0–7/8–14/15–30/31–60/61–90/90+ 六桶老化直方图；date_histogram + filter（doc['age_days'].value <= doc['sla_days'].value）生成月度 SLA 合规趋势。周而复始，第 4 周的"SLA 调整"正是基于上月合规率、异常率与团队反馈来收紧或放宽基线。

五、最佳实践与常见陷阱

技能文档总结的实践要点（SKILL.md）：

1. 先设定可达成的 SLA 目标，随流程成熟再逐步收紧；
2. SLA 要基于资产关键性与威胁上下文调整，而非只看 CVSS；
3. 自动化升级通知，减少人工跟踪负担；
4. 逐月跟踪 MTTR 趋势以证明改进；
5. 构建要求书面补偿控制的异常流程；
6. 每月向高管层汇报 SLA 合规率，落实问责；
7. 将老化指标纳入安全委员会与董事会级汇报；
8. 与 ITSM 工单打通，实现端到端修复可见性。

常见陷阱包括：设定团队无法达成的 SLA 导致"SLA 疲劳"；不区分资产关键性一刀切；缺少异常流程迫使团队要么无视 SLA、要么申请大面积豁免；只统计开放漏洞数量而不看年龄与合规；用报告日期而非发现日期启动 SLA 时钟（这会系统性低估老化）；团队成熟后不重新校准 SLA 基线。

六、合规对齐与相关技能

该技能在元数据中映射了 NIST CSF 的 ID.RA-01、ID.RA-02、ID.RA-06、ID.IM-02 以及 MITRE ATT&CK 的 T1190（利用面向公众的应用）、T1203（客户端利用）、T1068（提权利用），即围绕"先被利用的高危漏洞"设防。行业标准参考见 references/standards.md，包括 NIST SP 800-40 Rev 4（企业补丁管理规划）、CIS Controls v8.1 第 7 项（持续漏洞管理）、PCI DSS v4.0 要求 6.3.3（一个月内安装安全补丁）、BOD 22-01（CISA 对 KEV 漏洞的修复时限）与 ISO 27001:2022 A.8.8。SLA 基线与这些标准的对应关系可对照其基准表设计。

若需继续深化，本仓库还提供了相邻技能：implementing-vulnerability-remediation-sla、building-executive-vulnerability-risk-report、implementing-security-metrics-and-kpis、performing-remediation-validation-scanning，以及资产关键性评分的 performing-asset-criticality-scoring-for-vulns/SKILL.md（可与本文的 Tier 1 修饰因子衔接使用）。全文涉及的可复用资源汇总如下：

• 技能主文档：skills/building-vulnerability-aging-and-sla-tracking/SKILL.md
• 工作流定义：references/workflows.md
• 标准与基准：references/standards.md
• API 参考：references/api-reference.md
• 报告模板：assets/template.md
• CLI 引擎：scripts/process.py
• Agent 轻量实现：scripts/agent.py