将漏洞修复重新思考为容量分配问题
Rethinking Vulnerability Remediation as a Capacity Allocation Problem
浏览论文内容
中文总结 AI 辅助
本研究将漏洞修复视为流量控制与容量分配问题，通过多数据集分析发现队列状态、排序策略等对修复效率的影响，为漏洞修复提供了新的优化思路。
中文摘要 AI 辅助
随着人工智能加快漏洞发现速度，修复吞吐量可能会成为比优先级排序准确性更重要的约束条件。本研究使用Apache Jira、Mozilla Bugzilla、Red Hat安全勘误表、5个公共Jira组织及npm依赖图，将漏洞修复评估为流量控制问题。Apache的漏洞解决时间呈现强重尾分布，而主要问题跟踪系统中94%-100%的到达项进入的队列，经估计处于或超过容量。队列上下文模型仅提供中等预测区分度，且在很大程度上与简单的项目级基准模型表现相当。不同系统间的严重程度-速度区分度差异显著。流量控制分析显示出更大的操作影响：从过载队列转为排空队列与更短的解决时间相关；在固定容量下，按严重程度优先排序可减少关键项延迟；容量预留可降低长时间的关键项延迟。所有者层面分析进一步表明，可用容量仅在需求发生处或可通过相关专业知识连接转移时才有用。这些发现支持将漏洞修复视为流量控制和容量分配问题，而非仅排名问题。
英文摘要
As AI accelerates vulnerability discovery, remediation throughput may become a greater constraint than prioritisation accuracy. This study evaluates vulnerability remediation as a flow-control problem using Apache Jira, Mozilla Bugzilla, Red Hat security errata, five public Jira organisations, and an npm dependency graph. Apache resolution times are strongly heavy-tailed, while 94-100% of arrivals in the primary issue trackers enter queues estimated to be at or above capacity. Queue-context models provide only moderate predictive discrimination and are largely matched by simple project-level baselines. Severity-to-speed discrimination varies substantially across systems. Flow-control analyses show larger operational effects: transitions from overloaded to draining queues are associated with shorter resolution times, severity-first sequencing reduces critical-item delay at fixed capacity, and capacity reservation can reduce prolonged critical-item delays. Owner-level analyses further show that available capacity is useful only when it is located where demand occurs or can be transferred through relevant expertise connections. These findings support treating vulnerability remediation as a flow-control and capacity-allocation problem rather than solely a ranking problem.
