漏洞老化与 SLA 追踪工作流实战基于 Anthropic-Cybersecurity-Skills 构建修复时效治理体系【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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技能包位于 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激进 SLACISA KEV SLACritical9.0–10.014 天48 小时BOD 22-01 截止日High7.0–8.930 天7 天14 天Medium4.0–6.960 天30 天N/ALow0.1–3.990 天60 天N/AInformational0.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.7SLA -50%被利用概率高Tier 1皇冠明珠资产SLA -25%业务影响最大存在补偿性控制SLA 25%风险已被部分缓解厂商补丁不可用异常复审日期当前无法修复这一设计在 scripts/process.py 中得到印证引擎把SLA_DAYS定义为按严重度映射的字典并通过sla_config参数支持运行时覆盖——修饰因子本质上就是对这份映射的调整。KPI 体系KPI公式目标平均修复时间 MTTRAvg(修复日期 − 发现日期)整体 30 天SLA 合规率(SLA 内修复数 / 总数) × 100%≥ 90%超期漏洞数计数满足 年龄 SLA趋势下降老化分布按 0–14/15–30/31–60/60 天分桶计数多数落在 0–30 天修复速度每周关闭的漏洞数趋势上升异常率(异常数 / 总数) × 100% 5%二、Workflow 1SLA 全生命周期原文档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()直接服务于第三条工作流的升级触发。引擎默认值即标准 SLACritical 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 actionlistdetailsAllpublished_after2024-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 owners manager 100% ── CISO notification, marked overdue 120% ── VP/CTO escalation, exception required这一阶梯在引擎代码中被完整实现。文档版get_escalation_list()与 CLI 版generate_escalations()scripts/process.py逻辑一致对每个未修复漏洞计算sla_pct_elapsed120%归入 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 把老化分布定义为七档桶New0–7 天、Recent8–30 天、Aging31–60 天、Old61–90 天、Stale91–180 天、Ancient181–365 天、Critical Overdue365 天。这比仪表盘常用的六档分桶更细适合需要突出僵尸漏洞超半年未修的场景。四、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 Reminder50%、Manager Escalation75%、CISO Notification100%、VP/CTO Escalation120%四级计数与最严重团队。第 2 步的 KPI 仪表盘可直接用引擎输出投喂。技能文档还给出了 Grafana/Kibana 侧的聚合查询示例SKILL.mdElasticsearch 的range聚合按age_days生成 0–7/8–14/15–30/31–60/61–90/90 六桶老化直方图date_histogramfilterdoc[age_days].value doc[sla_days].value生成月度 SLA 合规趋势。周而复始第 4 周的SLA 调整正是基于上月合规率、异常率与团队反馈来收紧或放宽基线。五、最佳实践与常见陷阱技能文档总结的实践要点SKILL.md先设定可达成的 SLA 目标随流程成熟再逐步收紧SLA 要基于资产关键性与威胁上下文调整而非只看 CVSS自动化升级通知减少人工跟踪负担逐月跟踪 MTTR 趋势以证明改进构建要求书面补偿控制的异常流程每月向高管层汇报 SLA 合规率落实问责将老化指标纳入安全委员会与董事会级汇报与 ITSM 工单打通实现端到端修复可见性。常见陷阱包括设定团队无法达成的 SLA 导致SLA 疲劳不区分资产关键性一刀切缺少异常流程迫使团队要么无视 SLA、要么申请大面积豁免只统计开放漏洞数量而不看年龄与合规用报告日期而非发现日期启动 SLA 时钟这会系统性低估老化团队成熟后不重新校准 SLA 基线。六、合规对齐与相关技能该技能在元数据中映射了 NIST CSF 的 ID.RA-01、ID.RA-02、ID.RA-06、ID.IM-02 以及 MITRE ATTCK 的 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-01CISA 对 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.mdAPI 参考references/api-reference.md报告模板assets/template.mdCLI 引擎scripts/process.pyAgent 轻量实现scripts/agent.py【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考