本文研究的是 ReDoS(正则表达式拒绝服务)这一软件弱点及其检测工具生态。ReDoS 的成因是: 当正则表达式被用于校验用户可控输入时, 某些正则的匹配过程会退化为指数级(或超线性)时间复杂度, 攻击者只需构造特定输入即可让服务端线程长期占用 CPU, 最终导致服务不可用。论文围绕两个目标展开实证研究。第一项工作是工具评测: 作者选取三套数据集, 对五款公开可用的 ReDoS 检测工具以及一款正则修正/修复工具进行横向对比, 考察它们在'给定正则是否易受 ReDoS 影响'这一判定上的有效性与一致性。第二项工作是对 NVD(国家漏洞数据库)中所有已上报的 ReDoS 漏洞条目做系统性实证分析, 刻画这类漏洞在数量、时间趋势、受影响组件类型等方面与非 ReDoS 漏洞的差异, 从而提炼关于该弱点类别的整体认识。论文的主要发现有三点: (1) ReDoS 漏洞正变得越来越普遍, 在漏洞报告中占比持续上升; (2) 与非 ReDoS 漏洞相比, ReDoS 漏洞被实际利用的可能性显著更高; (3) 不同检测工具对同一个正则是否脆弱的判断存在明显分歧, 说明当前工具之间缺乏统一的判定标准与权威基准, 检测结论高度依赖所选工具。该研究对开发团队、代码审计人员和安全工程团队在选择与评估 ReDoS 防护工具、设计正则审查流程方面具有直接参考价值, 也指出了构建更可靠检测基准的方向。适合关注应用层拒绝服务、输入校验安全、SAST/代码审计工具选型的研究者与工程人员阅读。

本研究针对软件漏洞修复中的一个盲点展开：一个漏洞往往并非由一个安全补丁（SP）就能彻底解决，而是可能通过多个补丁增量修复、跨维护分支传播或在相关代码库中复制完成。由于现有漏洞数据库通常只记录部分补丁，下游用户可能只应用了部分修复，导致漏洞未被完全修补。为了量化并理解这一“多补丁漏洞”现象，作者首次开展了大规模实证研究。他们合并了四个主流漏洞数据库，构建了一个包含 6,053 个多补丁 CVE 和 16,260 个补丁的数据集，发现约 20.6% 的已修补 CVE 实际涉及多个补丁，且合并数据库比任何单一来源能多识别 36%-55% 的多补丁 CVE。研究进一步剖析了漏洞关联多个补丁的根本原因，提出了包含 6 大类和 16 个子类的两级分类体系。基于这些发现，作者设计并实现了 SPectre——一个由分类体系驱动的补丁完整性发现原型。在 300 个多补丁 CVE 上，经过人工校验真实补丁集，SPectre 在仓库内场景的补丁覆盖召回率达 0.927，跨仓库场景达 0.873。针对另外 100 个被所有公开数据库标记为“单补丁”的近期 CVE，SPectre 又额外发现了分布在 20 个 CVE 中的 28 个未被记录的补丁。研究表明，多补丁漏洞既普遍又被系统性地低估，这为补丁完整性意识、漏洞数据库治理及关系感知型安全工具设计提供了实证依据。适合漏洞管理研究者、安全运维人员以及软件供应链安全工具开发者阅读。

自动化漏洞发现技术已经大大降低了寻找漏洞的专业门槛，使得以往依赖专家稀缺注意力的“保护”不再有效。当前行业重点放在漏洞的发现与修复上，且两者的成本都在下降。本文作者认为，决定系统暴露程度的关键并非单纯的成本曲线，而是发布决策时的“修复覆盖率”（remediation coverage）——即在产品发布前已识别漏洞中被修复的比例，以及组织决定带到发布中的已知、已评估但未修复漏洞的残留部分。文章进一步提出四个论点：第一，这些残留漏洞并非所有已发现漏洞的随机样本，因为分诊（triage）会按修复成本排序，而成本高昂的情况通常具有架构性根源，难以快速解决；第二，被推迟处理的漏洞积压本身就是一项具有高价值的情报资产，反映出组织技术债和风险偏好的深层次信息；第三，当内部文件记录了对漏洞的知晓，就会在法律和市场上改变组织的地位，形成逆向选择——软件价格无法体现这一风险；第四，现有的监管工具均依赖于第三方观察到的利用行为，没有任何一项会在“内部获知”时触发，于是厂商知晓的内容与其必须披露之间的差距完全由厂商自己掌握。文章还研究了CISA的《约束性操作指令26-04》（Binding Operational Directive 26-04），将其视为能说明解决方案必备条件的唯一例外。最后，作者指出“发布覆盖率”目前并不被度量，而度量和公开它正是让责任、保险和采购机制发挥作用的前提条件。

该论文针对软件开发中安全漏洞发现与修复的滞后性问题，提出了一种通用且自动化的静态应用安全测试（SAST）工具集成流程。研究背景指出，SAST 工具虽能有效检测漏洞，但因误报率高、缺乏对原生流水线的支持等可用性问题，在企业中的广泛采用受到阻碍。作者设计了一个聚合 SAST 工具输出并将其接入开发者熟悉的缺陷跟踪系统的过程，从而在开发生命周期内简化安全漏洞的识别与沟通，提升修复效率。该流程是通用化的，不绑定特定工具或平台，但论文以 SonarQube 为 SAST 工具，在基于 GitLab 的开发环境中完成了实证实现。实验结果显示，开发者对该结构化实现、实时反馈和主动漏洞管理持积极态度，尽管存在学习曲线以及安全编码与工作流中断之间的权衡等挑战，但整体上对安全意识和响应能力的正面影响表明，该流程有望增强软件开发实践的安全态势。论文主要贡献在于提出一种可落地、可复用的 SAST 集成模式，减少安全工具与开发工作流之间的摩擦，使漏洞信息能够更早、更直接地触达开发者。适合关注 DevSecOps、应用安全工具链优化及安全开发流程改进的安全工程师、DevOps 团队和软件开发管理者阅读。

本文研究 Linux 内核漏洞的跨版本可利用性评估问题。具体而言，给定一个在特定内核版本上成功利用漏洞的 exploit，目标是判断同一漏洞在其他内核版本上是否也可被利用。现有唯一可用的解决方案是自动生成漏洞利用（AEG），但由于 AEG 基于模板驱动且忽略现有 exploit 所提供的能力，因此并不适合该任务。为此，作者提出一种新方法——自动漏洞利用迁移（AEM）。其核心观察是：exploit 所采用的利用策略通常也适用于其他可利用的内核版本。技术上将 exploit 可正常工作的内核版本作为参考版本，通过调整 exploit 迫使其他内核版本与参考版本对齐，从而在其他版本上复现相同的利用行为。为降低开销并提高可行性，作者策略性地识别真正影响利用执行的关键点，仅对这些点进行强制对齐。作者设计并实现了 AEM 原型，在 67 个需要迁移的案例中，成功迁移 56 个，成功率达到 83.5%。该研究为蓝队评估漏洞在多版本内核中的实际威胁提供了新的自动化思路，有助于安全团队更准确地判断漏洞影响范围，从而优先修复高风险版本。适合内核安全研究者、漏洞管理工程师和安全运营团队阅读。

本文针对AI编程代理（AI coding agents）在安全治理中面临的一个现实困境：现有安全框架虽已识别出过度代理权限、过度授权、弱任务绑定授权以及代理控制不足等风险，也提供了约束、授权、观察、验证和响应等控制能力，但安全团队仍缺乏一种机制来系统化管理那些跨组件、生命周期长于单次事件的持久化部署实例。为此，作者提出了一种新的安全抽象——'代理姿态漏洞'（Agentic Posture Vulnerability, APV）。APV是一种基于任务条件的漏洞管理抽象，它把某个组合式的代理控制暴露记录为持久化条目。同一个代理姿态在不同任务下可能产生不同的运行时表现，APV将这些表现关联回不变的姿态，并保持开放状态，直到权限收窄、缺失控制被补齐、风险被接受或关闭条件得到验证。作者强调，APV并非提出一种新的根因风险类别，而是将现有关于过度代理、授权不足和控制组合缺陷的问题操作化。论文系统区分了APV与CVE可寻址产品缺陷、OWASP Excessive Agency、Agent基线控制结果以及运行时授权-执行间隙等概念。文中还提供了实践场景描述、阈值化定义、六种常见的APV模式、漏洞生命周期、最小记录结构、控制与关闭矩阵、工具含义以及可测试的研究议程。通过这种方式，作者希望为AI代理的长期安全性和可审计性提供一种标准化的管理方法。该论文适合安全研究员、AI系统开发者和安全运维团队阅读，尤其关注LLM代理在生产环境中的风险治理。

企业网络持续面临高级持续性威胁（APT）的攻击，攻击者利用软件漏洞逐步渗透关键资产。随着披露的漏洞数量增长，资源受限的组织必须优先修补哪些漏洞。现有的漏洞优先级标准（如CVSS）对每个漏洞独立评分，无法评估修补策略在对抗随时间在网络中推进的攻击者时的实际效果。先前的模拟工具采用强化学习（RL）模拟攻击活动，但要么忽略了漏洞管理（即攻击者不受防御阻碍），要么依赖与真实威胁数据脱节的合成网络，因此无法评估策略对抗真实攻击者的表现。为填补这一空白，本文提出了VulnGym，一个用于评估漏洞管理策略的仿真工具。VulnGym模拟一个由RL训练的攻击者，其行为基于真实的APT配置文件（如攻击模式、速度、目标选择），同时防御者执行可配置的修补策略（如基于CVSS分数、资产重要性等）。两者在一个共享且持续演化的网络表示上行动，攻击者的进展直接受防御者修补活动的影响，从而能够对给定策略进行压力测试。实验基于真实世界的漏洞数据（如CVE）和两个APT案例（例如APT29、APT41等，摘要未明确但提及两个APT），结果显示漏洞管理必须根据组织环境、对手行为、网络拓扑和资产关键性进行定制化调整。该工具可帮助安全团队在部署前比较不同修补策略的效果，优化资源分配。

该论文研究了市政机构（市、县等地方政府）网络中持续存在漏洞主机的现象。作者通过大规模互联网扫描数据，结合漏洞数据库和市政基础设施信息，识别并分析了大量未修补的脆弱主机。研究发现，市政机构面临独特的挑战，包括预算限制、人员技术能力不足、业务流程依赖老旧系统、以及缺乏安全优先级等，导致漏洞修复周期显著长于企业环境。论文采用纵向分析方法，追踪同一主机上漏洞的存续时间，并利用统计模型量化关键影响因素。主要贡献包括：1) 量化了市政机构漏洞修复延迟的规模；2) 揭示了一类“不可修补”的主机，其漏洞因业务依赖、合同约束或技术债而无法被修复；3) 提出了针对性的政策和技术建议，例如通过集中化安全运营、强制补丁管理周期、以及使用网络隔离等补偿控制措施。实验使用了来自 Shodan、Censys 等扫描数据源，结合政府公开的 IT 资产清单，覆盖了多个国家的市政网络。研究结果表明，即使高危漏洞已被公开披露并存在可用利用代码，仍有大量市政主机处于暴露状态，平均修复时间超过 6 个月。论文呼吁安全社区关注这一被忽视的群体，并推动资金和技术支持。

企业安全团队常用的修复指标如平均修复时间（MTTR）、SLA合规率、驻留时间或检测延迟等，虽然能反映部分修复效率，但往往掩盖了补丁实际到达资产环境的真实方式——例如通过计划维护窗口、部署环、紧急绕过路径等连续或周期性过程。本文提出了一种面向企业漏洞管理的“修复节奏审计”（remediation-cadence audit）方法，旨在系统性地记录和量化补丁部署的节奏特征。审计指标包括：常规平均滞后时间、发布周期、发布比例、队列几何结构、紧急/常规分流、非部署延迟、局部剩余压力证据以及宣称的速率场景。该方法将连续同均值简化模型与实际发布日历进行比较，输出局部容量判定和日历折扣——即由日历化部署消耗的均值容量占比。通过30天均值的示例数据包，展示了不同部署节奏下的影响：在两月发布列车场景下，日历折扣消耗17.4%的均值容量；月度发布列车消耗5.2%；两周筛查消耗1.3%。在16倍的攻击者调整速率范围内，两月折扣至少保持约12%，月度折扣保持在分辨率敏感的3-8%区间。因此，该审计将节奏评估转化为证据分辨率问题：当折扣相对于剩余压力不确定性或声称的余量显著时，不应单独使用MTTR/SLA作为部署证据。发布几何检查表明，部署环并不能自动恢复连续基准，而队列交错可能有利或有害。该方法是一个可复现的治理诊断工具，而非漏洞优先级排序器。本文适合安全运营负责人、漏洞管理策略制定者以及安全度量研究人员阅读。

本文提出 VeriPort，一个端到端的自动化补丁回溯系统，旨在解决开源依赖中已知漏洞的修复难题。当前，安全补丁通常仅针对最新版本发布，开发者面临两难：要么升级到最新版本（可能引入破坏性变更），要么手动将补丁回溯到旧版本。现有回溯方案只能针对单个指定版本，且无法提供充分证据证明补丁能阻断漏洞利用并保持原有功能。VeriPort 能够根据给定的漏洞公告，将该补丁可扩展地回溯到该包的所有受影响版本。对于每个回溯版本，VeriPort 构建一条证据链，以确认补丁阻断了漏洞利用并保留了预期行为。作者使用 BackportBench 基准测试（包含 128 个回溯任务）进行评估，VeriPort 成功解决了 95.3% 的任务，比现有最佳方案 Claude Code 高出 22.7 个百分点。此外，研究团队将 VeriPort 部署在 169 个高/严重等级 CVE 上，生成了超过 5000 个经过验证的回溯补丁。更重要的是，VeriPort 还发现了 2100 个版本被错误报告为受影响，以及 127 个之前未被识别的脆弱版本（涉及 92 个公告），其中 23 个公告已在上游得到修正（删除了 387 个错误版本，新增了 81 个正确版本）。该论文适合安全工程师、开源维护者和依赖管理工具开发者阅读。

本论文提出了一种名为全球CVE倡议（GCVE）的分散化、开放且可扩展的模型，用于漏洞识别、发布和运营丰富化。论文指出当前漏洞生态系统存在一个关键缺口：集中式系统（如传统CVE）提供严格的控制和广泛认可的标识符，但许多生产者（如安全厂商、开源项目）独立发布公告，缺乏用于发现、关联、丰富和复用的共享框架。GCVE作为一个社会技术标准化努力，结合了自治的GCVE编号机构（GCVE Numbering Authorities）、轻量级分配规则、分布式发布、开放的最佳当前实践（BCP）以及实用的参考实现。该模型在允许参与者根据其运营需求发布的同时，保持全局唯一性。GCVE还拓宽了漏洞记录的概念，涵盖分配、披露、目击（sightings）、拒绝标识符、观察、被利用漏洞信息以及丰富记录。论文描述了GCVE BCP过程如何支持技术互操作性和可修正的运营实践，包括漏洞处理和披露的实用指南。此外，它探讨了扩展机制，包括面向人工智能的扩展，作为一种在不集中控制的情况下演进标准的方式。特别关注了参考实现vulnerability-lookup，它聚合多个来源，支持GCVE发布和消费，实现分布式已知被利用漏洞数据，并支持自动丰富的漏洞数据流。基于MISP生态系统的经验教训，GCVE将漏洞协调不仅视为标识符分配，而且视为集体安全知识生产的开放基础设施。本文适合对漏洞管理、安全数据标准化、分散化系统感兴趣的安全研究人员和工程师阅读。

该研究采用混合方法（问卷调查n1=80 + 半结构化访谈n2=22）调查了GitHub Advisory Database中列出的开源软件（OSS）项目的维护者，探究他们在漏洞管理和平台安全特性方面的观点。研究识别出37个关键方面，发现供应链不信任和缺乏自动化漏洞管理工具是最严峻的挑战。在采用平台安全特性（如私有漏洞报告、安全策略等）时，维护者普遍存在意识不足或认为不必要的认知。令人惊讶的是，即使项目过去曾遭受漏洞攻击，仍有部分维护者继续开放公开漏洞报告，甚至忽略报告。基于这些发现，论文讨论了OSS平台（如GitHub）应如何改进，以及研究社区如何更好地支持OSS漏洞管理工作。适合安全平台设计者、OSS社区管理者以及安全研究人员阅读。

FixV2W利用知识图谱嵌入和历史重映射模式，修正NVD中无效的CVE-CWE映射，提升漏洞管理准确性。