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 Bitsdifferential-review技能中 methodology.md 所定义的差分安全审查方法论它把一次 PR、commit 或 diff 的安全审查拆解为 Pre-Analysis 加 Phase 0–4 共六个可执行的阶段覆盖基线上下文构建、变更提取与分诊、逐行变更分析、测试覆盖核查、爆炸半径量化与深层上下文取证。读完本文你将掌握一套先建基线、再查变更、后算影响的安全审查流水线——既会写出可复制的 git 命令也能理解每一步背后的原理并能在 adversarial.mdPhase 5与 reporting.mdPhase 6中继续完整的工作流。一、方法论定位差分审查在整体工作流中的角色differential-review是当前仓库中面向安全研究的差分代码审查技能其完整流程在 SKILL.md 中定义为 Pre-Analysis Phase 0–6Pre-Analysis → Phase 0: Triage → Phase 1: Code Analysis → Phase 2: Test Coverage ↓ ↓ ↓ ↓ Phase 3: Blast Radius → Phase 4: Deep Context → Phase 5: Adversarial → Phase 6: Report其中本文讲解的 methodology.md 覆盖 Pre-Analysis 与 Phase 0–4分诊、代码分析、测试覆盖、爆炸半径、深层上下文是整条流水线的主干Phase 5 的对抗建模与 Phase 6 的报告生成分别由同目录的adversarial.md与reporting.md承接。在使用上SKILL.md 提供的决策树明确给出了路由规则需要逐阶段详细方法时读methodology.md对 HIGH RISK 变更做攻击者建模时读adversarial.md或委派给differential-review:adversarial-modeler子代理写最终报告时读reporting.md查找具体漏洞模式时读 patterns.md。这意味着本文讲解的六个阶段是必须逐个执行的主流程而不是可选项。另外要注意本技能的适用边界。SKILL.md 的When NOT to Use一节明确指出绿地代码没有基线可对比、纯文档变更、格式化/lint 类无害变更、用户明确只要快速摘要的场景都不应启动完整差分审查流程改用常规代码审查即可。二、Pre-Analysis基线上下文构建——审查的第一步动作methodology.md 把基线构建列为FIRST ACTION优先级高于一切分诊动作。理由是只有先搞清楚变更之前的代码应该做什么、假设了什么才能判断变更是否破坏了系统级不变量。2.1 操作步骤# 检出基线提交 git checkout baseline_commit # 在基线代码库上调用 audit-context-building 技能 # Scope 整个相关项目Solidity 用 packages/contracts/contractsRust 用 src 等 audit-context-building --scope [entire project or main contract directory] --focus invariants,trust-boundaries,validation-patterns,call-graphs,state-flows # 示例 # Solidity: audit-context-building --scope packages/contracts/contracts # Rust: audit-context-building --scope src # 全仓库: audit-context-building --scope .基线分析完成后切回 head 提交再分析变更git checkout head_commit2.2 必须从基线捕获的内容系统级不变量system-wide invariants所有代码路径上必须恒成立的性质信任边界与权限层级trust boundaries and privilege levels谁能做什么校验模式validation patterns什么在哪里被检查——这是纵深防御defense-in-depth的分布地图关键函数的完整调用图call graphs谁调用了谁状态流转图state flow diagrams状态如何变化外部依赖与信任假设external dependencies and trust assumptions。2.3 为什么基线分析如此重要理解变更前代码本应做什么识别基线中隐含的安全假设检测变更是否违反基线不变量区分哪些模式是系统级的、哪些是局部的捕捉变更是否打破纵深防御。基线上下文应在后续差分分析期间持续保留、随时参照。仓库中的audit-context-building插件正是这一阶段的主力工具其工作流实现在 audit-context.js。源码可以印证 methodology 中--focus参数的底层语义脚本在 第 173 行 用focus变量拼出作用域约束——Restrict the scan to ${focus} and anything it calls有 focus 时或 Cover the whole codebase无 focus 时即--focus不只是筛选分析面而是连带追踪其被调用的整条依赖链这与 Phase 4 中对变更函数及其依赖做深上下文的需求完全对应。从 audit-context.js 的 ORIENTATION_SCHEMA 可见基线分析产出的结构化字段modules模块及其角色、entrypoints外部可达入口及可达者、actors参与者及信任等级 untrusted/semi-trusted/trusted/unclear、state跨调用存续的状态及其写入者、candidates值得逐函数深挖的候选按重要性排序。分析会落盘为audit-context/DOSSIER.md与audit-context/functions/下每函数一份的分析文件只有紧凑的结构化记录返回上下文窗口——这正是 SKILL.md 所述理解、而非下结论的设计基线阶段不命名漏洞、不写利用、不评严重度只记录结构与不变量。三、Phase 0Intake Triage——变更提取与复杂度分诊进入差分分析前先完成三件事提取变更、评估代码库规模、给每个变更文件打风险分。3.1 提取变更# 提交区间统计与提交列表 git diff base..head --stat git log base..head --oneline # PR直接取文件与增删行数 gh pr view number --json files,additions,deletions # 获取所有变更文件 git diff base..head --name-only技能的入口命令/differential-review:diff-review接受pr-url|commit-sha|diff-path加可选的--baseline ref参数见 diff-review.md其中--baseline即本节base的显式化若不提供则由工具按仓库上下文推断比较基准。3.2 评估代码库规模find . -name *.sol -o -name *.rs -o -name *.go -o -name *.ts | wc -l按文件数把代码库分成三档并采用不同分析策略下表同时出现在 methodology.md 与 SKILL.md 的 Quick Reference 中保持一致规模判定策略做法SMALL20 文件深度分析DEEP阅读所有依赖完整 git blameMEDIUM20–200 文件聚焦分析FOCUSED1 跳依赖、优先文件LARGE200 文件外科手术式SURGICAL仅关键路径3.3 逐文件风险评分HIGH认证auth、加密crypto、外部调用、价值转移value transfer、校验移除MEDIUM业务逻辑、状态变更、新增公开 APILOW注释、测试、UI、日志。核心原则是按风险分类而不是按体量分类——SKILL.md 的 Rationalizations 表格用 Heartbleed 只有两行代码的例子提醒不要因PR 很小就快速放行必须先分类再决定投入。四、Phase 1Changed Code Analysis——逐文件变更取证对每个变更文件执行六步分析。4.1 阅读两个版本并逐 diff 区域分析先完整读取基线版本与变更版本两份代码然后对每个 diff 区域按固定模板记录BEFORE: [变更前精确代码] AFTER: [变更后精确代码] CHANGE: [行为影响] SECURITY: [安全影响]4.2 对删除代码做 git blame# 这段代码是什么时候加的为什么加 git log -S removed_code --all --oneline git blame baseline -- file.sol | grep pattern红旗red flags从 fix、security、CVE 相关提交中移除的代码 →CRITICAL近期1 个月刚添加就被移除 →HIGH。git blame 的意义在于重建历史意图一段安全代码被删必须先问它当初为何存在、防的是哪种攻击。4.3 检查回归re-added codegit log -S added_code --all -p要警惕的模式是代码因安全问题被移除 → 现在又重新加回 → 这构成REGRESSION回归。SKILL.md 的红旗清单把来自 security/CVE/fix 提交的代码被移除列为最高优先级的即时升级触发条件即便在快速分诊中也必须停下做对抗分析。patterns.md 进一步给出了回归检测命令git log -S pattern --all --grepsecurity\|fix\|CVE其红旗标准包括提交信息含 security/fix/CVE/vulnerability代码在 6 个月内被移除过当前 PR 未解释为何重新加回。4.4 微对抗分析micro-adversarial analysis对每一处变更主动扮演攻击者提问被移除的代码原本阻止了什么攻击新代码暴露了什么新攻击面被修改的逻辑能否被绕过检查是否变弱边界情况是否覆盖完整4.5 生成具体攻击场景SCENARIO: [攻击目标] PRECONDITIONS: [所需状态] STEPS: 1. [具体动作] 2. [预期结果] 3. [利用过程] WHY IT WORKS: [引用的代码变更] IMPACT: [严重度 影响范围]这一模板强调具体每个场景都必须落到具体的函数调用与状态条件而不是泛泛的威胁描述。SKILL.md 的质量清单也要求攻击场景必须具体不是通用套话且发现必须引用具体行号与提交。五、Phase 2Test Coverage Analysis——测试覆盖缺口识别没有测试覆盖的变更等于把风险评级拱手抬高。这一阶段的目标是找出改了但没测的部分。5.1 分离生产代码变更与测试变更# 生产代码变更排除测试 git diff range --name-only | grep -v test # 测试变更 git diff range --name-only | grep test # 对每个变更函数搜索对应测试 grep -r test.*functionName test/ --include*.sol --include*.js5.2 风险提升规则场景处理新增函数 无测试风险 MEDIUM→HIGH 提升修改了校验逻辑 测试未变高风险校验语义变了旧测试无法证明仍正确复杂逻辑20 行 无测试高风险methodology 对此的立场是没有测试本身不是免责理由而是风险升级理由。SKILL.md 的 Rationalizations 表格对应条目明确写着缺失的测试 风险评级必须上调并在报告中标记、升级严重度。SKILL.md 的 Do/Dont 清单也要求不要忘记检查测试覆盖。六、Phase 3Blast Radius Analysis——爆炸半径量化爆炸半径决定优先级一个 HIGH 风险函数如果有 89 个调用者与只有 2 个调用者处置优先级完全不同。6.1 统计调用者数量# 统计每个被修改函数的调用者数量 grep -r functionName( --include*.sol . | wc -l6.2 爆炸半径分级调用次数级别1–5LOW6–20MEDIUM21–50HIGH50CRITICALSKILL.md 特别警告过两种直觉陷阱爆炸半径一眼就能看出来是错误合理化——会漏掉传递性调用者必须定量计算同时把50 调用者 HIGH 风险变更列入即时升级红旗。6.3 优先级矩阵变更风险爆炸半径优先级分析深度HIGHCRITICALP0深度 全部依赖HIGHHIGH/MEDIUMP1深度HIGHLOWP2标准MEDIUMCRITICAL/HIGHP1标准 调用者矩阵的实际用法先用第 6.2 节量化半径再结合 Phase 0 的风险评分得出每个变更的优先级与分析深度——它是资源分配的决策表直接决定 Phase 4 与 Phase 5 的投入量。七、Phase 4Deep Context Analysis——高风险变更的深层取证Phase 4 面向所有 HIGH RISK 变更函数是信息密度最高的阶段。核心手段若audit-context-building技能可用直接调用它来辅助回答以下全部问题audit-context-building --scope [file containing changed function] --focus flow-analysis,call-graphs,invariants,root-cause从 audit-context.js 的 RECORD_SCHEMA 可以看到这类深分析的结构化产出每个函数的invariants必须成立的性质且每条都要引用代码行作证据、assumptions函数默认相信为真的前提并指明由哪个函数/行建立找不到则记 nothing found、calls内部/外部调用及各自传播/假设了什么、openQuestions未解问题。脚本的 PURE_CONTEXT 约束L167-L169强调这是上下文构建而非漏洞狩猎——不命名漏洞、不写利用、不评严重度未强制执行的假设只记录为未强制执行的假设。SKILL.md 还点明两条最值得交给后续狩猎阶段的信息标记为nothing found的假设以及诚实的未解问题清单。7.1 映射完整函数流入口条件前置条件preconditions、require、modifiers状态读取访问了哪些变量状态写入修改了哪些变量外部调用对合约、API、系统的调用返回值与副作用。7.2 追踪内部调用列出所有被调用的函数递归映射它们的流构建完整调用图。7.3 追踪外部调用识别跨过的信任边界列出关于外部行为的假设检查重入reentrancy风险。7.4 识别不变量什么必须恒为真什么必须永不发生变更后这些不变量是否仍被维持7.5 Five Whys 根因分析对每一处 HIGH 风险变更连续追问五个为什么为什么这段代码被改了为什么原代码会存在为什么这可能被破坏为什么选择这种方案为什么它会在生产环境失败若audit-context-building不可用methodology 明确要求退化为手动逐行分析使用 Read、Grep 与代码追踪完成上述全部五个子任务——即这一阶段的价值不依赖任何工具工具只是加速器。7.6 跨切面模式检测# 查找重复的校验模式 grep -r require.*amount 0 --include*.sol . grep -r onlyOwner --include*.sol . # 检查 diff 中是否有删除 git diff range | grep ^-.*require.*amount 0这一步回答模式是系统级的还是局部的如果所有价值转移路径都有amount 0校验而本次 diff 恰恰删除了其中一处就说明纵深防御被打破必须标记。methodology 的原话是如果移除破坏了纵深防御必须标记Flag if removal breaks defense-in-depth。八、阶段输出与后续路由methodology.md 的收尾给出了明确的下一步路由这也是整体工作流的衔接点HIGH RISK 变更→ 进入 adversarial.mdPhase 5定义攻击者模型WHO/ACCESS/INTERFACE、识别具体攻击向量、评级可利用性EASY/MEDIUM/HARD、构建完整利用场景、与基线上下文交叉对照报告生成→ 参见 reporting.mdPhase 69 段式 Markdown 报告模板、格式化规范、文件命名规则PROJECT_DIFFERENTIAL_REVIEW_DATE.md与用户通知模板漏洞模式速查→ patterns.md安全回归、双重增减、缺失校验、上下溢、重入、访问控制绕过、抢跑/竞争条件、时间戳操纵、未检查返回值、DoS 等模式的检测命令集。SKILL.md 的 Quality Checklist 是交付前的最后一道闸所有变更文件已分析、对删除的安全代码做过 git blame、HIGH 风险的爆炸半径已计算、攻击场景具体而非通用、发现引用具体行号与提交、报告文件已生成、用户已收到摘要通知。任何一个勾不上的项都意味着流程还没有真正走完。九、总结一条可复制的差分审查流水线把六个阶段连起来看methodology.md 提供的是一个高度工程化的审查流程其设计主线清晰先建基线Pre-Analysis用audit-context-building在 baseline commit 上建立不变量、信任边界、校验模式、调用图与状态流的完整地图再分诊Phase 0提取变更、按文件数选策略、逐文件打 HIGH/MEDIUM/LOW 风险分后取证Phase 1–2对每个 diff 区域做 BEFORE/AFTER 分析git blame 追删除代码的历史意图用git log -S抓回归同时核查测试覆盖缺口并按规则上调风险定量优先级Phase 3按调用者数量分级爆炸半径再用优先级矩阵决定 P0–P2 与分析深度深度审Phase 4对 HIGH 风险函数做函数流/内部调用/外部调用/不变量/Five Whys 五维取证并检测跨切面模式的移除是否破坏纵深防御。这套流水线既适用于几行的小改动按风险而非体量分类也适用于数百文件的框架级变更按 SURGICAL 策略收缩分析面其输出直接为 Phase 5 对抗建模与 Phase 6 报告生成供料。对任何以变更引入漏洞为主要风险形态的代码库它都是一份可直接照着执行的操作手册。赞分享AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载相关推荐基于 Differential Review 的安全差分代码审查git 历史、爆炸半径与对抗性建模实战指南基于 Differential Review 的安全差分代码审查git 历史、爆炸半径与对抗性建模实战指南 导读 本文围绕 Trail of Bits 开源技AI 技能AI 插件应用安全网络安全AI 评测基于 Claude Code 的差分安全审查深入解析 differential-review 命令与 Phases 0-6 审查流程基于 Claude Code 的差分安全审查深入解析 differential review 命令与 Phases 0 6 审查流程 导读 本文是 TraiAI 技能AI 插件应用安全网络安全AI 评测Newton 代码审查实战指南基于 code-review-newton 技能的三轴审查方法论Newton 代码审查实战指南基于 code review newton 技能的三轴审查方法论 导读 code review newton 是 Newton物理引擎机器人上一篇H5可视化编辑器终极指南零基础5分钟制作专业H5页面下一篇nanomsg与NNG的演进之路创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考