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_guarddcgDestructive Command Guard是一款拦截 AI Agent 执行危险 git / shell 命令的安全护栏工具它内置了 11 个模糊测试Fuzz目标用无限刁钻输入持续轰炸模式引擎确保任何畸形命令、恶意构造都让 dcg 崩溃不了、误判不了。本文将完整拆解这 11 个 Fuzz Target 的职责分工与设计思路带你快速理解一个 Rust 安全项目如何用模糊测试守住可靠性底线。为什么 dcg 需要模糊测试️dcg 运行在 AI 编码助手的命令出口上Agent 每发出一条 shell 命令dcg 都要先解析、归一化、匹配规则再决定放行还是拦截。这意味着它的输入面非常野畸形 shell 语法引号不闭合、反斜杠续行、嵌套管道未终止的 here-docEOF没有结尾标记、超长脚本体恶意 JSON钩子Hook输入的类型混淆、深层嵌套对抗性文本专为触发正则灾难性回溯而构造的字符串。人工写测试用例永远枚举不完模糊测试则让 libFuzzer 自动生成并变异海量输入用程序不变量invariant自动判定对不对。快速上手如何运行 dcg 的模糊测试整个 fuzz 工程独立在主工程之外配置见 fuzz/Cargo.toml基于cargo-fuzzlibfuzzer-sys构建。常用命令运行单个目标以评估器为例cargo fuzz run fuzz_evaluate运行全部 11 个目标依次cargo fuzz run target名或用 CI 脚本批量执行查看语料库种子语料存放在 fuzz/corpus/ast_matcher_fuzz/ 与 fuzz/corpus/heredoc_fuzz/例如bash_rm_rf、unterminated_python等文件分别覆盖了 bash 递归删除、未终止 Python 脚本等典型场景。 小提示每个目标都对输入大小做了上限如 10_000 字节避免超大输入浪费变异时间——这是工程上的常见取舍。11个Fuzz Target全景清单 #目标被测模块守护的不变量1fuzz_evaluate主评估器任意命令不得 panic、不得灾难性回溯2fuzz_hook_inputHook JSON 解析畸形 JSON 只报错、不崩溃3fuzz_contextshell 分词器所有 span 边界必须合法4fuzz_normalize命令归一化归一化幂等normalize² normalize5fuzz_heredoc_triggerhere-doc 触发检测触发结果与匹配集合严格一致6fuzz_heredoc_extracthere-doc 内容抽取抽取体受上限约束无漏报7fuzz_heredoc_language脚本语言识别启发式探测永不越界8fuzz_shell_extractbash AST 提取tree-sitter 解析不 panic9heredoc_fuzzhere-doc 集成管线失败必须fail-open而非 panic10ast_matcher_fuzzAST 模式匹配器解析错误/超时一律放行不拦截11fuzz_scan_extractors8 类文件扫描提取器行号 ≥ 1、提取器 ID 非空入口层评估器与钩子解析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.mdfuzz 套件也按分层思路配置了三枚单元目标Tier 1 触发fuzz/fuzz_targets/fuzz_heredoc_trigger.rs 验证check_triggers()与matched_triggers()两个接口结论永远一致杜绝触发却说没触发的逻辑裂缝Tier 2 抽取fuzz/fuzz_targets/fuzz_heredoc_extract.rs 检查抽取体不超过ExtractionLimits10_000 字节 / 1_000 行 / 5 个 here-doc / 20ms 超时语言识别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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考