#code-audit

共收录 3 条相关安全情报。

← 返回所有主题
👥 作者: Aman Priyanshu, Supriti Vijay, Kimia Majd, Xuhong He, Fraser Burch, Takahiro Matsumoto, Jianliang He, Baturay Saglam, Arthur Goldblatt, Zhuoran Yang, Amin Karbasi

该论文针对语言模型智能体在完整软件仓库上执行安全分析的能力评估问题展开研究。作者指出,当前网络安全领域的评测工作主要关注智能体能否「检测」、「复现」或「修复」漏洞,却很少衡量一个更基础的能力:能否在陌生仓库中准确定位与特定弱点类别相关联的实现文件。为此,论文提出「漏洞定位」(vulnerability localization)这一独立任务,并构建了 Vulnerability Localization Benchmark(VLoc Bench)基准。该基准包含来自 290 个仓库、覆盖六大软件包生态与 147 个 CWE 类别的 500 个真实漏洞案例;每个任务都提供修复前与修复后的仓库快照配对。在漏洞版本快照上,智能体仅获得 CWE 描述与只读终端访问权限,必须返回受影响的文件;在已修补快照上,智能体则需判断所记录的漏洞是否已不存在。作者在统一智能体接口下评估了 27 个语言模型与 4 种静态分析工具。结果显示,仓库级漏洞定位仍然十分困难:表现最好的系统仅达到 0.229 的 File F1,且有 38.4% 的任务没有任何被评估模型给出正确本地化结果。论文进一步发现,更强的定位能力并不等同于修复后的可靠行为——那些能有效识别漏洞文件的系统,在已修补仓库上仍可能报告缺乏依据的位置。该工作将漏洞定位确立为一种独立的仓库级能力,并为研究安全智能体如何搜索易受攻击代码、以及何时应当避免报告提供了实验框架。

💡 推荐理由: 安全智能体正被广泛用于仓库级代码审计与告警收敛,但「定位准」不等于「修复后不误报」。该基准揭示了当前模型在仓库级定位上的真实下限,并暴露修复后仍乱报的可靠性缺口,对构建自动化审计流水线与降低误报噪声有直接参考价值。

🎯 建议动作: 研究跟进

排序因子: 有可用补丁/修复方案 (+3) | 来自 arXiv 其他板块 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.6)
👥 作者: N'Zolieh Ismaël Mahassadi, Raphaël Khoury, Justin Vallé, Abdelwahab Hamou-Lhadj

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

💡 推荐理由: 正则校验几乎无处不在, ReDoS 利用门槛低、影响面广。论文给出实证结论: ReDoS 漏洞数量上升、被利用概率明显高于普通漏洞, 且多款检测工具判定结果严重不一致。这意味着仅靠单一工具做正则安全把关存在漏判风险, 直接影响代码审计与 CI 门禁的设计。

🎯 建议动作: 研究跟进

排序因子: 来自 arXiv 其他板块 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)
👥 作者: Qiushi Wu, Kevin Eykholt, Youngja Park, Xiaokui Shu, Dhilung Kirat, Douglas Lee Schales, Ian Molloy

本文提出 BUGSTONE-E2E,一种将漏洞历史(尤其是 CVE 修复提交)转化为可执行检测规则并自动化验证的端到端框架。当前公共漏洞数据库虽然记录了已知软件缺陷的类型、影响组件和补丁信息,但这些信息主要用于人工查阅,缺乏自动化复用机制,导致相同的不安全编码模式可能仍存在于未关联 CVE 的代码中。BUGSTONE-E2E 首先从经过验证的修复提交中挖掘可复用规则,内容包括扫描锚点(如函数调用模式)、修复语义(具体代码变更逻辑)以及 CVE 溯源信息,并按 CWE 分类和编程语言组织。检测阶段采用漏斗式流水线:早期阶段以轻量级分析处理大量候选代码,例如使用 Tree-sitter 枚举匹配规则锚点的调用点,并通过无 LLM 调用的启发式方法筛除良性模式;后期阶段则对剩余目标使用越来越强且昂贵的模型。具体地,LLM 智能体依据规则检查候选点,随后系统对幸存对象进行重新分类并构建运行时验证,最终生成经过作用域检查的补丁,并通过双向差分测试进行确认。实验基于 2022 年至 2026 年间 19,325 个高危 CVE,识别出 2,710 个修复提交,构建了覆盖 56 个 CWE 家族的 1,033 条检测规则,并封装为 172 个技能。将这些规则应用于 14 个程序时,系统产生了 644 个具有运行时证据的发现。结果表明,CVE 历史可以转换为可执行的工作流,将过去的安全漏洞转化为可复现的检测与修复机制。该研究适合从事自动化代码审计、漏洞挖掘、AI 安全与软件工程交叉领域的安全研究人员。

💡 推荐理由: 该研究提供了一种将大规模历史漏洞数据自动转化为可执行检测规则的方法,显著提升了 CVE 知识的复用效率,有助于蓝队发现未公开但仍存在的同类漏洞,为自动化代码审计和 AI 辅助安全分析提供了新思路。

🎯 建议动作: 研究跟进

排序因子: 有可用补丁/修复方案 (+3) | 影响边界/网络设备 (+5) | 来自 arXiv 其他板块 (+2) | 命中热门研究主题 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)