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

基于 Anthropic-Cybersecurity-Skills 构建漏洞老化与 SLA 合规跟踪体系KPI 报告模板到自动化引擎的完整实战【免费下载链接】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 及其配套的 合规报告模板 展开讲述如何在漏洞管理场景中落地漏洞老化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 ATTCK 的 T1190、T1203、T1068外部利用面入口相关技术说明它同时服务于风险评估、持续改进和合规举证三条主线见 SKILL.md 元数据。前置条件在开始搭建前需要具备以下数据与系统基础拥有历史扫描数据的漏洞管理平台Nessus/Tenable、Qualys 等带关键性criticality评级的资产清单用于修复跟踪的 ITSM/工单系统报表平台Splunk、Elastic、Power BI、Grafana 等利益相关方对 SLA 时限与升级流程的书面共识。二、标准 SLA 框架先定义时限分级 SLA 基准表严重度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仓库中的两份实现采用了略有差异的默认值可在配置时二选一或按需覆盖process.py 内置SLA_DAYSCritical 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/90CISA BOD 22-01 对 KEV 漏洞给出 2 周硬性期限。建议起步使用可达目标随流程成熟度逐步收紧。自适应 SLA 修正因子单纯按 CVSS 分数一刀切会忽视资产上下文。仓库给出了常见修正因子用于动态调整单条漏洞的 SLA因子修正理由暴露在互联网的资产SLA -50%暴露风险更高出现在 CISA KEV 清单覆盖为 48 小时已确认被积极利用EPSS 得分 0.7SLA -50%利用概率高Tier 1皇冠珠宝级资产SLA -25%业务影响最大存在补偿性控制SLA 25%风险部分缓解厂商补丁不可用例外并设复审日期当前无法修复三、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_elapsedSLA 已消耗百分比为判据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 定义KPI公式目标MTTR平均修复时间Avg(修复日期 - 发现日期)整体 30 天SLA 合规率(SLA 内修复数 / 总数) × 100≥ 90%逾期漏洞数年龄 SLA 的未修复漏洞数呈下降趋势老化分布按年龄桶计数0-14d、15-30d、31-60d、60d多数落在 0-30d修复速度每周关闭漏洞数呈上升趋势例外率(例外数 / 总数) × 100 5%其中SLA 时钟必须从发现日期起算而非报告日期这是仓库明确点出的关键实现细节。引擎核心逻辑SKILL.md 给出了VulnerabilityAgingTracker类的完整实现核心计算逻辑如下与 process.py 的calculate_aging()一致年龄计算已修复漏洞取(修复日期 - 发现日期).days未修复漏洞取(今天 - 发现日期).daysSLA 截止日sla_deadline discovery_date sla_days逾期判定仅未修复漏洞参与——age_days sla_days合规判定仅已修复漏洞参与——age_days sla_days衍生指标days_overdue逾期天数、sla_pct_elapsedSLA 消耗百分比保留 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.csvCSV 至少需要discovery_date、remediation_date、severity三列可选cve_id、asset、owner列用于升级名单。escalations子命令会输出各升级级别的数量分布kpis子命令则打印按严重度拆分的 MTTR 与 SLA 合规率、按年龄桶0-7d / 8-14d / 15-30d / 31-60d / 61-90d / 90d的老化分布以及逾期漏洞的 count/mean/max 统计。agent.py 还内置了演示数据集直接运行python agent.py即可看到 SLA 合规判定、仪表盘数据与 MTTR含均值/中位数的示例输出适合先跑通整体语义再对接真实数据。五、老化的年龄桶划分模板与代码中出现了两套年龄桶口径分别服务于报表展示与代码统计需注意对齐模板口径见 template.md0-7 天、8-14 天、15-30 天、31-60 天、61-90 天、90 天。API 参考口径见 api-reference.md 与 agent.pyNew 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 APIapi-reference.md 给出了两类扫描平台的数据拉取方式Tenable.ioNessus 云版# 列出漏洞 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]}}Qualyscurl -u user:pass -X POST \ https://qualysapi.qualys.com/api/2.0/fo/knowledge_base/vuln/ \ -d actionlistdetailsAllpublished_after2024-01-01拉取到的数据经清洗后即可落入上一节 CSV 的列结构进入老化引擎。七、合规报告模板如何填写与使用模板 template.md 是三段式管理层月报所有[N]占位符应由引擎计算的真实数值替换1. KPI 汇总表MetricCurrent MonthPrior MonthTargetTrendTotal Open Vulnerabilities[N][N]Decreasing[Up/Down]MTTR (all severities)[N] days[N] days 30 days[Up/Down]SLA Compliance Rate[N]%[N]% 90%[Up/Down]Overdue Count[N][N]0[Up/Down]Exception Count[N][N] 5%[Up/Down]该表的每个指标都能由process.py kpis直接产出open_vulnerabilities、mttr_days、sla_compliance_rate、overdue_count例外数量则需结合例外工单单独统计。2. 老化分布表Age BucketCriticalHighMediumLowTotal0-7 days[N][N][N][N][N]8-14 days[N][N][N][N][N]15-30 days[N][N][N][N][N]31-60 days[N][N][N][N][N]61-90 days[N][N][N][N][N]90 days[N][N][N][N][N]这张表回答了逾期风险集中在哪里若 Critical 大量堆积在 61-90 天与 90 桶说明高危漏洞长期未处置应直接触发 CISO 升级。3. 升级汇总表LevelCountTop Offending TeamOwner Reminder (50%)[N][Team]Manager Escalation (75%)[N][Team]CISO Notification (100%)[N][Team]VP/CTO Escalation (120%)[N][Team]升级名单由process.py escalations生成其中escalation_level字段直接对应四个等级Top Offending Team逾期最多的责任团队可按输出中的owner/asset归属字段聚合得出。月度汇报周期workflows.md 给出四周期节奏第 1 周收集扫描数据与老化指标第 2 周生成 KPI 仪表盘第 3 周向安全委员会汇报第 4 周分配行动项并视情况调整 SLA。八、最佳实践与常见陷阱最佳实践从可达成的 SLA 目标起步随流程成熟逐步收紧SLA 要结合资产关键性与威胁上下文调整而非只依据 CVSS 分数自动化升级通知减少人工跟踪开销逐月跟踪 MTTR 趋势以证明改进建立要求书面补偿性控制的例外流程每月向管理层汇报 SLA 合规率强化问责将老化指标纳入安全委员会与董事会级报告与 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-01CISA 对 KEV 漏洞的修复时限ISO 27001:2022 A.8.8技术漏洞的管理。行业参考数据standards.md2024 年新增 CVE 超 30,000 个、同比 17%各行业平均 MTTR 约 60 天而顶尖组织 Critical 漏洞 MTTR 可低于 15 天——这也印证了本体系将 MTTR 目标设为 30 天是行业平均之上、领先组织之下的合理起点。十、进一步深入本技能属于仓库漏洞管理技能群可继续阅读以下相邻技能形成闭环implementing-vulnerability-remediation-slaSLA 策略的落地与执行细节修复完成后可配合执行修复验证扫描确保关闭的漏洞真实修复。若需要将本技能映射到更大框架仓库的 NIST CSF 映射Identify/Improve 类目与 MITRE ATTCK 映射 提供了子域到控制框架的对照参考。【免费下载链接】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），仅供参考