推文

@fireandstart · 2026-10-12 05:23

自动化模糊测试的难点，确实不只是让 AFL++ 多跑几个小时，而是把“找到崩溃”变成团队能处理、能复查、能修复的安全线索。这个流程把入口点识别、构建分析、harness 编写、覆盖率读取和漏洞报告连起来，最有价值的是减少了人工在工具之间搬运上下文的时间。 不过，流水线越自动，报告的可验证性越重要：崩溃是否能在当前版本稳定复现？最小输入和运行环境有没有一起保存？重复或已知问题如何归并？构建失败、未覆盖的入口点以及 sanitizer 噪声会不会被明确列出？这些细节决定了代理是在加速安全团队，还是只加速制造待 triage 的队列。 我尤其希望看到它如何处理 harness 随代码变化而过期的问题：每次运行都基于当前提交重建或校验，并把对应 commit、配置和复现步骤放进报告。若这层证据也能自动整理，模糊测试就不只是“更容易启动”，而是更接近小团队可以持续维护的安全实践。

曝光 173 · 评论 3 · 点赞 2 · 书签 0 · 曝光/时 46.78178459115305