欢迎光临
我们一直在努力

My Fuzzers Won’t Build:当模糊测试卡在“第一步”的真实代价

“ 在安全领域,模糊测试(Fuzzing)被公认为发现漏洞最有效、最具性价比的技术之一。随着OSS-Fuzz等基础设施的普及,越来越多关键开源项目开始依赖持续fuzzing来保障安全。然而,在真实工程环境中,一个被广泛吐槽却长期被忽视的问题反复出现:Fuzzer 还没开始跑,构建就已经失败了。构建失败不仅意味着fuzzing无法执行,更意味着漏洞发现窗口的直接缺失。学术界几乎没有对 fuzzing构建失败进行过系统、量化、可复现的研究。 ”

  • 📄 论文标题:My Fuzzers Won’t Build: An Empirical Study of Fuzzing Build Failures

  • 📅 发表时间: ACM Transactions on Software Engineering and Methodology,2025

  • 🏫 作者单位: 日本九州大学,滑铁卢大学等

  • 💡开源代码: 

     https://github.com/posl/FuzzingBuildLogs-ReplicationPackage

01—方法介绍

论文的核心目标并不是提出一种新的 fuzzing 技术,而是回答一个被长期忽略却极其关键的问题:在真实世界中,fuzzing 为什么会“跑不起来”?

为此,作者基于 OSS-Fuzz 的历史数据,从“规模化统计 + 人工深度分析”两个层面展开研究,整体流程可概括为三步:

① 大规模量化分析

统计 fuzzing 构建失败的发生频率与修复周期。

② 失败日志人工标注

对典型失败构建进行人工分析,提取真实根因。

③ 根因分类与自动化探索

构建失败原因分类体系,并尝试自动识别失败模式。。

图片

图 1. OSS-Fuzz整体框架

小结:这是一篇“不谈算法,专注现实问题”的高价值工程实证研究。

02—关键机制

  • 构建失败并不罕见,约 9% 的 fuzzing 构建会失败,但项目间差异极大。
  • 修复通常很快,超过 80% 的失败可在 24 小时内修复。
  • 失败原因高度多样,共总结出 25 种 细粒度根因。
  • 大量失败与 fuzzing 本身无关,更多源于依赖、环境、构建脚本。
  • 模块

    设计思路

    作用

    构建日志挖掘

    解析 OSS-Fuzz 云端构建日志

    获取真实 fuzzing 构建行为

    失败频率分析

    统计项目级与整体失败率

    量化问题严重程度

    人工根因分析

    逐条分析失败日志

    揭示失败背后的真实原因

    根因分类体系

    归纳共性失败模式

    为维护与自动化提供依据

    小结:论文的价值不在于“模型多复杂”,而在于“问题看得足够清楚”。

    03—实验结果

    作者利用存储在OSS-Fuzz的GCS存储桶中的元数据文件,提取并挖掘出过去构建日志的链接(URL)。使用这些URL,开始挖掘元数据文件中包含的每个构建日志。还从元数据文件中提取了每个构建日志的唯一标识符(哈希值)和创建时间,以便能够建立每个项目模糊测试构建的完整历史时间线。在日志挖掘过程结束时,模糊测试构建日志的总数达到1,223,075条,时间跨度从2017年3月到2022年9月,涉及748个项目。

    (1)实验首先进行初步分析解在模糊测试环境中构建失败的频率,结果见表1。了解构建失败的普遍性有助于在进行模糊测试活动时量化构建管理问题的严重程度。结果发现,所有项目的构建失败率中位数为4.76%,这表明大多数参与OSS-Fuzz的项目都对其模糊测试构建进行了细致管理。

    表1.   每个项目构建失败的绝对次数统计数据,以及所有项目构建失败次数的百分比统计数据

    图片

    (2)为了更好地理解在模糊测试背景下构建维护的成本,实验研究了开发人员修复一个失败的模糊测试构建需要多长时间。结果发现,93%的项目能够及时处理其模糊测试工作量,并在一两个构建周期内修复失败的模糊测试构建。仅有2.12%的初始构建失败需要10次或更多次后续构建才能修复,而0.32%的初始构建失败则需要100次或更多次构建才能修复。

    图2.  修复一个模糊测试构建失败的时间

    图片

    图片

    (3)表2展示了论文描述的标注和合并过程所得的分类结果。通过将相似的根本原因归类,总共得出了11个通用类别。

    表2.  在手动分析失败的模糊测试构建日志时观察到的模糊测试构建失败的根本原因

    图片

    (4)实验验证一个模型是否能学会识别常见的构建失败根本原因类型,即:语料库相关问题(RC7)、下载外部资源时出现问题(RC8)、编译器问题(RC1)、项目依赖性问题(RC9),以及最后与命令和参数相关的问题(RC12)。结果见表3。

    表3.   随机森林(RF)分类器10折交叉验证结果

    图片

    小结:本文为模糊测试开发人员在日常活动中需要注意的构建失败根本原因提供了清晰的分类。定量分析表明:(1)开源社区能够维护其模糊测试基础设施,并及时修复出现的构建问题。(2)大多数失败的构建之后并没有后续的失败构建,这表明开源开发者非常重视安全性。(3)很大一部分模糊测试构建失败是由非模糊测试特定问题引起的。

    📌 总结

    本文首次以大规模实证数据揭示了模糊测试中一个长期被低估的问题——构建失败。研究表明,fuzzing 的挑战并不只存在于“如何发现漏洞”,更存在于“如何长期稳定运行”。

    这项工作提醒我们:如果 fuzzer 跑不起来,再强的测试能力也无从谈起。 

    📣 欢迎留言讨论

    • 你在实践 fuzzing 时,最常遇到的构建问题是什么?

    • 你认为 fuzzing 工具链中,哪些环节最需要自动化支持?

    📌 点赞 + 收藏 + 分享,你的支持,是我们持续解析高水平软件安全论文的最大动力!

    赞(0)
    未经允许不得转载:171主机测评 » My Fuzzers Won’t Build:当模糊测试卡在“第一步”的真实代价
    分享到: 更多 (0)

    评论 抢沙发

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址