AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载导读本文以 Trail of Bits 开源的 Claude Code 技能插件mutation-testing位于 plugins/mutation-testing/README.md为核心系统讲解如何配置变异测试mutation testingcampaign、解读存活变异体surviving mutants揭示的测试缺口并借变异结果反向排查原代码中的潜在缺陷。读完本文你将掌握mewt/muton的完整命令行工作流、五阶段配置与优化方法、等价变异体判定程序、严重度分级标准以及如何复现和验证该插件自带的评估用例。一、插件定位一个技能覆盖三种工作流mutation-testing插件仅内置一个同名技能通过/mutation-testing:mutation-testing调用或直接向 Agent 描述变异测试需求即可触发。技能入口文档 SKILL.md 将请求路由到三个独立工作流请求类型技能行为搭建或优化 campaign配置mewt或muton检查目标选择实测测试耗时调优超时与按目标per-target的测试命令分析已完成的结果逐个读取存活变异体对应的源码与测试区分等价变异与测试缺口并在mutation-testing-report.md中给出具体的断言或输入建议调查潜在 Bug以存活变异体为地图优先排查原代码在产出可复现的 PoC 之前不得把某个缺陷描述为已确认值得注意的是一个存活变异体只意味着测试未检测到一次人为注入的改动——它可能揭示测试缺口也可能是等价实现。它本身并不能证明原代码存在 Bug。因此分析工作流只负责给出测试改进建议不会替用户实现或修改测试代码。技能的适用与排除边界同样明确用户提到 mewt、muton、mutation testing、配置/加速 campaign、分析存活或等价变异体、以及用变异结果找 Bug 时使用而纯粹讨论行覆盖率、与变异测试无关的测试问题时不应调用此技能。二、前置条件与工具约定Campaign 搭建依赖 mewt 或 muton 之一外加一套可运行的测试套件。文档中的示例均遵循mewt 4.x APImuton 与 mewt 共享相同接口只需把命令名替换为muton并把文件名替换为muton.toml、muton.sqlite。安装后应以mewt --help与mewt subcommand --help为准——技能明确规定命令行行为以--help为准示例反映 mewt 4.x API遇到陌生 flag 或命令失败时先查--help。分析已保存的结果则不需要安装任何工具只需提供 campaign 输出、变异位点处的源码与相关测试即可。分析工作流同样接受来自其他变异测试工具如 slither-mutate、mull、dextool-mutate的结果其解析锚点见 references/input-formats.md。三、核心命令速查从初始化到复核技能在 SKILL.md 中给出了完整的 Essential Commands按生命周期阶段整理如下# 搭建与运行 mewt init # 创建配置与数据库mewt.toml mewt.sqlite mewt mutate [paths] # 只生成变异体不运行测试 mewt run [paths] # 生成变异体并运行整个 campaign # 读取结果 mewt status # 总览含按文件的细分 mewt results # 默认视图未捕获Uncaught的变异体 mewt results --all # 展示所有结果而不只是 Uncaught mewt results --format json # 输出格式json | sarif | ids | table # 缩小范围以下过滤器同时作用于 results 与 print mutants mewt results --target src/auth/** # 用引号包裹 glob避免被 shell 展开 mewt results --severity high,medium mewt results --mutation-types ER,CR mewt results --status Uncaught # Uncaught | TestFail | Skipped | Timeout mewt results --line 42 # 调查与重测 mewt print mutant --id [id] # 查看被改写的代码 mewt test --ids [ids] # 重测指定变异体 mewt test --ids-file uncaught_ids.txt # 从文件读 ID 重测- 表示从 stdin 读 # 检查配置 mewt print config # 生效中的配置 mewt print targets # 实际被变异的文件 mewt print mutations --language [lang] # 某语言的变异操作与严重度语言标签使用 mewt 4.x 的规范family或family/dialect值例如rust、javascript/ts、move/sui、move/iota。结果状态语义是理解输出数据的根基Caught/TestFail测试检测到了注入的改动好事Uncaught测试未检测到改动需要查看代码以区分是测试缺口还是等价变异Timeout测试超时——结果不确定不能作为覆盖证据Skipped同一行存在更高严重度的未捕获变异体因此跳过了较低严重度的那个。变异操作符语义以mewt print mutations --language [lang]的输出为权威来源操作符集合随每个版本增长但输出并不会告诉你存活变异体的含义——这正是优先级排序的来源严重度代表 slug未捕获变异体意味着什么HighERError Replacement错误替换测试容忍了被注入的错误。需调查该路径是否被执行、错误处理是否掩盖了改动、断言是否真的校验了结果MediumCRComment Replacement注释/语句替换移除该语句不会导致测试失败。需检查其副作用是否重要、断言是否观察到这些副作用MediumIF/ITIf False/True条件恒假/恒真、NRNegation Removal取反移除测试区分不了被改写的条件。两个常量替换都存活可能意味着条件从未被执行或对分支结果的断言太弱Low操作符重排AOS、COS、LOS、BOS、位移/赋值变体、BL、AS、LC、WF需检查边界输入、算术断言与语义等价性。变异结果本身无法证明代码是否被执行关键提醒严重度衡量的是变异操作本身而非风险。一个低严重度、发生在费用计算里的存活体可能比一个高严重度、发生在日志行里的存活体更重要——判断依据是被改动代码的功能而不是操作符标签。可配合--severity过滤器按优先级逐个处理结果。四、工作流一五阶段配置与优化配置工作流的目标是让用户能以兼顾彻底性与执行时间的最优设置运行mewt run。完整流程见 workflows/configuration.md这里浓缩其五个阶段。Phase 1初始化并校验目标mewt init # 生成 mewt.toml 与 mewt.sqlite若配置放在非标准位置用--config path/to/mewt.toml指定——配置文件所在目录的父目录会成为工作目录配置中的相对路径也以此为基准解析。随后mewt print config # 查看自动生成的配置校验[targets]模式include应只匹配源码src/、lib/、contracts/ignore应排除测试、依赖与生成代码。注意 ignore 模式是子串匹配例如test会命中tests/与test_utils.rs。[targets] include [src/**/*.rs] # 只匹配具体源码目录 ignore [test, mock] # 排除 src/ 内的 test/mock 文件Phase 2生成变异体并评估规模mewt mutate src/ # 输出按目标的严重度细分--verbose 可看单个变异体 mewt status # 查看变异体总数 mewt print targets # 展示实际被变异的文件 time test-command-from-config # 例如 time cargo test记录基线耗时最坏情况时长估算公式变异体数量 × 单次测试耗时。例如 500 个变异体 × 10 秒 ≈ 1.4 小时。实际运行通常会更快测试会快速杀死变异体skip 机制也会降低负载。Phase 3决策优化策略按预估时长走决策树 1 小时直接进入 Phase 41–16 小时询问用户能否接受通宵/下班后运行不接受则应用优化 16 小时必须探索优化方案。需要优化时读取 references/optimization-strategies.md其优先级顺序为核实目标选择最常见问题用mewt print config/mewt print targets排查是否变异了 mocksrc/mocks/、__mocks__/、测试*_test.rs、*.test.js、tests/、依赖vendor/、node_modules/或生成代码proto/、generated/分析项目结构mewt print mutants --target src/auth/**/*.rs --format ids | wc -l统计各组件变异体数并按--severity high/medium/low或--mutation-types ER统计严重度分布注意严重度占比在代码库之间差异巨大15% 到 50% 都属常见向用户呈现带时间估算的四个选项见下节将选中方案写入mewt.toml。若[targets]或[run].mutations发生变更需要更新数据库并重算时长# 缩小目标范围Option Bpurge 移除不再匹配 [targets].include/ignore 的目标 mewt purge mewt mutate src/ # 为新纳入的文件补变异体 mewt status # 确认变异体数量下降 # 限制变异类型Option C已有变异体可能失效必须全量重建 mewt purge --all mewt mutate src/ mewt statuspurge 会删除已保存的变异体与结果——执行前务必保留需要留存的产出并确认丢弃相关 campaign 数据已获授权。Phase 4校验测试命令与超时默认情况下 mewt 自动计算超时基线测试时间 × 2多数情况可覆盖增量重编译的开销。例外场景是重编译开销主导测试时间的编译型语言如 Solidity/Foundry需实测验证time forge test # 热缓存下例如 0.8s touch src/Contract.sol # 模拟变异触发依赖重编译 time forge test # 例如 5.2s若重编译时间远大于测试时间则在mewt.toml中手动设置超时[test] cmd forge test timeout 11 # 依据5.2s × 2 10.4s向上取整否则省略timeout交给 mewt 自动计算。Phase 5最终校验清单mewt print config— 配置语法有效、无报错mewt status— 变异体数量符合预期mewt print targets— 只变异了目标文件无测试/mock/依赖测试命令已验证Phase 2 或 4 中实测通过超时已设置自动或针对重编译重型语言手动设置时长估算用户可接受全部通过后即可运行mewt run。执行时机建议 1 小时随时可跑1–16 小时放在下班前启动、次日清晨收结果16–48 小时建议周五晚启动、周一收结果两阶段方案则第一阶段过夜、第二阶段次日。配置参考完整 mewt.toml 模板db mewt.sqlite [log] level info # trace, debug, info, warn, error [targets] # 务必具体只含源码绝不含测试/依赖 include [src/**/*.js, lib/**/*.js] ignore [test, mock] # 子串匹配不是 glob [run] # 可选限制变异类型省略则测试全部 # mutations [ER, CR, IF, IT] [test] cmd npm test # timeout 30 # 可选省略时自动计算2× 基线 # 按目标覆盖规则第一个匹配优先 [[per_target]] glob src/core/*.js test.cmd npm test -- core test.timeout 20各语言的[targets]参考配置# Rust [targets] include [src/**/*.rs] ignore [test, mock, generated] # Solidity [targets] include [contracts/**/*.sol] ignore [test, interfaces, mocks] # Go [targets] include [**/*.go] ignore [test, mock, generated] # JavaScript/TypeScript [targets] include [src/**/*.ts, lib/**/*.ts] ignore [test, spec, mock]编辑后务必运行mewt print config检查无效 TOML 并确认生效配置。优化选项 A–DOption A完整 campaign预估 ~X 小时最坏情况实际通常更快适合时长可接受、追求全面覆盖的场景Option B聚焦关键组件先只变异src/auth/等关键组件快速迭代评审后再逐步扩围Option C仅高/中严重度[run]中设置mutations [ER, CR, IF, IT]约覆盖 30–40% 的变异体也可不改数据库、直接用mewt results --severity high,medium在分析期过滤保留灵活性Option D两阶段 campaign仅适合集成测试主导的套件Phase 1 用[[per_target]]指向快速定向测试Phase 2 用mewt results --status Uncaught --format ids uncaught_ids.txt导出存活体再切换回全量[test]配置并用mewt test --ids-file uncaught_ids.txt复测。示例估算朴素方案 2000 × 45s 25 小时两阶段约 10 小时约 2.5× 提速。注意 Phase 2 时长在 Phase 1 完成前不可预知只能表述为存活数 × 全量套件耗时。排障要点没有生成任何变异体时依次检查语言是否受支持mewt print mutations --language rust、include 模式是否匹配到文件mewt print configfind src -name *.rs | head。文档特别警告排查文件存在性时用find而不是ls src/**/*.rs——**是否递归取决于 shellzsh 会展开bash 需开启 globstarmacOS 自带 bash 3.2 甚至没有 globstar 选项ls在不同机器上会给出不一致的诊断结果而find在所有 shell 中行为一致且无匹配时退出码为 0 而非报错。**请保留在mewt.toml中由 mewt 自己展开。常见原因还包括 ignore 模式过宽test命中test_utils.rs与语言不受支持。测试命令失败时先在项目目录手动运行确认再检查Makefile、justfile、package.json、README.md找正确命令monorepo 中可能需要从 workspace 子目录运行。配置原则总结通过mewt.toml配置而非 CLI flag便于版本控制目标精确指向源码优先限制文件范围而非变异类型campaign 前手动验证测试命令信任自动超时优化前先实测将mewt.toml连同注释一起提交。五、工作流二结果分析——等价变异、严重度与报告分析工作流workflows/analyzing-results.md是工具无关、语言无关的负责识别测试缺口、按严重度分类存活变异体、过滤等价变异体并产出结构化报告。它需要配合等价目录、严重度指南与报告模板三个引用文件使用。必须拒绝的合理化辩解技能明确列出六种要拒绝的借口这是保证分析质量的核心约束kill rate 超过 80%测试套件足够了。——聚合指标会掩盖单个关键缺口访问控制里的一个存活体比日志模块里被杀死的一百个变异体更重要这大概是等价变异体。——等价性必须从类型系统与控制流中证明绝不能假设缺少能区分它的测试不是证明改成这种边界改动总是等价的。——只有当边界值可证明不可达时才等价可达的边界就是真实发现虽然存活了但测试套件在实践中能抓住这个问题。——既然存活套件就抓不住这就是存活的定义只报最高层级就够了。——低层级同样是具体、可行动的测试改进建议事件发射类存活体也能暴露监控与集成所需的缺失断言不读源码我就能分类。——严重度取决于被改代码的功能等价性取决于类型与可达性两者都必须读变异位点的源码。六阶段分析程序解析输入Phase 1识别结果格式。mewt/muton、mutmut、cargo-mutants、mutahunter 大多产出可直接按字段名解析的 JSON/CSV结构不明显的先读前 50 行。对 mewt/muton 项目mewt results --format json可直接给出 Uncaught 变异体。确认字段含文件路径、行号与状态只提取存活/未捕获状态收集上下文Phase 2按文件分组批量读取变异位点确认代码功能、涉及类型、是否可达、是否安全敏感/财务/业务逻辑/可观测性代码过滤等价变异体Phase 3对每个变异体套用五步验证程序见下节严重度分级Phase 4按 references/severity-classification.md 的标准为每个真实缺口分配优先级层级影响不确定时明确说明而不是自动升 tier。这些 tier 只用于排定测试工作的优先级不构成对原程序漏洞严重性的判定分析测试缺口Phase 5按生态惯例定位负责的测试文件src/x.rs→tests/x.rs或#[cfg(test)]模块x.py→test_x.pyx.go→x_test.goX.sol→X.t.sol读出本应捕获该变异体的用例解释它为什么没抓到缺失断言、未覆盖分支、缺失边界用例、输入种类不足、或者执行了代码却没验证输出并给出具体补法加什么断言、用什么输入、覆盖哪个分支。如果根本没有测试触达被改代码必须明说——这比弱断言更强有力的发现写报告Phase 6写入工作目录下的mutation-testing-report.md按报告模板组织。每个统计量都要说明分母skipped/timeout/unresolved 单独列账原始与等价调整后的 kill rate 只在数据支持时给出。报告长度与发现数匹配空 tier 可以省略。分析硬性要求每个存活变异体都要单独分析不得跳读、概括或批量处理按严重度顺序Tier 1、2 优先工作会话可能中断时保存中间进度报告使用正式、客观、第三人称、主动语态、现在时测试改进建议用文字描述而非贴测试代码。等价变异体五步验证程序references/equivalent-mutants.md 定义等价变异体是语义上与原始代码完全一致的变异任何测试都无法杀死它因为不存在可观察差异。判定前必须完成全部五项检查类型上下文确认变异涉及变量的类型——无符号整数、布尔、枚举各有专属等价模式可达性确认被改代码在运行中确实可达——死代码中的变异是平凡等价的下游消费追踪变异后的值是否被后续逻辑读取——从不被消费的值其变异无可观察效果语义比较在类型约束下对全部可能输入比较原始与变异行为若无输入产生不同结果则等价区分性测试尝试尝试构造一个能产生不同行为的输入——若能构造则非等价并把该输入作为推荐测试用例若检查完边界值、类型极值与领域特定边界后仍找不到区分输入则强化等价判定。只有分析确立了可观察行为相同变异体才算等价。某步不确定时保留为 unresolved 并说明缺失的证据——不确定性本身不构成测试缺口。典型等价模式与看似等价实则不然的陷阱确认为等价的模式无符号比较等价x 0变异为x ! 0——对无符号整数不大于零的值只有零本身两者对所有无符号值结果一致。适用于 Rustu8–u128/usize、C/Cunsigned、Solidityuint等。但变量是有符号类型时不成立x 0排除负数x ! 0包含负数布尔双重否定!(!condition)变异为condition——逻辑恒等重言式边界检查无符号x 0变异为true——两者对所有值都为真前提是求值x无可观察副作用。但替换为x 0时不成立x 0时原式为真、替换式为假而零对无符号类型是可达的死代码变异不可达分支内的任何变异冗余赋值赋值后变量从未被读取的变异交换律重排a b→b a、a * b→b * a仅限纯操作数、同类型的内建整数运算重载操作符与浮点语义需单独审查。看似等价但必须当作真实发现的陷阱边界值改动→——边界值产生不同结果除非边界值可证明不可达。常见错误因为当前测试没触发边界就断言其不可达——不可达必须由类型系统或控制流证明不能由测试覆盖推断循环边界 off-by-onei length→i length——多执行一次迭代可能越界访问或处理多余元素移除事件发射emit Transfer(...)被注释掉——虽不改执行逻辑但可能破坏依赖事件的监控、索引服务或集成测试应归为 Tier 4低而非等价交换非交换操作a - b→b - a、a / b→b / a——除非a b结果必然不同引入未定义行为C/C改动使边界检查、指针操作或整数算术引入 UB有符号溢出、缓冲区越界、空指针解引用——今天测试全过不代表等价UB 在不同编译器/优化级别/平台下可能以不同方式显现代表真实的安全缺陷。严重度分级标准Tier 1–4分级依据是被改代码的影响类型而非变异操作符——同一个操作符替换出现在访问控制逻辑里和出现在日志语句里严重度完全不同。tier 只排定测试工作优先级不代表原代码存在漏洞影响不确定时应说明而不是自动升档。Tier 1严重安全敏感代码强制安全不变量。判定条件谁可调用函数的控制访问控制/授权、身份或凭据校验认证/签名、防重入或其他并发攻击、系统边界的外部输入校验、密码学操作哈希/签名/验签、提权路径防护admin 函数/升级。示例assert(caller admin)、签名验签verify_signature、ecrecover、jwt.verify、常量时间比较hmac.compare_digest、login_required等认证守卫Tier 2高财务/状态完整性代码管理资金转账、会计或关键状态转换。判定条件代币/原生币转账、手续费/份额/汇率/利息计算、余额与账本管理、状态机转换顺序、预言机价格、滑点/期限保护、清算或抵押阈值。示例account.balance - withdrawal、fee amount * rate / 100、份额会计、价格/阈值守卫Tier 3中业务逻辑代码实现协议特定行为但不直接处理价值或强制安全边界。判定条件非安全边界的配置/参数校验、数据结构管理数组/映射/队列、协议工作流治理/投票/质押奖励、外部合约集成点、非安全路径的错误处理Tier 4低可观测性与信息性代码不影响执行逻辑。判定条件事件/日志发射、仅用于展示的 view/pure/getter 返回值、错误消息字符串而非 revert 条件本身、NatSpec/文档常量、监控调试输出。示例log::info!、metrics.increment、get_name()。模糊案例裁决规则控制安全敏感阈值如最大签名者数、timelock 超时的配置参数归Tier 1承载价值的合约外部调用的错误处理归Tier 2非价值调用归 Tier 3返回值被状态变更函数消费的 getter如交易中的定价查询、更新前的权限检查归Tier 2而非 Tier 4下游消费者监控、索引器、集成合约、协议标准依赖的事件/日志发射升到Tier 3。区分 Tier 2 与 Tier 3 的试金石这段代码在生产环境出错会导致资金损失或会计错误吗是则 Tier 2否则 Tier 3。报告模板结构references/report-template.md 定义的结构包含执行摘要总变异数、被杀数、存活数、等价数、真实存活数、未决存活数、跳过/不确定数、原始与调整后 kill rate且每个比率注明分母、关键发现、严重度分布表、等价变异体清单表文件/行/变异/等价理由、按 Tier 1–4 组织的逐条发现每条含文件、行、变异前后代码、操作符、上下文、负责的测试文件与用例、为什么没被抓住、推荐改进、按测试文件归组的建议清单、未决案例、以及附录输入文件、含存活体的源文件表、方法论。六、工作流三Bug Hunting——把存活体变成已确认 BugBug 猎手工作流workflows/bug-hunter.md的核心原则是未捕获变异体揭示测试盲区而盲区正是 Bug 藏身之处。但缺失测试不是 Bug它只是去哪里找的信号。该工作流的交付物是带 PoC 复现的已确认 Bug而不是一份覆盖缺口清单只有在调查变异体背后的代码并真正发现问题后才报告一个未捕获变异体。前置条件已完成的 campaignmewt run [paths]且结果可查mewt status。四步流程识别高风险代码用mewt status找有存活体的文件交叉对照敏感性auth、crypto、解析、输入校验、核心业务逻辑用mewt results --target src/auth/**拉取目标区域的存活体。排序优先级低分的关键代码 → 任意分数的关键代码crypto 80% 也值得读→ 低分的核心逻辑 → 其余个体变异体排序按高危险模式表排列见下。立即调查auth/crypto/parsing/validation 中的ER、跨连续行的ER簇、安全代码中IF与IT双双存活、授权检查上的CR。其次调查错误处理路径中的ER、复杂条件中的IF/IT、状态变更操作上的CR、单个函数内多个存活体聚集。低优先级孤立操作符变异、工具函数存活体、死代码那是该清理的技术债不是要调试的 Bug调查 Bugmewt print mutant --id id查看变异读周围函数确立预期行为注意变异注入的缺陷不能证明原程序有漏洞要调查的是原始源码。确定它为何未被测试——死代码/新代码/测试从未触发的边界用例/仅 happy-path 测试背后的错误路径/单元与集成缺口每种指向不同类型的 Bug。评估风险攻击者可控输入能否触达、出错会怎样、是否位于安全边界。按变异类型查找对应 Bug 类ER手工走代码路径、检查静默成功的错误处理与输入校验IF/IT演练未测分支、找 off-by-one 与未处理的 null/空值CR检查语句是否必要、状态变更是否真的发生操作符变异核对比较/算术是否为预期并测试边界。尝试复现写 PoC 测试并运行确认影响——未能复现的假设只能叫疑似 Bug不能叫确认记录发现每条发现含位置、证据变异结果 手动测试、问题、影响与严重度、复现、修复。示例见技能文档中的Expired Tokens Accepted案例src/auth/verify.rs:78的过期令牌校验反转。所有发现分类为confirmed可复现 PoC、已验证影响、likely强证据但未复现、dead code不可达建议清理、not a bug代码正确、测试弱。后两类不进 Bug 清单。若调查确认无 Bug如实报告该结论及其范围与未决案例——这并不等于该区域没有 Bug。高危险模式表ER簇可能意味着未执行代码块或测试容忍错误需先检查执行与断言再选解释一行上IF与IT双双存活意味着测试对两种常量替换都不区分条件可能未执行或两个分支都跑了却没断言结果差异错误处理中的ERcatch 块、错误返回路径意味着失败模式完全未校验一个安全敏感文件里有大量混合类型存活体意味着关键代码覆盖普遍薄弱应手工通读逻辑寻找安全绕过而不是逐个变异体排查。工作方式一次聚焦一个文件/区域集中在优先级最高的 10–20 个变异体——全面覆盖大结果集不是目标高影响力发现才是。存活体过多时果断取舍从 auth/crypto/validation 中的ER开始偏好簇而非孤立变异体接受部分区域无法调查。七、验证体系确定性检查与模型评估插件自带的评估见 README.md 的 Validation 一节使用一次捕获的 campaign 加上一套刻意写得薄弱的 Rust 测试套件。fixture 位于 evals/weak-suite-analysis/fixture其 src/lib.rs 是一个最小化的保险库vaultwithdraw函数有if !is_admin授权守卫、amount account.balance资金守卫与余额扣减而tests/vault.rs只演练一次 happy-path 提现并只断言返回余额导致多个变异体存活。评估要求 Agent 区分balance 0与其两个变异体balance ! 0对u64是等价的而balance 0在零值处有差异——这是核心考点。它还检查授权、余额会计与日志记录方面的缺口。fixture 无需安装 cargo 或 mewt 即可分析。从仓库根目录运行报告校验测试uv run --no-project --with pytest python -m pytest plugins/mutation-testing/tests -q --import-modeimportlib DETERMINISTIC_ONLY1 uv run --no-project bash plugins/mutation-testing/tests/smoke-test.sh校验脚本 tests/validate_report.py 说明了判定逻辑balance 0若被列入等价表即失败它在balance 0处与原式不同且没有测试调用has_funds(0)balance ! 0若未被列为等价即失败对无符号 u64 它与balance 0不可区分。此外还检查报告须有等价变异体章节、Tier 1/Critical 章节必须出现is_admin两个if !is_admin变异体是访问控制缺口属于最高 tier、record_withdrawal与eprintln不得被归档到 Tier 1它们是可观测性代码应归最低 tier、5 个存活行号24/27/31/37/41必须都被引用、报告正文不得少于 500 字节防止 stub。确定性检查只验证 grader 的牙齿不验证技能的有效性。可选的模型评估需要支持插件 eval 的 Claude Code 与ANTHROPIC_API_KEY用同一校验器检查 Agent 的报告uv run --no-project bash plugins/mutation-testing/tests/smoke-test.sh模型评估会在本地保留报告并调用 API可用MODEL、JUDGE_MODEL、RUNS、MAX_COST_USD分别控制模型、评判模型、运行次数与成本上限。一个通过的 fixture 并不证明带技能的 Agent 优于不带技能的 Agent——这是评估设计上明确承认的边界。八、复现捕获的 campaign如果想在本地完整复现那次捕获的 campaign需要在独立的副本上操作避免污染仓库mutation_fixture_dir$(mktemp -d)/vault cp -R plugins/mutation-testing/evals/weak-suite-analysis/fixture $mutation_fixture_dir cd $mutation_fixture_dir cargo test mewt mutate mewt run mewt resultsfixture 中已包含捕获的mewt-results.json与mewt-status.txt供分析流程直接使用。九、总结与实践要点围绕本插件形成的一套可复用的完整实践路径是初始化mewt init→ 严格限定目标[targets]只含源码→ 预估规模变异体数 × 测试耗时→ 必要时优化聚焦组件/限制类型/两阶段→ 验证测试命令与超时 →mewt run→ 分析存活体五步等价判定 四级严重度→ 输出mutation-testing-report.md→ 对高危区域做 Bug Hunting 并以 PoC 确认。贯穿全程的三条纪律值得反复强调存活 ≠ Bug。存活变异体只证明测试没抓住这次改动必须先区分测试缺口与等价变异再谈原代码是否存在问题等价性靠证明不靠猜测。类型上下文、可达性、下游消费、语义比较、区分性测试五步缺一不可严重度看代码功能不看操作符。授权逻辑上的低严重度操作符存活体其价值远高于日志行上的高严重度存活体。想深入了解背景可参阅 Trail of Bits 博客文章《Use mutation testing to find the bugs your tests dont catch》并进一步阅读本仓库中的 SKILL.md 及三个工作流、六个引用文档它们构成了完整的可执行方法论。赞分享AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载相关推荐IronClaw 变异审计实战用 Mutation Testing 找出覆盖率看不见的测试空洞IronClaw 变异审计实战用 Mutation Testing 找出覆盖率看不见的测试空洞 在 IronClaw一个聚焦隐私、安全与可扩展性的 Agen人工智能AI 应用交互助手AI AgentDiem Move Prover 变异测试工具prover-mutation完整指南原理、CLI 与配置Diem Move Prover 变异测试工具prover mutation完整指南原理、CLI 与配置 导读 本文围绕 Diem 代码仓库中 langu区块链金融科技基于 TritonDSE 的 AFL Python 自定义变异器实战指南基于 TritonDSE 的 AFL Python 自定义变异器实战指南 导读 本文深入解析 AFL 仓库中 custom_mutators/aflpp应用安全测试漏洞扫描上一篇交互感知轨迹预测终极指南从理论到自动驾驶应用下一篇探索React Native的文档选择器react-native-document-picker创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mutation Testing 实战指南：基于 mewt/muton 配置变异测试、分析存活变异体并定位潜在 Bug
AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载导读本文以 Trail of Bits 开源的 Claude Code 技能插件mutation-testing位于 plugins/mutation-testing/README.md为核心系统讲解如何配置变异测试mutation testingcampaign、解读存活变异体surviving mutants揭示的测试缺口并借变异结果反向排查原代码中的潜在缺陷。读完本文你将掌握mewt/muton的完整命令行工作流、五阶段配置与优化方法、等价变异体判定程序、严重度分级标准以及如何复现和验证该插件自带的评估用例。一、插件定位一个技能覆盖三种工作流mutation-testing插件仅内置一个同名技能通过/mutation-testing:mutation-testing调用或直接向 Agent 描述变异测试需求即可触发。技能入口文档 SKILL.md 将请求路由到三个独立工作流请求类型技能行为搭建或优化 campaign配置mewt或muton检查目标选择实测测试耗时调优超时与按目标per-target的测试命令分析已完成的结果逐个读取存活变异体对应的源码与测试区分等价变异与测试缺口并在mutation-testing-report.md中给出具体的断言或输入建议调查潜在 Bug以存活变异体为地图优先排查原代码在产出可复现的 PoC 之前不得把某个缺陷描述为已确认值得注意的是一个存活变异体只意味着测试未检测到一次人为注入的改动——它可能揭示测试缺口也可能是等价实现。它本身并不能证明原代码存在 Bug。因此分析工作流只负责给出测试改进建议不会替用户实现或修改测试代码。技能的适用与排除边界同样明确用户提到 mewt、muton、mutation testing、配置/加速 campaign、分析存活或等价变异体、以及用变异结果找 Bug 时使用而纯粹讨论行覆盖率、与变异测试无关的测试问题时不应调用此技能。二、前置条件与工具约定Campaign 搭建依赖 mewt 或 muton 之一外加一套可运行的测试套件。文档中的示例均遵循mewt 4.x APImuton 与 mewt 共享相同接口只需把命令名替换为muton并把文件名替换为muton.toml、muton.sqlite。安装后应以mewt --help与mewt subcommand --help为准——技能明确规定命令行行为以--help为准示例反映 mewt 4.x API遇到陌生 flag 或命令失败时先查--help。分析已保存的结果则不需要安装任何工具只需提供 campaign 输出、变异位点处的源码与相关测试即可。分析工作流同样接受来自其他变异测试工具如 slither-mutate、mull、dextool-mutate的结果其解析锚点见 references/input-formats.md。三、核心命令速查从初始化到复核技能在 SKILL.md 中给出了完整的 Essential Commands按生命周期阶段整理如下# 搭建与运行 mewt init # 创建配置与数据库mewt.toml mewt.sqlite mewt mutate [paths] # 只生成变异体不运行测试 mewt run [paths] # 生成变异体并运行整个 campaign # 读取结果 mewt status # 总览含按文件的细分 mewt results # 默认视图未捕获Uncaught的变异体 mewt results --all # 展示所有结果而不只是 Uncaught mewt results --format json # 输出格式json | sarif | ids | table # 缩小范围以下过滤器同时作用于 results 与 print mutants mewt results --target src/auth/** # 用引号包裹 glob避免被 shell 展开 mewt results --severity high,medium mewt results --mutation-types ER,CR mewt results --status Uncaught # Uncaught | TestFail | Skipped | Timeout mewt results --line 42 # 调查与重测 mewt print mutant --id [id] # 查看被改写的代码 mewt test --ids [ids] # 重测指定变异体 mewt test --ids-file uncaught_ids.txt # 从文件读 ID 重测- 表示从 stdin 读 # 检查配置 mewt print config # 生效中的配置 mewt print targets # 实际被变异的文件 mewt print mutations --language [lang] # 某语言的变异操作与严重度语言标签使用 mewt 4.x 的规范family或family/dialect值例如rust、javascript/ts、move/sui、move/iota。结果状态语义是理解输出数据的根基Caught/TestFail测试检测到了注入的改动好事Uncaught测试未检测到改动需要查看代码以区分是测试缺口还是等价变异Timeout测试超时——结果不确定不能作为覆盖证据Skipped同一行存在更高严重度的未捕获变异体因此跳过了较低严重度的那个。变异操作符语义以mewt print mutations --language [lang]的输出为权威来源操作符集合随每个版本增长但输出并不会告诉你存活变异体的含义——这正是优先级排序的来源严重度代表 slug未捕获变异体意味着什么HighERError Replacement错误替换测试容忍了被注入的错误。需调查该路径是否被执行、错误处理是否掩盖了改动、断言是否真的校验了结果MediumCRComment Replacement注释/语句替换移除该语句不会导致测试失败。需检查其副作用是否重要、断言是否观察到这些副作用MediumIF/ITIf False/True条件恒假/恒真、NRNegation Removal取反移除测试区分不了被改写的条件。两个常量替换都存活可能意味着条件从未被执行或对分支结果的断言太弱Low操作符重排AOS、COS、LOS、BOS、位移/赋值变体、BL、AS、LC、WF需检查边界输入、算术断言与语义等价性。变异结果本身无法证明代码是否被执行关键提醒严重度衡量的是变异操作本身而非风险。一个低严重度、发生在费用计算里的存活体可能比一个高严重度、发生在日志行里的存活体更重要——判断依据是被改动代码的功能而不是操作符标签。可配合--severity过滤器按优先级逐个处理结果。四、工作流一五阶段配置与优化配置工作流的目标是让用户能以兼顾彻底性与执行时间的最优设置运行mewt run。完整流程见 workflows/configuration.md这里浓缩其五个阶段。Phase 1初始化并校验目标mewt init # 生成 mewt.toml 与 mewt.sqlite若配置放在非标准位置用--config path/to/mewt.toml指定——配置文件所在目录的父目录会成为工作目录配置中的相对路径也以此为基准解析。随后mewt print config # 查看自动生成的配置校验[targets]模式include应只匹配源码src/、lib/、contracts/ignore应排除测试、依赖与生成代码。注意 ignore 模式是子串匹配例如test会命中tests/与test_utils.rs。[targets] include [src/**/*.rs] # 只匹配具体源码目录 ignore [test, mock] # 排除 src/ 内的 test/mock 文件Phase 2生成变异体并评估规模mewt mutate src/ # 输出按目标的严重度细分--verbose 可看单个变异体 mewt status # 查看变异体总数 mewt print targets # 展示实际被变异的文件 time test-command-from-config # 例如 time cargo test记录基线耗时最坏情况时长估算公式变异体数量 × 单次测试耗时。例如 500 个变异体 × 10 秒 ≈ 1.4 小时。实际运行通常会更快测试会快速杀死变异体skip 机制也会降低负载。Phase 3决策优化策略按预估时长走决策树 1 小时直接进入 Phase 41–16 小时询问用户能否接受通宵/下班后运行不接受则应用优化 16 小时必须探索优化方案。需要优化时读取 references/optimization-strategies.md其优先级顺序为核实目标选择最常见问题用mewt print config/mewt print targets排查是否变异了 mocksrc/mocks/、__mocks__/、测试*_test.rs、*.test.js、tests/、依赖vendor/、node_modules/或生成代码proto/、generated/分析项目结构mewt print mutants --target src/auth/**/*.rs --format ids | wc -l统计各组件变异体数并按--severity high/medium/low或--mutation-types ER统计严重度分布注意严重度占比在代码库之间差异巨大15% 到 50% 都属常见向用户呈现带时间估算的四个选项见下节将选中方案写入mewt.toml。若[targets]或[run].mutations发生变更需要更新数据库并重算时长# 缩小目标范围Option Bpurge 移除不再匹配 [targets].include/ignore 的目标 mewt purge mewt mutate src/ # 为新纳入的文件补变异体 mewt status # 确认变异体数量下降 # 限制变异类型Option C已有变异体可能失效必须全量重建 mewt purge --all mewt mutate src/ mewt statuspurge 会删除已保存的变异体与结果——执行前务必保留需要留存的产出并确认丢弃相关 campaign 数据已获授权。Phase 4校验测试命令与超时默认情况下 mewt 自动计算超时基线测试时间 × 2多数情况可覆盖增量重编译的开销。例外场景是重编译开销主导测试时间的编译型语言如 Solidity/Foundry需实测验证time forge test # 热缓存下例如 0.8s touch src/Contract.sol # 模拟变异触发依赖重编译 time forge test # 例如 5.2s若重编译时间远大于测试时间则在mewt.toml中手动设置超时[test] cmd forge test timeout 11 # 依据5.2s × 2 10.4s向上取整否则省略timeout交给 mewt 自动计算。Phase 5最终校验清单mewt print config— 配置语法有效、无报错mewt status— 变异体数量符合预期mewt print targets— 只变异了目标文件无测试/mock/依赖测试命令已验证Phase 2 或 4 中实测通过超时已设置自动或针对重编译重型语言手动设置时长估算用户可接受全部通过后即可运行mewt run。执行时机建议 1 小时随时可跑1–16 小时放在下班前启动、次日清晨收结果16–48 小时建议周五晚启动、周一收结果两阶段方案则第一阶段过夜、第二阶段次日。配置参考完整 mewt.toml 模板db mewt.sqlite [log] level info # trace, debug, info, warn, error [targets] # 务必具体只含源码绝不含测试/依赖 include [src/**/*.js, lib/**/*.js] ignore [test, mock] # 子串匹配不是 glob [run] # 可选限制变异类型省略则测试全部 # mutations [ER, CR, IF, IT] [test] cmd npm test # timeout 30 # 可选省略时自动计算2× 基线 # 按目标覆盖规则第一个匹配优先 [[per_target]] glob src/core/*.js test.cmd npm test -- core test.timeout 20各语言的[targets]参考配置# Rust [targets] include [src/**/*.rs] ignore [test, mock, generated] # Solidity [targets] include [contracts/**/*.sol] ignore [test, interfaces, mocks] # Go [targets] include [**/*.go] ignore [test, mock, generated] # JavaScript/TypeScript [targets] include [src/**/*.ts, lib/**/*.ts] ignore [test, spec, mock]编辑后务必运行mewt print config检查无效 TOML 并确认生效配置。优化选项 A–DOption A完整 campaign预估 ~X 小时最坏情况实际通常更快适合时长可接受、追求全面覆盖的场景Option B聚焦关键组件先只变异src/auth/等关键组件快速迭代评审后再逐步扩围Option C仅高/中严重度[run]中设置mutations [ER, CR, IF, IT]约覆盖 30–40% 的变异体也可不改数据库、直接用mewt results --severity high,medium在分析期过滤保留灵活性Option D两阶段 campaign仅适合集成测试主导的套件Phase 1 用[[per_target]]指向快速定向测试Phase 2 用mewt results --status Uncaught --format ids uncaught_ids.txt导出存活体再切换回全量[test]配置并用mewt test --ids-file uncaught_ids.txt复测。示例估算朴素方案 2000 × 45s 25 小时两阶段约 10 小时约 2.5× 提速。注意 Phase 2 时长在 Phase 1 完成前不可预知只能表述为存活数 × 全量套件耗时。排障要点没有生成任何变异体时依次检查语言是否受支持mewt print mutations --language rust、include 模式是否匹配到文件mewt print configfind src -name *.rs | head。文档特别警告排查文件存在性时用find而不是ls src/**/*.rs——**是否递归取决于 shellzsh 会展开bash 需开启 globstarmacOS 自带 bash 3.2 甚至没有 globstar 选项ls在不同机器上会给出不一致的诊断结果而find在所有 shell 中行为一致且无匹配时退出码为 0 而非报错。**请保留在mewt.toml中由 mewt 自己展开。常见原因还包括 ignore 模式过宽test命中test_utils.rs与语言不受支持。测试命令失败时先在项目目录手动运行确认再检查Makefile、justfile、package.json、README.md找正确命令monorepo 中可能需要从 workspace 子目录运行。配置原则总结通过mewt.toml配置而非 CLI flag便于版本控制目标精确指向源码优先限制文件范围而非变异类型campaign 前手动验证测试命令信任自动超时优化前先实测将mewt.toml连同注释一起提交。五、工作流二结果分析——等价变异、严重度与报告分析工作流workflows/analyzing-results.md是工具无关、语言无关的负责识别测试缺口、按严重度分类存活变异体、过滤等价变异体并产出结构化报告。它需要配合等价目录、严重度指南与报告模板三个引用文件使用。必须拒绝的合理化辩解技能明确列出六种要拒绝的借口这是保证分析质量的核心约束kill rate 超过 80%测试套件足够了。——聚合指标会掩盖单个关键缺口访问控制里的一个存活体比日志模块里被杀死的一百个变异体更重要这大概是等价变异体。——等价性必须从类型系统与控制流中证明绝不能假设缺少能区分它的测试不是证明改成这种边界改动总是等价的。——只有当边界值可证明不可达时才等价可达的边界就是真实发现虽然存活了但测试套件在实践中能抓住这个问题。——既然存活套件就抓不住这就是存活的定义只报最高层级就够了。——低层级同样是具体、可行动的测试改进建议事件发射类存活体也能暴露监控与集成所需的缺失断言不读源码我就能分类。——严重度取决于被改代码的功能等价性取决于类型与可达性两者都必须读变异位点的源码。六阶段分析程序解析输入Phase 1识别结果格式。mewt/muton、mutmut、cargo-mutants、mutahunter 大多产出可直接按字段名解析的 JSON/CSV结构不明显的先读前 50 行。对 mewt/muton 项目mewt results --format json可直接给出 Uncaught 变异体。确认字段含文件路径、行号与状态只提取存活/未捕获状态收集上下文Phase 2按文件分组批量读取变异位点确认代码功能、涉及类型、是否可达、是否安全敏感/财务/业务逻辑/可观测性代码过滤等价变异体Phase 3对每个变异体套用五步验证程序见下节严重度分级Phase 4按 references/severity-classification.md 的标准为每个真实缺口分配优先级层级影响不确定时明确说明而不是自动升 tier。这些 tier 只用于排定测试工作的优先级不构成对原程序漏洞严重性的判定分析测试缺口Phase 5按生态惯例定位负责的测试文件src/x.rs→tests/x.rs或#[cfg(test)]模块x.py→test_x.pyx.go→x_test.goX.sol→X.t.sol读出本应捕获该变异体的用例解释它为什么没抓到缺失断言、未覆盖分支、缺失边界用例、输入种类不足、或者执行了代码却没验证输出并给出具体补法加什么断言、用什么输入、覆盖哪个分支。如果根本没有测试触达被改代码必须明说——这比弱断言更强有力的发现写报告Phase 6写入工作目录下的mutation-testing-report.md按报告模板组织。每个统计量都要说明分母skipped/timeout/unresolved 单独列账原始与等价调整后的 kill rate 只在数据支持时给出。报告长度与发现数匹配空 tier 可以省略。分析硬性要求每个存活变异体都要单独分析不得跳读、概括或批量处理按严重度顺序Tier 1、2 优先工作会话可能中断时保存中间进度报告使用正式、客观、第三人称、主动语态、现在时测试改进建议用文字描述而非贴测试代码。等价变异体五步验证程序references/equivalent-mutants.md 定义等价变异体是语义上与原始代码完全一致的变异任何测试都无法杀死它因为不存在可观察差异。判定前必须完成全部五项检查类型上下文确认变异涉及变量的类型——无符号整数、布尔、枚举各有专属等价模式可达性确认被改代码在运行中确实可达——死代码中的变异是平凡等价的下游消费追踪变异后的值是否被后续逻辑读取——从不被消费的值其变异无可观察效果语义比较在类型约束下对全部可能输入比较原始与变异行为若无输入产生不同结果则等价区分性测试尝试尝试构造一个能产生不同行为的输入——若能构造则非等价并把该输入作为推荐测试用例若检查完边界值、类型极值与领域特定边界后仍找不到区分输入则强化等价判定。只有分析确立了可观察行为相同变异体才算等价。某步不确定时保留为 unresolved 并说明缺失的证据——不确定性本身不构成测试缺口。典型等价模式与看似等价实则不然的陷阱确认为等价的模式无符号比较等价x 0变异为x ! 0——对无符号整数不大于零的值只有零本身两者对所有无符号值结果一致。适用于 Rustu8–u128/usize、C/Cunsigned、Solidityuint等。但变量是有符号类型时不成立x 0排除负数x ! 0包含负数布尔双重否定!(!condition)变异为condition——逻辑恒等重言式边界检查无符号x 0变异为true——两者对所有值都为真前提是求值x无可观察副作用。但替换为x 0时不成立x 0时原式为真、替换式为假而零对无符号类型是可达的死代码变异不可达分支内的任何变异冗余赋值赋值后变量从未被读取的变异交换律重排a b→b a、a * b→b * a仅限纯操作数、同类型的内建整数运算重载操作符与浮点语义需单独审查。看似等价但必须当作真实发现的陷阱边界值改动→——边界值产生不同结果除非边界值可证明不可达。常见错误因为当前测试没触发边界就断言其不可达——不可达必须由类型系统或控制流证明不能由测试覆盖推断循环边界 off-by-onei length→i length——多执行一次迭代可能越界访问或处理多余元素移除事件发射emit Transfer(...)被注释掉——虽不改执行逻辑但可能破坏依赖事件的监控、索引服务或集成测试应归为 Tier 4低而非等价交换非交换操作a - b→b - a、a / b→b / a——除非a b结果必然不同引入未定义行为C/C改动使边界检查、指针操作或整数算术引入 UB有符号溢出、缓冲区越界、空指针解引用——今天测试全过不代表等价UB 在不同编译器/优化级别/平台下可能以不同方式显现代表真实的安全缺陷。严重度分级标准Tier 1–4分级依据是被改代码的影响类型而非变异操作符——同一个操作符替换出现在访问控制逻辑里和出现在日志语句里严重度完全不同。tier 只排定测试工作优先级不代表原代码存在漏洞影响不确定时应说明而不是自动升档。Tier 1严重安全敏感代码强制安全不变量。判定条件谁可调用函数的控制访问控制/授权、身份或凭据校验认证/签名、防重入或其他并发攻击、系统边界的外部输入校验、密码学操作哈希/签名/验签、提权路径防护admin 函数/升级。示例assert(caller admin)、签名验签verify_signature、ecrecover、jwt.verify、常量时间比较hmac.compare_digest、login_required等认证守卫Tier 2高财务/状态完整性代码管理资金转账、会计或关键状态转换。判定条件代币/原生币转账、手续费/份额/汇率/利息计算、余额与账本管理、状态机转换顺序、预言机价格、滑点/期限保护、清算或抵押阈值。示例account.balance - withdrawal、fee amount * rate / 100、份额会计、价格/阈值守卫Tier 3中业务逻辑代码实现协议特定行为但不直接处理价值或强制安全边界。判定条件非安全边界的配置/参数校验、数据结构管理数组/映射/队列、协议工作流治理/投票/质押奖励、外部合约集成点、非安全路径的错误处理Tier 4低可观测性与信息性代码不影响执行逻辑。判定条件事件/日志发射、仅用于展示的 view/pure/getter 返回值、错误消息字符串而非 revert 条件本身、NatSpec/文档常量、监控调试输出。示例log::info!、metrics.increment、get_name()。模糊案例裁决规则控制安全敏感阈值如最大签名者数、timelock 超时的配置参数归Tier 1承载价值的合约外部调用的错误处理归Tier 2非价值调用归 Tier 3返回值被状态变更函数消费的 getter如交易中的定价查询、更新前的权限检查归Tier 2而非 Tier 4下游消费者监控、索引器、集成合约、协议标准依赖的事件/日志发射升到Tier 3。区分 Tier 2 与 Tier 3 的试金石这段代码在生产环境出错会导致资金损失或会计错误吗是则 Tier 2否则 Tier 3。报告模板结构references/report-template.md 定义的结构包含执行摘要总变异数、被杀数、存活数、等价数、真实存活数、未决存活数、跳过/不确定数、原始与调整后 kill rate且每个比率注明分母、关键发现、严重度分布表、等价变异体清单表文件/行/变异/等价理由、按 Tier 1–4 组织的逐条发现每条含文件、行、变异前后代码、操作符、上下文、负责的测试文件与用例、为什么没被抓住、推荐改进、按测试文件归组的建议清单、未决案例、以及附录输入文件、含存活体的源文件表、方法论。六、工作流三Bug Hunting——把存活体变成已确认 BugBug 猎手工作流workflows/bug-hunter.md的核心原则是未捕获变异体揭示测试盲区而盲区正是 Bug 藏身之处。但缺失测试不是 Bug它只是去哪里找的信号。该工作流的交付物是带 PoC 复现的已确认 Bug而不是一份覆盖缺口清单只有在调查变异体背后的代码并真正发现问题后才报告一个未捕获变异体。前置条件已完成的 campaignmewt run [paths]且结果可查mewt status。四步流程识别高风险代码用mewt status找有存活体的文件交叉对照敏感性auth、crypto、解析、输入校验、核心业务逻辑用mewt results --target src/auth/**拉取目标区域的存活体。排序优先级低分的关键代码 → 任意分数的关键代码crypto 80% 也值得读→ 低分的核心逻辑 → 其余个体变异体排序按高危险模式表排列见下。立即调查auth/crypto/parsing/validation 中的ER、跨连续行的ER簇、安全代码中IF与IT双双存活、授权检查上的CR。其次调查错误处理路径中的ER、复杂条件中的IF/IT、状态变更操作上的CR、单个函数内多个存活体聚集。低优先级孤立操作符变异、工具函数存活体、死代码那是该清理的技术债不是要调试的 Bug调查 Bugmewt print mutant --id id查看变异读周围函数确立预期行为注意变异注入的缺陷不能证明原程序有漏洞要调查的是原始源码。确定它为何未被测试——死代码/新代码/测试从未触发的边界用例/仅 happy-path 测试背后的错误路径/单元与集成缺口每种指向不同类型的 Bug。评估风险攻击者可控输入能否触达、出错会怎样、是否位于安全边界。按变异类型查找对应 Bug 类ER手工走代码路径、检查静默成功的错误处理与输入校验IF/IT演练未测分支、找 off-by-one 与未处理的 null/空值CR检查语句是否必要、状态变更是否真的发生操作符变异核对比较/算术是否为预期并测试边界。尝试复现写 PoC 测试并运行确认影响——未能复现的假设只能叫疑似 Bug不能叫确认记录发现每条发现含位置、证据变异结果 手动测试、问题、影响与严重度、复现、修复。示例见技能文档中的Expired Tokens Accepted案例src/auth/verify.rs:78的过期令牌校验反转。所有发现分类为confirmed可复现 PoC、已验证影响、likely强证据但未复现、dead code不可达建议清理、not a bug代码正确、测试弱。后两类不进 Bug 清单。若调查确认无 Bug如实报告该结论及其范围与未决案例——这并不等于该区域没有 Bug。高危险模式表ER簇可能意味着未执行代码块或测试容忍错误需先检查执行与断言再选解释一行上IF与IT双双存活意味着测试对两种常量替换都不区分条件可能未执行或两个分支都跑了却没断言结果差异错误处理中的ERcatch 块、错误返回路径意味着失败模式完全未校验一个安全敏感文件里有大量混合类型存活体意味着关键代码覆盖普遍薄弱应手工通读逻辑寻找安全绕过而不是逐个变异体排查。工作方式一次聚焦一个文件/区域集中在优先级最高的 10–20 个变异体——全面覆盖大结果集不是目标高影响力发现才是。存活体过多时果断取舍从 auth/crypto/validation 中的ER开始偏好簇而非孤立变异体接受部分区域无法调查。七、验证体系确定性检查与模型评估插件自带的评估见 README.md 的 Validation 一节使用一次捕获的 campaign 加上一套刻意写得薄弱的 Rust 测试套件。fixture 位于 evals/weak-suite-analysis/fixture其 src/lib.rs 是一个最小化的保险库vaultwithdraw函数有if !is_admin授权守卫、amount account.balance资金守卫与余额扣减而tests/vault.rs只演练一次 happy-path 提现并只断言返回余额导致多个变异体存活。评估要求 Agent 区分balance 0与其两个变异体balance ! 0对u64是等价的而balance 0在零值处有差异——这是核心考点。它还检查授权、余额会计与日志记录方面的缺口。fixture 无需安装 cargo 或 mewt 即可分析。从仓库根目录运行报告校验测试uv run --no-project --with pytest python -m pytest plugins/mutation-testing/tests -q --import-modeimportlib DETERMINISTIC_ONLY1 uv run --no-project bash plugins/mutation-testing/tests/smoke-test.sh校验脚本 tests/validate_report.py 说明了判定逻辑balance 0若被列入等价表即失败它在balance 0处与原式不同且没有测试调用has_funds(0)balance ! 0若未被列为等价即失败对无符号 u64 它与balance 0不可区分。此外还检查报告须有等价变异体章节、Tier 1/Critical 章节必须出现is_admin两个if !is_admin变异体是访问控制缺口属于最高 tier、record_withdrawal与eprintln不得被归档到 Tier 1它们是可观测性代码应归最低 tier、5 个存活行号24/27/31/37/41必须都被引用、报告正文不得少于 500 字节防止 stub。确定性检查只验证 grader 的牙齿不验证技能的有效性。可选的模型评估需要支持插件 eval 的 Claude Code 与ANTHROPIC_API_KEY用同一校验器检查 Agent 的报告uv run --no-project bash plugins/mutation-testing/tests/smoke-test.sh模型评估会在本地保留报告并调用 API可用MODEL、JUDGE_MODEL、RUNS、MAX_COST_USD分别控制模型、评判模型、运行次数与成本上限。一个通过的 fixture 并不证明带技能的 Agent 优于不带技能的 Agent——这是评估设计上明确承认的边界。八、复现捕获的 campaign如果想在本地完整复现那次捕获的 campaign需要在独立的副本上操作避免污染仓库mutation_fixture_dir$(mktemp -d)/vault cp -R plugins/mutation-testing/evals/weak-suite-analysis/fixture $mutation_fixture_dir cd $mutation_fixture_dir cargo test mewt mutate mewt run mewt resultsfixture 中已包含捕获的mewt-results.json与mewt-status.txt供分析流程直接使用。九、总结与实践要点围绕本插件形成的一套可复用的完整实践路径是初始化mewt init→ 严格限定目标[targets]只含源码→ 预估规模变异体数 × 测试耗时→ 必要时优化聚焦组件/限制类型/两阶段→ 验证测试命令与超时 →mewt run→ 分析存活体五步等价判定 四级严重度→ 输出mutation-testing-report.md→ 对高危区域做 Bug Hunting 并以 PoC 确认。贯穿全程的三条纪律值得反复强调存活 ≠ Bug。存活变异体只证明测试没抓住这次改动必须先区分测试缺口与等价变异再谈原代码是否存在问题等价性靠证明不靠猜测。类型上下文、可达性、下游消费、语义比较、区分性测试五步缺一不可严重度看代码功能不看操作符。授权逻辑上的低严重度操作符存活体其价值远高于日志行上的高严重度存活体。想深入了解背景可参阅 Trail of Bits 博客文章《Use mutation testing to find the bugs your tests dont catch》并进一步阅读本仓库中的 SKILL.md 及三个工作流、六个引用文档它们构成了完整的可执行方法论。赞分享AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载相关推荐IronClaw 变异审计实战用 Mutation Testing 找出覆盖率看不见的测试空洞IronClaw 变异审计实战用 Mutation Testing 找出覆盖率看不见的测试空洞 在 IronClaw一个聚焦隐私、安全与可扩展性的 Agen人工智能AI 应用交互助手AI AgentDiem Move Prover 变异测试工具prover-mutation完整指南原理、CLI 与配置Diem Move Prover 变异测试工具prover mutation完整指南原理、CLI 与配置 导读 本文围绕 Diem 代码仓库中 langu区块链金融科技基于 TritonDSE 的 AFL Python 自定义变异器实战指南基于 TritonDSE 的 AFL Python 自定义变异器实战指南 导读 本文深入解析 AFL 仓库中 custom_mutators/aflpp应用安全测试漏洞扫描上一篇交互感知轨迹预测终极指南从理论到自动驾驶应用下一篇探索React Native的文档选择器react-native-document-picker创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考