dcg模糊测试实践：11个Fuzz Target如何守护模式引擎

dcg模糊测试实践：11个Fuzz Target如何守护模式引擎

【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard

dcg（Destructive Command Guard）是一款拦截 AI Agent 执行危险 git / shell 命令的安全护栏工具，它内置了 11 个模糊测试（Fuzz）目标，用"无限刁钻输入"持续轰炸模式引擎，确保任何畸形命令、恶意构造都让 dcg 崩溃不了、误判不了。本文将完整拆解这 11 个 Fuzz Target 的职责分工与设计思路，带你快速理解一个 Rust 安全项目如何用模糊测试守住可靠性底线。

为什么 dcg 需要模糊测试？🛡️

dcg 运行在 AI 编码助手的"命令出口"上：Agent 每发出一条 shell 命令，dcg 都要先解析、归一化、匹配规则，再决定放行还是拦截。这意味着它的输入面非常"野"：

• 畸形 shell 语法：引号不闭合、反斜杠续行、嵌套管道；
• 未终止的 here-doc（<<EOF没有结尾标记）、超长脚本体；
• 恶意 JSON：钩子（Hook）输入的类型混淆、深层嵌套；
• 对抗性文本：专为触发正则灾难性回溯而构造的字符串。

人工写测试用例永远枚举不完，模糊测试则让 libFuzzer 自动生成并变异海量输入，用程序不变量（invariant）自动判定"对不对"。

快速上手：如何运行 dcg 的模糊测试

整个 fuzz 工程独立在主工程之外，配置见 fuzz/Cargo.toml，基于cargo-fuzz+libfuzzer-sys构建。常用命令：

1. 运行单个目标（以评估器为例）：cargo fuzz run fuzz_evaluate
2. 运行全部 11 个目标：依次cargo fuzz run <target名>，或用 CI 脚本批量执行；
3. 查看语料库：种子语料存放在 fuzz/corpus/ast_matcher_fuzz/ 与 fuzz/corpus/heredoc_fuzz/，例如bash_rm_rf、unterminated_python等文件，分别覆盖了 bash 递归删除、未终止 Python 脚本等典型场景。

💡 小提示：每个目标都对输入大小做了上限（如 10_000 字节），避免超大输入浪费变异时间——这是工程上的常见取舍。

11个Fuzz Target全景清单 📋

入口层：评估器与钩子解析

• fuzz/fuzz_targets/fuzz_evaluate.rs—— 直接轰炸evaluate_command主入口。它会用git、rm、docker、kubectl、psql等 8 个关键词组合反复评估，专找正则灾难性回溯与内存问题；
• fuzz/fuzz_targets/fuzz_hook_input.rs—— AI 助手通过 JSON 把命令喂给 dcg，这个目标验证类型混淆、深层嵌套等攻击下解析器只会"优雅报错"。

解析层：分词、归一化与 AST 提取

• fuzz/fuzz_targets/fuzz_context.rs—— shell 分词器负责区分"被执行的部分"与"纯数据部分"，fuzz 验证每个 span 的起止字节都落在命令长度之内；
• fuzz/fuzz_targets/fuzz_normalize.rs—— 归一化会剥离路径前缀，目标验证其幂等性：归一化两次与一次结果必须完全相同，这是规则命中率的基石；
• fuzz/fuzz_targets/fuzz_shell_extract.rs—— 针对 tree-sitter（经 ast-grep）的 bash AST 命令提取，确保解析器面对任意字节流都能安全失败。

here-doc 专题：三个单元 + 一个集成 📄

dcg 支持识别python <<EOF ... EOF这类内嵌脚本（设计见 docs/adr-001-heredoc-scanning.md），fuzz 套件也按"分层"思路配置了三枚单元目标：

1. Tier 1 触发：fuzz/fuzz_targets/fuzz_heredoc_trigger.rs 验证check_triggers()与matched_triggers()两个接口结论永远一致，杜绝"触发却说没触发"的逻辑裂缝；
2. Tier 2 抽取：fuzz/fuzz_targets/fuzz_heredoc_extract.rs 检查抽取体不超过ExtractionLimits（10_000 字节 / 1_000 行 / 5 个 here-doc / 20ms 超时）；
3. 语言识别：fuzz/fuzz_targets/fuzz_heredoc_language.rs 用 shebang、命令名、内容三种启发式交叉探测，验证对怪异输入不越界。

集成的fuzz/fuzz_targets/heredoc_fuzz.rs更精巧：首字节选择命令包装器、次字节选择解释器语言、其余字节作为脚本体——让变异始终贴着"真实 shell 结构"发生，同时自由产生未终止、非执行的 here-doc。

匹配层：fail-open 是硬指标 🎯

fail-open（失败放行）是 dcg 模糊测试里最重要的设计哲学：解析器超时、语法不支持、模式编译失败时，宁可放行也不让 Agent 被"卡死"或误拦。

• fuzz/fuzz_targets/ast_matcher_fuzz.rs用 10ms 超时与 0ms 超时两套匹配器对照测试：find_matches报ParseError/Timeout时，has_blocking_match必须返回"不拦截"，且所有命中的行号、字节偏移都落在字符边界上；
• 配合语料 fuzz/corpus/ast_matcher_fuzz/bash_rm_rf 等种子，持续逼近匹配器边界。

扫描层：八类 CI/DevOps 文件提取器

fuzz/fuzz_targets/fuzz_scan_extractors.rs一次性轰炸 8 个扫描提取器：Dockerfile、Makefile、GitHub Actions、GitLab CI、Docker Compose、package.json、Terraform、shell 脚本。断言朴素但关键：行号必须 ≥ 1、提取器 ID 非空——保证dcg scan输出永远可定位。各提取器的行为规格可参考 docs/scan/github-actions-extractor-v1-spec.md 与 docs/scan/dockerfile-extractor-v1-spec.md。

这套 Fuzz 体系好在哪？✨

• 分层覆盖：从字节输入 → 解析 → 归一化 → 规则匹配 → 扫描输出，每一层都有独立目标，问题定位精确到模块；
• 不变量驱动：不是"不崩就赢"，而是幂等性、span 边界、fail-open 等可证明的性质被写成断言，fuzz 即回归测试；
• 贴近真实攻击面：here-doc 集成的"包装器 + 语言 + 脚本体"三段结构，让随机变异也产生高价值样本。

总结

dcg 的 11 个 Fuzz Target 构成一张"分层防护网"：入口层守住进程存活，解析层守住边界与幂等，here-doc 专题守住内嵌脚本管线，匹配层把 fail-open 变成硬约束，扫描层保证报告可定位。对想给自家 CLI 工具加模糊测试的团队来说，这套"按模块切目标、用不变量做断言"的做法，是一份值得直接抄的清单。

【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard