AI赋能Fuzzing：让程序崩溃转化为可修复的安全漏洞
AI漏洞猎手（四）：AI赋能Fuzzing——让程序崩溃转化为可修复的安全漏洞
核心观点一句话：AI无法完全替代fuzzer发现所有问题，但它能大幅降低harness开发、crash解读、原因归纳和回归验证的成本。
本文是"AI漏洞猎手"系列第四篇，重点探讨fuzzing技术。这不是关于系统攻击的教程，而是介绍在授权代码和测试环境中，如何借助AI帮助安全团队将"发现崩溃"推进到"修复漏洞"。
重要声明：本文仅讨论授权环境下的fuzzing、崩溃分析、修复和回归测试。不涉及真实目标攻击方法、可复现payload、绕过技术或武器化利用链。
许多团队误以为fuzzing的核心是"生成大量输入"。实际上，工程挑战通常集中在四个方面：harness难以编写、覆盖率提升困难、crash数量过多难以区分、修复后缺少回归验证。
AI适合参与这些环节。AI能够阅读API文档和测试用例，生成harness初稿；能够分析覆盖率报告，建议新的输入构造方式；能够解读crash日志和调用栈，提出原因假设；能够将修复建议转化为回归测试用例。
图1：AI + Fuzzing工作流程
核心要点：AI + Fuzzing的交付成果不是"一个崩溃"，而是一套可复现的证据链和修复闭环。
能否成功运行Fuzzing，第一关在于harness。AI在此处发挥重要作用，因为它能将API调用方式、初始化顺序、对象生命周期、异常处理和现有测试用例串联起来。
图2：生成Harness所需的上下文信息
上下文
作用
AI应输出
验收标准
API文档
明确入口函数和参数定义
harness草案说明
可正常编译
初始化逻辑
构建依赖对象和环境
初始化步骤
不依赖生产服务
输入格式
约束结构化输入
输入解析策略
不越权访问
异常处理
区分预期失败和异常情况
失败分类
日志记录清晰
现有测试
学习标准调用方式
复用示例和断言
覆盖核心路径
构建脚本
接入编译和运行
构建说明
CI可复现
需注意，AI生成的harness通常无法一次就完美通过。正确做法是让编译器和测试框架反馈错误信息，再让模型进行迭代优化。模型负责缩短试错时间，工具负责验证是否正确。
Fuzzing质量不仅看运行时间，更要看是否进入关键代码分支。AI能够阅读覆盖率报告，分析哪些分支未被执行，然后提出新的seed或结构约束建议。
图3：覆盖率反馈循环
观察
AI分析方向
工具验证
合格结果
某分支未覆盖
输入缺少状态字段或格式头
coverage report
分支覆盖提升
错误路径过多
harness初始化不完整
编译和运行日志
无效输入比例下降
仅覆盖浅层解析
结构生成过于随机
corpus统计
深层函数被触达
运行速度过慢
依赖外部资源或状态过重
性能日志
单次执行成本下降
覆盖提升停滞
需要字典、seed或状态引导
覆盖趋势
有可解释的改进
核心要点：覆盖率不是表面指标，而是判断AI生成的harness是否真正有价值的关键证据。
Fuzzing运行时间长了，最常见的问题不是没有crash，而是crash数量过多。AI适合承担第一轮分诊工作：按调用栈、信号类型、函数名、输入结构和最近代码变更进行聚类分析，再给出原因假设。
图4：Crash分诊漏斗
分诊层级
要做什么
AI可输出
必须由工具确认
去重
合并同一栈或同一根因
聚类说明
crash signature
稳定复现
判断是否稳定触发
复现条件描述
重跑结果
最小化
减少无关输入
最小用例思路
reducer输出
根因假设
关联代码路径
可能根因和证据
调用栈、源码、测试
影响判断
判断是否涉及安全影响
CWE映射和范围
人工审计
修复回归
验证问题已关闭
回归测试建议
CI和fuzzer重跑
AI提出的根因假设不等于事实。AI可能将表象崩溃误认为根因，也可能忽略上游状态污染问题。必须通过重跑、最小化、sanitizer和人工review来约束AI假设。
假设一个解析库处理嵌套消息。Fuzzer发现崩溃后，AI可以读取栈信息，定位崩溃点附近的长度检查、状态转换和异常处理。AI可以提出三个候选根因：长度字段与缓冲区不匹配、状态机缺少非法状态分支、递归深度无上限控制。
下一步不是编写攻击步骤，而是补充证据。安全工程师让工具最小化用例，确认同一根因稳定复现；再补充一个回归测试，描述"此边界条件必须被拒绝或安全处理"；最后让AI辅助生成修复说明和影响范围。
交付物
内容
用途
Crash摘要
触发模块、栈位置、重复性
快速分诊
根因假设
边界检查、状态机、资源限制
指导人工审计
最小用例说明
抽象输入结构和触发条件
回归测试
修复建议
增加校验、限制或异常处理
研发执行
回归结果
单测和fuzzer重跑结论
关闭漏洞
图5：Fuzzing证据包
证据
说明
不合格表现
构建记录
使用的分支、编译选项、sanitizer
无法复现环境
覆盖率
覆盖到哪些模块和分支
只跑到浅层解析
Crash日志
栈、信号、重复性和聚类
仅有截图或口头描述
最小用例
抽象触发条件和最小测试
沉淀可滥用细节
Patch
修复约束和代码变更摘要
只改表象错误
回归结果
单测、fuzzer重跑和CI结果
没有验证问题关闭
核心要点：Fuzzing报告要能被研发复现、理解和修复，但不能沉淀可被滥用的攻击材料。
编号
检查项
合格标准
1
授权范围
只在授权仓库和隔离测试环境运行
2
Harness可编译
编译、运行和CI可复现
3
覆盖率指标
能看到覆盖率变化和未覆盖分支
4
输入边界
不使用真实敏感数据或外部目标
5
Crash去重
同类崩溃被聚类，不重复建单
6
稳定复现
关键问题能重跑验证
7
最小化
只保留修复所需的抽象证据
8
根因复核
AI假设必须由工具和人工确认
9
修复回归
修复后有单测和fuzzer重跑
10
经验沉淀
harness、规则、测试进入基线
能够生成初稿并快速迭代，但高质量harness仍需要编译、覆盖率和人工review验证。
不等于。Crash需要经过稳定复现、根因确认、影响判断和修复回归，才可能进入漏洞管理流程。
覆盖率是重要指标，但不是唯一指标。关键是覆盖到安全敏感路径，而不是机械追求数字。
最大风险是把表象当根因。解决办法是用最小化、重跑、sanitizer和源码证据约束模型。
建议先选择稳定库或内部解析模块做试点，目标是跑通harness、覆盖率、crash分诊和回归闭环，不要一开始就追求全仓库自动化。
AI让fuzzing从"少数专家能玩"变成"安全工程流水线的一部分"。但它真正改变的不是fuzzer的本质，而是让harness、triage、报告和回归这些工程环节更快闭环。
值得收藏的一句话：AI + Fuzzing的价值，不在于制造更多崩溃，而在于更快判断哪些崩溃值得修、怎么修、如何证明已经修好。
·[1] Google Project Zero, Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models https://projectzero.google/2024/06/project-naptime.html
·[2] Google Project Zero, From Naptime to Big Sleep https://projectzero.google/2024/10/from-naptime-to-big-sleep.html
·[3] Google Security Blog, AI-Powered Fuzzing: Breaking the Bug Hunting Barrier https://security.googleblog.com/2023/08/ai-powered-fuzzing-breaking-bug-hunting.html
·[4] OSS-Fuzz, LLM target generation https://google.github.io/oss-fuzz/research/llms/target_generation/
·[5] GitHub CodeQL Documentation https://codeql.github.com/docs/
·[6] GitHub CodeQL, Data flow and taint tracking https://codeql.github.com/docs/writing-codeql-queries/about-data-flow-analysis/
·[7] Semgrep Docs, Semgrep Code https://semgrep.dev/docs/semgrep-code/overview
·[8] DARPA, AI Cyber Challenge https://www.darpa.mil/research/programs/ai-cyber
·[9] MITRE CWE https://cwe.mitre.org/
·[10] NIST SP 800-218, Secure Software Development Framework https://csrc.nist.gov/pubs/sp/800/218/final
·[11] OWASP Top 10 for LLM Applications https://owasp.org/www-project-top-10-for-large-language-model-applications/