building-vulnerability-aging-and-sla-tracking

用途

该技能用于实现漏洞老化仪表盘与 SLA 跟踪系统，衡量漏洞从发现到修复所经历的时间，并依据严重程度对应的截止期限判断修复是否在 SLA 内完成。漏洞老化衡量发现与修复之间的时长，SLA 跟踪则强制执行基于严重程度的截止期限。资料指出，2024 年新发现漏洞超过 30,000 个（较上一年增长 17%），组织必须跟踪漏洞未修补的时长以及修复是否在既定 SLA 内完成。行业基准显示标准 SLA 为：严重 14 天、高危 30 天、中危 60 天、低危 90 天，但更激进的时间线（针对正被利用的严重 CVE 为 24-48 小时）日益普遍。该技能涵盖 SLA 策略设计、老化仪表盘构建、自动化升级实现以及合规指标生成。

主要能力

标准漏洞 SLA 框架：按严重程度（Critical 9.0-10.0、High 7.0-8.9、Medium 4.0-6.9、Low 0.1-3.9、Informational 0.0）定义标准 SLA、激进 SLA 与 CISA KEV SLA。
自适应 SLA 修正因子：根据资产上下文调整 SLA，包括互联网暴露资产（-50% SLA）、CISA KEV 列入（覆盖为 48 小时）、EPSS > 0.7（-50% SLA）、Tier 1 关键资产（-25% SLA）、存在补偿控制（+25% SLA）、厂商补丁不可用（例外并设定复审日期）。
KPI 指标：平均修复时间（MTTR，目标 < 30 天）、SLA 合规率（目标 >= 90%）、逾期漏洞数量（趋势下降）、漏洞老化分布（按 0-14 天、15-30 天、31-60 天、60+ 天分桶）、修复速度（每周关闭漏洞数，趋势上升）、例外率（目标 < 5%）。
老化计算引擎：提供基于 pandas 的 VulnerabilityAgingTracker 类，计算每个漏洞的老化天数、SLA 天数、SLA 截止日期、是否逾期、SLA 合规性、逾期天数、SLA 已过百分比，并生成 KPI 摘要与升级清单。
仪表盘可视化：提供 Grafana/Kibana 查询示例，包括老化分布直方图（Elasticsearch 范围聚合）与 SLA 合规趋势（按月日期直方图）。
升级流程：SLA 已过 50% 自动提醒资产负责人；75% 升级至经理；100%（逾期）通知 CISO；120% 升级至 VP/CTO。

使用方式

资料给出的工作流包括：

定义 SLA 策略文档：明确范围（所有信息系统与应用）、严重程度分类（基于 CVSS v4.0/v3.1 基础分）、SLA 时间线、自适应修正因子、例外流程（需业务理由与补偿控制描述，最长延期 90 天且仅可续期一次，严重/高危例外需 CISO 批准）、升级路径与指标报告（每月向安全委员会报告）。
构建老化计算引擎：使用提供的 Python 代码，通过 calculate_aging 计算老化指标，通过 generate_kpis 生成 KPI 摘要，通过 get_escalation_list 获取需升级的漏洞清单。
仪表盘可视化：使用提供的 Elasticsearch 聚合查询构建老化分布与 SLA 合规趋势视图。

适用场景

在环境中部署或配置漏洞老化与 SLA 跟踪能力时。
建立与合规要求对齐的安全控制时。
构建或改进该领域的安全架构时。
开展需要此实现的安全评估时。

前提条件

具备历史扫描数据的漏洞管理平台。
带有关键性评级的资产清单。
用于修复跟踪的 ITSM/工单系统。
报告平台（Splunk、Elastic、Power BI、Grafana）。
利益相关方就 SLA 时间线与升级流程达成一致。

最佳实践

从可实现的 SLA 目标开始，随流程成熟逐步收紧。
基于资产关键性与威胁上下文调整 SLA，而非仅依据 CVSS 分数。
自动化升级通知以减少人工跟踪开销。
逐月跟踪 MTTR 趋势以展示改进。
构建要求记录补偿控制的例外工作流。
每月向高管层报告 SLA 合规情况以落实问责。
将老化指标纳入安全委员会与董事会级报告。
将 SLA 跟踪与 ITSM 工单集成，实现端到端修复可见性。

常见陷阱

设定团队无法实现的 SLA 目标，导致 SLA 疲劳。
未针对资产关键性调整 SLA，对所有系统一视同仁。
缺乏例外流程，迫使团队要么忽略 SLA，要么申请一揽子豁免。
仅衡量未关闭漏洞数量，而不考虑老化与 SLA 合规。
未从发现日期开始计算 SLA 时钟（而使用报告日期）。
未随团队成熟度提升重新设定 SLA 基线。

限制

资料未提供该技能的具体收费、价格、平台支持范围或实际使用效果数据，这些信息暂未提供。

技能介绍

用途