尧图网页设计 
Anthropic-Cybersecurity-Skills 实战指南构建漏洞老化Vulnerability Aging与 SLA 跟踪体系的行业标准、基准与落地实现【免费下载链接】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导读本文以 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 天而针对被积极利用的关键 CVE2448 小时的激进时限也日趋常见。与此同时全行业平均修复时间MTTR约为 60 天而表现最好的组织可将关键漏洞的 MTTR 控制在 15 天以内——这正是 SLA 制度拉开差距的地方。该技能包在 SKILL.md 的元数据中将其映射至 NIST CSF 2.0 的ID.RA-01、ID.RA-02、ID.RA-06、ID.IM-02及 MITRE ATTCK 的T1190、T1203、T1068说明该能力同时服务于风险评估、响应度量与合规证明三项目标。二、行业标准全景核心基准references/standards.md列出了构建 SLA 制度时应当对齐的核心行业标准标准定位NIST SP 800-40 Rev 4企业补丁管理规划指南是设计补丁/修复流程的基线参考CIS Controls v8.1 Control 7持续漏洞管理Continuous Vulnerability Management要求对漏洞进行持续发现、跟踪与修复PCI DSS v4.0 Req 6.3.3安全补丁须在一个月内安装完成是支付卡环境下的硬性时限BOD 22-01CISA 针对已知被利用漏洞KEV规定的修复时限ISO 27001:2022 A.8.8技术漏洞管理控制项强调识别、评估与及时处置从源码结构看该技能包在设计上刻意与这些标准对齐标准 SLA 框架中的 CISA KEV 列直接对应 BOD 22-01 的期限覆盖逻辑而异常流程、升级路径与月度指标上报等设计则回应了 PCI DSS 与 ISO 27001 对可证明的修复流程的要求。行业 SLA 基准表SourceCriticalHighMediumLowCISA BOD 22-012 weeksN/AN/AN/APCI DSS30 days30 days90 days90 daysIndustry Average14 days30 days60 days90 daysAggressive Target48 hours7 days30 days60 days说明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三档给出目标值SeverityCVSS RangeStandard SLAAggressive SLACISA KEV SLACritical9.0-10.014 days48 hoursBOD 22-01 due dateHigh7.0-8.930 days7 days14 daysMedium4.0-6.960 days30 daysN/ALow0.1-3.990 days60 daysN/AInformational0.0Best effortBest effortN/A注意standards.md 的行业基准表与 SKILL.md 的标准框架表数值一致14/30/60/90二者相互印证。自适应 SLA 修饰符仅仅按 CVSS 分数一刀切会带来大量误配。仓库给出了基于资产上下文调整 SLA 的修饰符规则FactorModifierRationaleInternet-facing asset-50% SLA暴露面更大风险更高CISA KEV listedOverride to 48h已确认被积极利用EPSS 0.7-50% SLA利用概率高Tier 1皇冠级资产-25% SLA业务影响最大存在补偿性控制25% SLA风险已部分缓解厂商补丁不可用异常 复审日期当前无法修复从references/api-reference.md看仓库还提供了一组更细的修复/补丁双轨 SLA定义该表同时被scripts/agent.py中的SLA_DEFINITIONS常量复现SeverityRemediation SLAPatch SLAException MaxCritical7 days15 days30 daysHigh30 days45 days90 daysMedium90 days120 days180 daysLow180 days365 days365 days两种口径可结合使用修复 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 1SLA 生命周期┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ 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 owners manager 100% ── CISO notification, marked overdue 120% ── VP/CTO escalation, exception requiredWorkflow 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_overridesNone): 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], errorscoerce ) 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, axis1 ) 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], unitD) vulns_df[is_overdue] vulns_df.apply( lambda row: row[age_days] row[sla_days] if pd.isna(row[remediation_date]) else False, axis1 ) vulns_df[sla_compliance] vulns_df.apply( lambda row: row[age_days] row[sla_days] if pd.notna(row[remediation_date]) else None, axis1 ) vulns_df[days_overdue] vulns_df.apply( lambda row: max(0, row[age_days] - row[sla_days]) if row[is_overdue] else 0, axis1 ) 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中提供了一个可直接运行的命令行工具仅依赖 pandaspip 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输出带老化列的报告并打印 KPIkpis打印含 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给出了一套语义化的老化桶命名便于报告与沟通BucketRangeNew0-7 daysRecent8-30 daysAging31-60 daysOld61-90 daysStale91-180 daysAncient181-365 daysCritical Overdue365 days该文件还给出了综合风险评分公式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 actionlistdetailsAllpublished_after2024-01-01这些 API 用于把扫描数据灌入老化引擎再由 ITSM 工单系统承载修复动作实现端到端闭环。八、KPI 定义与看板可视化核心 KPIKPIFormulaTargetMean Time to Remediate (MTTR)Avg(remediation_date - discovery_date) 30 days overallSLA Compliance Rate(Vulns remediated within SLA / Total vulns) * 100 90%Overdue Vulnerability CountCount where age SLATrending downwardVulnerability Aging DistributionCount by age bucket (0-14d, 15-30d, 31-60d, 60d)Majority in 0-30dRemediation VelocityVulns closed per weekTrending upwardException Rate(Exceptions / Total vulns) * 100 5%看板查询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 Count5%Aging Distribution按年龄桶0-7d / 8-14d / 15-30d / 31-60d / 61-90d / 90× 严重级别的二维计数矩阵Escalation SummaryOwner 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, 90d即可自动生成该模板所需的大部分数据。九、最佳实践与常见陷阱最佳实践从可达成的 SLA 目标起步随流程成熟再逐步收紧避免SLA 疲劳依据资产关键度与威胁上下文调整 SLA而非只看 CVSS 分数自动化升级通知减少人工跟踪开销按月跟踪 MTTR 趋势以证明改进构建要求提供文档化补偿性控制的异常流程每月向高管层汇报 SLA 合规率以建立问责机制将老化指标纳入安全委员会与董事会级报告将 SLA 跟踪与 ITSM 工单集成实现修复端到端可见。常见陷阱设定团队无法达成的激进 SLA导致指标疲劳与数据失真不按资产关键度适配 SLA所有系统一视同仁缺少异常流程迫使团队要么无视 SLA、要么申请 blanket waiver一揽子豁免只统计开放漏洞数量忽略年龄与 SLA 合规维度未从发现日期启动 SLA 时钟误用报告日期团队成熟后不重新设定 SLA 基线。十、与相关技能衔接该技能可与仓库内其他漏洞管理技能组合成完整体系implementing-vulnerability-remediation-slaSLA 制度落地、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 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），仅供参考 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 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导读本文以 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 天而针对被积极利用的关键 CVE2448 小时的激进时限也日趋常见。与此同时全行业平均修复时间MTTR约为 60 天而表现最好的组织可将关键漏洞的 MTTR 控制在 15 天以内——这正是 SLA 制度拉开差距的地方。该技能包在 SKILL.md 的元数据中将其映射至 NIST CSF 2.0 的ID.RA-01、ID.RA-02、ID.RA-06、ID.IM-02及 MITRE ATTCK 的T1190、T1203、T1068说明该能力同时服务于风险评估、响应度量与合规证明三项目标。二、行业标准全景核心基准references/standards.md列出了构建 SLA 制度时应当对齐的核心行业标准标准定位NIST SP 800-40 Rev 4企业补丁管理规划指南是设计补丁/修复流程的基线参考CIS Controls v8.1 Control 7持续漏洞管理Continuous Vulnerability Management要求对漏洞进行持续发现、跟踪与修复PCI DSS v4.0 Req 6.3.3安全补丁须在一个月内安装完成是支付卡环境下的硬性时限BOD 22-01CISA 针对已知被利用漏洞KEV规定的修复时限ISO 27001:2022 A.8.8技术漏洞管理控制项强调识别、评估与及时处置从源码结构看该技能包在设计上刻意与这些标准对齐标准 SLA 框架中的 CISA KEV 列直接对应 BOD 22-01 的期限覆盖逻辑而异常流程、升级路径与月度指标上报等设计则回应了 PCI DSS 与 ISO 27001 对可证明的修复流程的要求。行业 SLA 基准表SourceCriticalHighMediumLowCISA BOD 22-012 weeksN/AN/AN/APCI DSS30 days30 days90 days90 daysIndustry Average14 days30 days60 days90 daysAggressive Target48 hours7 days30 days60 days说明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三档给出目标值SeverityCVSS RangeStandard SLAAggressive SLACISA KEV SLACritical9.0-10.014 days48 hoursBOD 22-01 due dateHigh7.0-8.930 days7 days14 daysMedium4.0-6.960 days30 daysN/ALow0.1-3.990 days60 daysN/AInformational0.0Best effortBest effortN/A注意standards.md 的行业基准表与 SKILL.md 的标准框架表数值一致14/30/60/90二者相互印证。自适应 SLA 修饰符仅仅按 CVSS 分数一刀切会带来大量误配。仓库给出了基于资产上下文调整 SLA 的修饰符规则FactorModifierRationaleInternet-facing asset-50% SLA暴露面更大风险更高CISA KEV listedOverride to 48h已确认被积极利用EPSS 0.7-50% SLA利用概率高Tier 1皇冠级资产-25% SLA业务影响最大存在补偿性控制25% SLA风险已部分缓解厂商补丁不可用异常 复审日期当前无法修复从references/api-reference.md看仓库还提供了一组更细的修复/补丁双轨 SLA定义该表同时被scripts/agent.py中的SLA_DEFINITIONS常量复现SeverityRemediation SLAPatch SLAException MaxCritical7 days15 days30 daysHigh30 days45 days90 daysMedium90 days120 days180 daysLow180 days365 days365 days两种口径可结合使用修复 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 1SLA 生命周期┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ 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 owners manager 100% ── CISO notification, marked overdue 120% ── VP/CTO escalation, exception requiredWorkflow 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_overridesNone): 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], errorscoerce ) 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, axis1 ) 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], unitD) vulns_df[is_overdue] vulns_df.apply( lambda row: row[age_days] row[sla_days] if pd.isna(row[remediation_date]) else False, axis1 ) vulns_df[sla_compliance] vulns_df.apply( lambda row: row[age_days] row[sla_days] if pd.notna(row[remediation_date]) else None, axis1 ) vulns_df[days_overdue] vulns_df.apply( lambda row: max(0, row[age_days] - row[sla_days]) if row[is_overdue] else 0, axis1 ) 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中提供了一个可直接运行的命令行工具仅依赖 pandaspip 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输出带老化列的报告并打印 KPIkpis打印含 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给出了一套语义化的老化桶命名便于报告与沟通BucketRangeNew0-7 daysRecent8-30 daysAging31-60 daysOld61-90 daysStale91-180 daysAncient181-365 daysCritical Overdue365 days该文件还给出了综合风险评分公式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 actionlistdetailsAllpublished_after2024-01-01这些 API 用于把扫描数据灌入老化引擎再由 ITSM 工单系统承载修复动作实现端到端闭环。八、KPI 定义与看板可视化核心 KPIKPIFormulaTargetMean Time to Remediate (MTTR)Avg(remediation_date - discovery_date) 30 days overallSLA Compliance Rate(Vulns remediated within SLA / Total vulns) * 100 90%Overdue Vulnerability CountCount where age SLATrending downwardVulnerability Aging DistributionCount by age bucket (0-14d, 15-30d, 31-60d, 60d)Majority in 0-30dRemediation VelocityVulns closed per weekTrending upwardException Rate(Exceptions / Total vulns) * 100 5%看板查询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 Count5%Aging Distribution按年龄桶0-7d / 8-14d / 15-30d / 31-60d / 61-90d / 90× 严重级别的二维计数矩阵Escalation SummaryOwner 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, 90d即可自动生成该模板所需的大部分数据。九、最佳实践与常见陷阱最佳实践从可达成的 SLA 目标起步随流程成熟再逐步收紧避免SLA 疲劳依据资产关键度与威胁上下文调整 SLA而非只看 CVSS 分数自动化升级通知减少人工跟踪开销按月跟踪 MTTR 趋势以证明改进构建要求提供文档化补偿性控制的异常流程每月向高管层汇报 SLA 合规率以建立问责机制将老化指标纳入安全委员会与董事会级报告将 SLA 跟踪与 ITSM 工单集成实现修复端到端可见。常见陷阱设定团队无法达成的激进 SLA导致指标疲劳与数据失真不按资产关键度适配 SLA所有系统一视同仁缺少异常流程迫使团队要么无视 SLA、要么申请 blanket waiver一揽子豁免只统计开放漏洞数量忽略年龄与 SLA 合规维度未从发现日期启动 SLA 时钟误用报告日期团队成熟后不重新设定 SLA 基线。十、与相关技能衔接该技能可与仓库内其他漏洞管理技能组合成完整体系implementing-vulnerability-remediation-slaSLA 制度落地、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 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），仅供参考