人工智能AI Agent应用安全漏洞扫描【免费下载链接】defending-code-reference-harnessSkills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize项目地址https://gitcode.com/gh_mirrors/de/defending-code-reference-harness点击查看免费下载导读本文围绕开源仓库 defending-code-reference-harness 中的 Claude Code 技能/vuln-scan定义于 .claude/skills/vuln-scan/SKILL.md展开完整讲解纯静态源码漏洞评审如何读取目标目录、以威胁模型为范围依据、并行派发聚焦子代理审查并产出供/triage直接消费的VULN-FINDINGS.json与人类可读的VULN-FINDINGS.md。读完本文你将掌握该技能的参数体系、五步执行流程、子代理评审简报与置信度复评协议、输出 JSON 规范以及它与仓库内find_prompt.py、recon_prompt.py等自动化管线源码的渊源关系可将其直接用于自己代码库的静态漏洞初筛。技能定位只读、不执行的静态审查/vuln-scan在技能体系中扮演威胁建模与三线triage之间的静态扫描步它读取一个目标目录若存在THREAT_MODEL.md则一并读取按关注领域focus area并行派发多个审查子代理最终写出VULN-FINDINGS.json和VULN-FINDINGS.md供/triage直接摄取。该技能最关键的一条边界是本技能不执行任何代码。它只读取源码并基于代码推理。对于需要执行验证的结论ASAN 崩溃、可复现 PoC技能明确指引用户转向vuln-pipeline run target参见仓库 README.md 的 Step 2 描述及 docs/pipeline.md。因此它与自动化管线中的 find 阶段见 harness/find.py分工清晰静态扫描负责别漏报管线负责执行验证。技能清单frontmatter中的权限约束SKILL.md 的 frontmatter 明确列出了allowed-tools这是理解其安全模型的关键维度值namevuln-scanargument-hinttarget-dir [--focus area] [--single] [--extra file] [--no-score]allowed-toolsRead、Glob、Grep、Write、Task以及只读 Bash 白名单rg:*、grep:*、ls:*、wc:*、head:*、file:*文档特别提醒allowed-tools是权限过滤器而非加载器——列出来不等于这些工具就可用。当会话未预置 Glob/Grep 专用工具时回退到上面白名单中的只读 Bash 命令枚举rg --files scope/ls -R搜索rg -n/grep -rn嗅探wc/head/file这些是唯一允许的 Bash 命令不得编写辅助脚本也不得将目标内容通过管道送入 shell 解释器。参数体系技能接受以下参数全部通过$ARGUMENTS解析与/triage一致不依赖不稳定的位置参数展开target-dir必填——要扫描的目录相对或绝对路径均可。--focus area——只扫描该关注领域可重复指定使用后会跳过侦察recon步骤。--single——不派发子代理进行单次顺序扫描。适用于极小目标或调试提示词时。--extra file——把file的内容纯文本形状与下面类别块相同追加到评审简报的类别列表之后用于注入组织特有的漏洞类别、合规检查或特定技术栈的模式。--no-score——跳过第 3b 步置信度复评省一轮子代理开销此时发现项只保留扫描器自报的置信度。Step 1 — 界定扫描范围范围界定是整个流程的瞄准动作共四步解析target-dir若目录不存在或没有源文件立即报错停止。查找target-dir/THREAT_MODEL.md若存在解析其第 3 节 Entry points trust boundaries 表格获得关注领域与第 4 节 Threats 表格获得威胁类别。这是首选的界定输入。无 THREAT_MODEL.md 且未传--focus时做快速侦察列出源码树、阅读入口点与分发代码提出 3–10 个关注领域使用subsystem (function/file) — key operations模式与 harness/prompts/recon_prompt.py 中 recon 提示词要求的输出格式一致。传了--focus则只用所给领域。在派发前要向用户说明将扫描的关注领域与源文件数量。仓库中的真实示例仓库自带的金丝雀目标 targets/canary/THREAT_MODEL.md 是这一步的最佳样例其第 3 节给出了file input (argv[1])这一入口点信任边界为untrusted file → process memory第 4 节 Threats 表格列出了 T1内存破坏导致 RCE、T2DoS、T3供应链等威胁行。其第 3 节正是该技能 Step 1 所解析的目标。若目标没有威胁模型快速侦察输出的格式与 targets/canary/config.yaml 中手写的focus_areas一致focus_areas: - Alpha parser (parse_alpha) — heap allocation with input-controlled copy length - Bravo parser (parse_bravo) — fixed stack buffer, unbounded copy - Charlie parser (parse_charlie) — conditional early-free with fall-throughrecon 提示词 harness/prompts/recon_prompt.py 要求每个子系统足够独立好的划分如PNG 解码器 vs JPEG 解码器 vs GIF 解码器坏的划分如第 47 行过窄、所有解析过宽、或汇聚到同一代码路径的重叠领域并把函数名前缀或文件 关键操作作为提示线索引导 find 代理瞄准漏洞模式。Step 2 — 并行派发子代理除非传了--single技能会为每个关注领域并行派生一个 Task 子代理并发上限 10。每个子代理获得下面完整的评审简报填入其关注领域。当目标极小少于 15 个源文件时自动降级为--single顺序扫描。评审简报per-subagent 完整原文You are conducting authorized static security review of source code. Your focus area: **{focus_area}**. Other agents cover other areas; duplication is wasted effort. TARGET: {target_dir} TRUST BOUNDARY: {from THREAT_MODEL.md section 3, or untrusted input → process memory} TASK: read the source in your focus area and identify candidate vulnerabilities. This is static review — do NOT build, run, or probe anything. Reason from the code. REPORTING BAR: report anything with a plausible exploit path. Skip style concerns, best-practice gaps, and purely theoretical issues with no attack story at all — but if youre unsure whether something is real, REPORT IT with a low confidence score rather than dropping it. A downstream triage step does the rigorous verification; your job is to not miss things. WHAT TO LOOK FOR: MEMORY SAFETY (C/C and unsafe/FFI blocks) — HIGH VALUE: - heap-buffer-overflow / stack-buffer-overflow / global-buffer-overflow - heap-use-after-free / double-free - integer overflow feeding an allocation or index - format-string bugs - unbounded recursion or allocation driven by untrusted size fields INJECTION CODE EXECUTION — HIGH VALUE: - SQL / command / LDAP / XPath / NoSQL / template injection - path traversal in file operations - unsafe deserialization (pickle, YAML, native), eval injection - XSS (reflected, stored, DOM-based) — but see React/Angular note below AUTH, CRYPTO, DATA — HIGH VALUE: - authentication or authorization bypass, privilege escalation - TOCTOU on a security check - hardcoded secrets, weak crypto, broken cert validation - sensitive data (secrets, PII) in logs or error responses LOW VALUE — note briefly, keep looking: - null-pointer deref at small fixed offsets with no attacker control - assertion failures / clean error returns (correct handling, not a bug) DO NOT REPORT (common false positives — skip even if technically present): - volumetric DoS / rate-limiting / resource-exhaustion — BUT unbounded recursion, algorithmic-complexity blowup, or ReDoS driven by untrusted input ARE reportable - memory-safety findings in memory-safe languages outside unsafe/FFI - XSS in React/Angular/Vue unless via dangerouslySetInnerHTML, bypassSecurityTrustHtml, v-html, or equivalent raw-HTML escape hatch - findings in test files, fixtures, build scripts, docs, or .ipynb - missing hardening / best-practice gaps with no concrete exploit - env vars and CLI flags as the attack vector (operator-controlled) - regex injection, log spoofing, open redirect, missing audit logs - outdated third-party dependency versions {if --extra file was given: append its contents here verbatim} For each finding you DO report, trace: where does the untrusted input enter, what path reaches the sink, and what condition triggers it. OUTPUT — one block per finding, nothing else: finding idF-{focus_idx:02d}-{n:02d}/id file{relative/path}/file line{line_number}/line category{heap-buffer-overflow | use-after-free | integer-overflow | sql-injection | command-injection | path-traversal | deserialization | xss | auth-bypass | hardcoded-secret | ...}/category severity{HIGH | MEDIUM | LOW}/severity confidence{0.0-1.0}/confidence title{one line}/title description{root cause, attacker control, trigger condition, data flow from entry to sink. Cite line numbers.}/description exploit_scenario{concrete attack: what input, from where, causing what outcome}/exploit_scenario recommendation{specific fix: parameterize the query, bounds-check before memcpy, etc.}/recommendation /finding SEVERITY: HIGH directly exploitable → RCE, data breach, auth bypass. MEDIUM significant impact under specific conditions. LOW defense-in- depth. If you find nothing reportable in your area after a thorough read, emit a single finding with categorynone and a one-line note of what you covered.简报设计与管线源码的同源关系这份重点找什么 / 别报什么的分层结构并非凭空而来。SKILL.md 的 Provenance 一节明确说明其关注领域侦察模式与内存安全质量分层直接取自本仓库 harness/prompts/find_prompt.py 与 harness/prompts/recon_prompt.py——即自主管线在 find/recon 阶段使用的同一套逻辑此处改为静态应用。在 harness/prompts/find_prompt.py 中可以读到对应的 Crash Quality Tiersheap-buffer-overflow尤其是 WRITE、heap-use-after-free/double-free、stack-buffer-overflow、global-buffer-overflow、非空且受攻击者影响的地址上的 SEGV 属 HIGH VALUE断言失败、无界递归导致的栈溢出、0x0/0x8等固定偏移的空指针解引用属 LOW VALUE往往是同一个根因的信号牌改变输入尺寸与偏移可能升级为 HIGH VALUE。这套宁可低置信度上报不可漏报的哲学也与该文件的 Instructions 一脉相承。Step 3 — 汇总与轻量去重收集所有子代理的finding块丢弃categorynone占位。轻量去重若两条发现引用了相同的file:line且类别相同保留描述更长的那条并记录被去重的 id。重量级去重是/triage的职责此处不过度设计。按(severity 降序, file, line)排序后分配稳定 idF-001,F-002, ...。这一步刻意保持轻量静态扫描阶段的目标是召回率误报的过滤被明确交给下游三线阶段。Step 3b — 置信度复评--no-score时跳过这是一个廉价的第二意见阅读只对发现项按信号质量排序不丢弃任何发现。它校准confidence让人与/triage先看到高信号项。实现方式是为每条发现并行派生一个 Task 子代理简报要求浅读重读并打分不做完整可达性追踪。评分简报per-finding 完整原文You are giving ONE candidate security finding an independent confidence score. You are NOT deciding whether to keep it — every finding is kept. You are deciding how likely it is to survive rigorous triage. FINDING: {the full finding block} TARGET: {target_dir} (you may Read/Grep inside it; do NOT execute) STEP 1 — Re-read the cited code. Open {file} around line {line}. Does the code actually do what the description claims? STEP 2 — Check against common false-positive patterns (volumetric DoS, memory-safe language, test/fixture/doc file, framework auto-escape, env-var vector, missing-hardening-only, regex/log injection, outdated dep). A match lowers confidence sharply but does not auto-zero it. STEP 3 — Score 1-10 that this is a real, actionable vulnerability: 1-3 likely false positive or noise 4-5 plausible but speculative 6-7 credible, needs investigation 8-10 high confidence, clear pattern OUTPUT (exactly this, nothing else): CONFIDENCE: 1-10 REASON: one line收尾处理用评分归一化到 0.0–1.0覆盖每条发现的confidence并附加confidence_reason按(confidence 降序, severity 降序, file, line)重新排序并按该顺序重新分配F-001..统计low_confidence_countconfidence 0.4 的条数供摘要行使用。从实现层面看这种每发现一个独立子代理复评的模式与管线中grade.py/judge.py的独立验证思路一致——独立上下文、独立从代码出发判断避免共享上下文导致的盲区传播该原则在 .claude/skills/triage/SKILL.md 的 Phase 3 中有更详尽的阐述。Step 4 — 写出两份产物到target-dir/技能要求同时写出两个文件VULN-FINDINGS.json/triage的摄取格式{ target: target-dir, scanned_at: iso8601, focus_areas: [...], findings: [ { id: F-001, file: relative/path.c, line: 123, category: heap-buffer-overflow, severity: HIGH, confidence: 0.9, title: ..., description: ..., exploit_scenario: ..., recommendation: ..., confidence_reason: ... } ], summary: {total: 0, high: 0, medium: 0, low: 0, low_confidence: 0} }发现项按confidence降序其次 severity、file、line排列因此文件头部即最高信号内容。VULN-FINDINGS.md人类可读报告先是一个摘要表id | severity | category | file:line | title然后为每条发现写一个### F-NNN小节包含完整描述。这个 JSON 容器形状被下游/triage直接识别在 .claude/skills/triage/SKILL.md 的 Phase 1a 中VULN-FINDINGS.json被列为目录摄取时按优先级识别的容器之一读取其.findings[]数组即进入标准化流程。Step 5 — 交还给用户扫描完成后向用户汇报计数N 条发现H/M/L 拆分、X 条低置信度覆盖 K 个关注领域来自 M 个源文件。Top 3按置信度最高的三条各一行。下一步 /triage target-dir/VULN-FINDINGS.json --repo target-dir提醒这些是静态候选未经验证需要执行验证的崩溃请使用vuln-pipeline run target参见 README.md 的 Step 2。这与仓库 README 的 Day 1 实操闭环完全对应README.md# 1. Build a threat model (aim before you shoot) /threat-model bootstrap targets/canary # 2. Run a static scan, scoped by that threat model /vuln-scan targets/canary # 3. Verify, dedupe, and rank what came back /triage targets/canary/VULN-FINDINGS.json # 4. Generate candidate fixes for the verified findings /patch ./TRIAGE.json --repo targets/canary该流程依次产出THREAT_MODEL.md、VULN-FINDINGS.{json,md}、TRIAGE.{json,md}与PATCHES/。约束Constraints技能末尾明确列出的安全边界运行与二次开发时都必须遵守绝不执行目标代码无 Bash、无构建、无docker、无网络。若用户要求复现或用 PoC 确认应拒绝并指向vuln-pipeline。不得伪造行号每条file:line必须是你实际 Read 或 Grep 过的不确定精确行号时引用函数并在描述中说明。停留在target-dir内不跟随符号链接不越出..。永不丢弃发现发现项是/triage的候选而非最终结论Step 3b 只做排序真正去除误报是/triage的 N 票验证职责。与自主管线的同源关系ProvenanceSKILL.md 的自述说明其设计来源关注领域侦察模式与内存安全质量分层取自本仓库 harness/prompts/find_prompt.py 和 harness/prompts/recon_prompt.py——即自主管线在 recon → find 阶段使用的同一套逻辑此处以静态方式应用。更宽泛的类别菜单、DO-NOT-REPORT 排除项、逐发现置信度复评以及exploit_scenario/recommendation输出字段则改编自公开的/security-review命令设计思路仓库不内置该外部项目此处仅作思想来源说明。与之对照的实现证据recon 阶段在 harness/recon.py 中以短轮次预算默认RECON_MAX_TURNS 100运行轻量 agent解析focus_areas标签并逐行产出关注领域find 阶段在 harness/find.py 中为每个关注领域在沙箱容器内运行 find agent解析poc_path/reproduction_command/crash_type等 XML 标签并组装CrashArtifact。/vuln-scan相当于把这两者的读取源码 划分领域 并行聚焦部分抽离出来、去掉执行与沙箱形成文件级的静态扫描技能。延伸阅读管线整体机制与 CLI 标志docs/pipeline.md三线阶段本技能的消费方的验证/去重/排序协议.claude/skills/triage/SKILL.md金丝雀目标的威胁模型样例Step 1 解析对象targets/canary/THREAT_MODEL.md关注领域配置样例targets/canary/config.yaml自主管线的提示词实现harness/prompts/find_prompt.py、harness/prompts/recon_prompt.py技能自定义与移植指南docs/customizing.md赞分享人工智能AI Agent应用安全漏洞扫描【免费下载链接】defending-code-reference-harnessSkills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize项目地址https://gitcode.com/gh_mirrors/de/defending-code-reference-harness点击查看免费下载相关推荐威胁模型驱动的漏洞扫描剖析 defending-code-reference-harness 的 canary 靶机 THREAT_MODEL威胁模型驱动的漏洞扫描剖析 defending code reference harness 的 canary 靶机 THREAT_MODEL 本文以开源仓库人工智能AI Agent应用安全漏洞扫描为自主漏洞扫描 Agent 构建 gVisor 沙箱defending-code-reference-harness 的隔离实践深度解析为自主漏洞扫描 Agent 构建 gVisor 沙箱defending code reference harness 的隔离实践深度解析 本文以仓库 docs人工智能AI Agent应用安全漏洞扫描AionUi 新手指南装好即用一个窗口管住 20 多个 AI AgentAionUi 新手指南装好即用一个窗口管住 20 多个 AI Agent AionUi 是一个免费的开源桌面应用把 Gemini CLI、Claude C人工智能AI Agent应用安全漏洞扫描上一篇TranslucentTB启动失败5种解决方案彻底修复Windows任务栏透明化工具下一篇BabelDOC让学术PDF翻译不再头疼轻松搞定跨语言阅读难题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Defending Code Reference Harness 静态漏洞扫描实战：/vuln-scan 技能从威胁模型到 VULN-FINDINGS 全流程解析
人工智能AI Agent应用安全漏洞扫描【免费下载链接】defending-code-reference-harnessSkills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize项目地址https://gitcode.com/gh_mirrors/de/defending-code-reference-harness点击查看免费下载导读本文围绕开源仓库 defending-code-reference-harness 中的 Claude Code 技能/vuln-scan定义于 .claude/skills/vuln-scan/SKILL.md展开完整讲解纯静态源码漏洞评审如何读取目标目录、以威胁模型为范围依据、并行派发聚焦子代理审查并产出供/triage直接消费的VULN-FINDINGS.json与人类可读的VULN-FINDINGS.md。读完本文你将掌握该技能的参数体系、五步执行流程、子代理评审简报与置信度复评协议、输出 JSON 规范以及它与仓库内find_prompt.py、recon_prompt.py等自动化管线源码的渊源关系可将其直接用于自己代码库的静态漏洞初筛。技能定位只读、不执行的静态审查/vuln-scan在技能体系中扮演威胁建模与三线triage之间的静态扫描步它读取一个目标目录若存在THREAT_MODEL.md则一并读取按关注领域focus area并行派发多个审查子代理最终写出VULN-FINDINGS.json和VULN-FINDINGS.md供/triage直接摄取。该技能最关键的一条边界是本技能不执行任何代码。它只读取源码并基于代码推理。对于需要执行验证的结论ASAN 崩溃、可复现 PoC技能明确指引用户转向vuln-pipeline run target参见仓库 README.md 的 Step 2 描述及 docs/pipeline.md。因此它与自动化管线中的 find 阶段见 harness/find.py分工清晰静态扫描负责别漏报管线负责执行验证。技能清单frontmatter中的权限约束SKILL.md 的 frontmatter 明确列出了allowed-tools这是理解其安全模型的关键维度值namevuln-scanargument-hinttarget-dir [--focus area] [--single] [--extra file] [--no-score]allowed-toolsRead、Glob、Grep、Write、Task以及只读 Bash 白名单rg:*、grep:*、ls:*、wc:*、head:*、file:*文档特别提醒allowed-tools是权限过滤器而非加载器——列出来不等于这些工具就可用。当会话未预置 Glob/Grep 专用工具时回退到上面白名单中的只读 Bash 命令枚举rg --files scope/ls -R搜索rg -n/grep -rn嗅探wc/head/file这些是唯一允许的 Bash 命令不得编写辅助脚本也不得将目标内容通过管道送入 shell 解释器。参数体系技能接受以下参数全部通过$ARGUMENTS解析与/triage一致不依赖不稳定的位置参数展开target-dir必填——要扫描的目录相对或绝对路径均可。--focus area——只扫描该关注领域可重复指定使用后会跳过侦察recon步骤。--single——不派发子代理进行单次顺序扫描。适用于极小目标或调试提示词时。--extra file——把file的内容纯文本形状与下面类别块相同追加到评审简报的类别列表之后用于注入组织特有的漏洞类别、合规检查或特定技术栈的模式。--no-score——跳过第 3b 步置信度复评省一轮子代理开销此时发现项只保留扫描器自报的置信度。Step 1 — 界定扫描范围范围界定是整个流程的瞄准动作共四步解析target-dir若目录不存在或没有源文件立即报错停止。查找target-dir/THREAT_MODEL.md若存在解析其第 3 节 Entry points trust boundaries 表格获得关注领域与第 4 节 Threats 表格获得威胁类别。这是首选的界定输入。无 THREAT_MODEL.md 且未传--focus时做快速侦察列出源码树、阅读入口点与分发代码提出 3–10 个关注领域使用subsystem (function/file) — key operations模式与 harness/prompts/recon_prompt.py 中 recon 提示词要求的输出格式一致。传了--focus则只用所给领域。在派发前要向用户说明将扫描的关注领域与源文件数量。仓库中的真实示例仓库自带的金丝雀目标 targets/canary/THREAT_MODEL.md 是这一步的最佳样例其第 3 节给出了file input (argv[1])这一入口点信任边界为untrusted file → process memory第 4 节 Threats 表格列出了 T1内存破坏导致 RCE、T2DoS、T3供应链等威胁行。其第 3 节正是该技能 Step 1 所解析的目标。若目标没有威胁模型快速侦察输出的格式与 targets/canary/config.yaml 中手写的focus_areas一致focus_areas: - Alpha parser (parse_alpha) — heap allocation with input-controlled copy length - Bravo parser (parse_bravo) — fixed stack buffer, unbounded copy - Charlie parser (parse_charlie) — conditional early-free with fall-throughrecon 提示词 harness/prompts/recon_prompt.py 要求每个子系统足够独立好的划分如PNG 解码器 vs JPEG 解码器 vs GIF 解码器坏的划分如第 47 行过窄、所有解析过宽、或汇聚到同一代码路径的重叠领域并把函数名前缀或文件 关键操作作为提示线索引导 find 代理瞄准漏洞模式。Step 2 — 并行派发子代理除非传了--single技能会为每个关注领域并行派生一个 Task 子代理并发上限 10。每个子代理获得下面完整的评审简报填入其关注领域。当目标极小少于 15 个源文件时自动降级为--single顺序扫描。评审简报per-subagent 完整原文You are conducting authorized static security review of source code. Your focus area: **{focus_area}**. Other agents cover other areas; duplication is wasted effort. TARGET: {target_dir} TRUST BOUNDARY: {from THREAT_MODEL.md section 3, or untrusted input → process memory} TASK: read the source in your focus area and identify candidate vulnerabilities. This is static review — do NOT build, run, or probe anything. Reason from the code. REPORTING BAR: report anything with a plausible exploit path. Skip style concerns, best-practice gaps, and purely theoretical issues with no attack story at all — but if youre unsure whether something is real, REPORT IT with a low confidence score rather than dropping it. A downstream triage step does the rigorous verification; your job is to not miss things. WHAT TO LOOK FOR: MEMORY SAFETY (C/C and unsafe/FFI blocks) — HIGH VALUE: - heap-buffer-overflow / stack-buffer-overflow / global-buffer-overflow - heap-use-after-free / double-free - integer overflow feeding an allocation or index - format-string bugs - unbounded recursion or allocation driven by untrusted size fields INJECTION CODE EXECUTION — HIGH VALUE: - SQL / command / LDAP / XPath / NoSQL / template injection - path traversal in file operations - unsafe deserialization (pickle, YAML, native), eval injection - XSS (reflected, stored, DOM-based) — but see React/Angular note below AUTH, CRYPTO, DATA — HIGH VALUE: - authentication or authorization bypass, privilege escalation - TOCTOU on a security check - hardcoded secrets, weak crypto, broken cert validation - sensitive data (secrets, PII) in logs or error responses LOW VALUE — note briefly, keep looking: - null-pointer deref at small fixed offsets with no attacker control - assertion failures / clean error returns (correct handling, not a bug) DO NOT REPORT (common false positives — skip even if technically present): - volumetric DoS / rate-limiting / resource-exhaustion — BUT unbounded recursion, algorithmic-complexity blowup, or ReDoS driven by untrusted input ARE reportable - memory-safety findings in memory-safe languages outside unsafe/FFI - XSS in React/Angular/Vue unless via dangerouslySetInnerHTML, bypassSecurityTrustHtml, v-html, or equivalent raw-HTML escape hatch - findings in test files, fixtures, build scripts, docs, or .ipynb - missing hardening / best-practice gaps with no concrete exploit - env vars and CLI flags as the attack vector (operator-controlled) - regex injection, log spoofing, open redirect, missing audit logs - outdated third-party dependency versions {if --extra file was given: append its contents here verbatim} For each finding you DO report, trace: where does the untrusted input enter, what path reaches the sink, and what condition triggers it. OUTPUT — one block per finding, nothing else: finding idF-{focus_idx:02d}-{n:02d}/id file{relative/path}/file line{line_number}/line category{heap-buffer-overflow | use-after-free | integer-overflow | sql-injection | command-injection | path-traversal | deserialization | xss | auth-bypass | hardcoded-secret | ...}/category severity{HIGH | MEDIUM | LOW}/severity confidence{0.0-1.0}/confidence title{one line}/title description{root cause, attacker control, trigger condition, data flow from entry to sink. Cite line numbers.}/description exploit_scenario{concrete attack: what input, from where, causing what outcome}/exploit_scenario recommendation{specific fix: parameterize the query, bounds-check before memcpy, etc.}/recommendation /finding SEVERITY: HIGH directly exploitable → RCE, data breach, auth bypass. MEDIUM significant impact under specific conditions. LOW defense-in- depth. If you find nothing reportable in your area after a thorough read, emit a single finding with categorynone and a one-line note of what you covered.简报设计与管线源码的同源关系这份重点找什么 / 别报什么的分层结构并非凭空而来。SKILL.md 的 Provenance 一节明确说明其关注领域侦察模式与内存安全质量分层直接取自本仓库 harness/prompts/find_prompt.py 与 harness/prompts/recon_prompt.py——即自主管线在 find/recon 阶段使用的同一套逻辑此处改为静态应用。在 harness/prompts/find_prompt.py 中可以读到对应的 Crash Quality Tiersheap-buffer-overflow尤其是 WRITE、heap-use-after-free/double-free、stack-buffer-overflow、global-buffer-overflow、非空且受攻击者影响的地址上的 SEGV 属 HIGH VALUE断言失败、无界递归导致的栈溢出、0x0/0x8等固定偏移的空指针解引用属 LOW VALUE往往是同一个根因的信号牌改变输入尺寸与偏移可能升级为 HIGH VALUE。这套宁可低置信度上报不可漏报的哲学也与该文件的 Instructions 一脉相承。Step 3 — 汇总与轻量去重收集所有子代理的finding块丢弃categorynone占位。轻量去重若两条发现引用了相同的file:line且类别相同保留描述更长的那条并记录被去重的 id。重量级去重是/triage的职责此处不过度设计。按(severity 降序, file, line)排序后分配稳定 idF-001,F-002, ...。这一步刻意保持轻量静态扫描阶段的目标是召回率误报的过滤被明确交给下游三线阶段。Step 3b — 置信度复评--no-score时跳过这是一个廉价的第二意见阅读只对发现项按信号质量排序不丢弃任何发现。它校准confidence让人与/triage先看到高信号项。实现方式是为每条发现并行派生一个 Task 子代理简报要求浅读重读并打分不做完整可达性追踪。评分简报per-finding 完整原文You are giving ONE candidate security finding an independent confidence score. You are NOT deciding whether to keep it — every finding is kept. You are deciding how likely it is to survive rigorous triage. FINDING: {the full finding block} TARGET: {target_dir} (you may Read/Grep inside it; do NOT execute) STEP 1 — Re-read the cited code. Open {file} around line {line}. Does the code actually do what the description claims? STEP 2 — Check against common false-positive patterns (volumetric DoS, memory-safe language, test/fixture/doc file, framework auto-escape, env-var vector, missing-hardening-only, regex/log injection, outdated dep). A match lowers confidence sharply but does not auto-zero it. STEP 3 — Score 1-10 that this is a real, actionable vulnerability: 1-3 likely false positive or noise 4-5 plausible but speculative 6-7 credible, needs investigation 8-10 high confidence, clear pattern OUTPUT (exactly this, nothing else): CONFIDENCE: 1-10 REASON: one line收尾处理用评分归一化到 0.0–1.0覆盖每条发现的confidence并附加confidence_reason按(confidence 降序, severity 降序, file, line)重新排序并按该顺序重新分配F-001..统计low_confidence_countconfidence 0.4 的条数供摘要行使用。从实现层面看这种每发现一个独立子代理复评的模式与管线中grade.py/judge.py的独立验证思路一致——独立上下文、独立从代码出发判断避免共享上下文导致的盲区传播该原则在 .claude/skills/triage/SKILL.md 的 Phase 3 中有更详尽的阐述。Step 4 — 写出两份产物到target-dir/技能要求同时写出两个文件VULN-FINDINGS.json/triage的摄取格式{ target: target-dir, scanned_at: iso8601, focus_areas: [...], findings: [ { id: F-001, file: relative/path.c, line: 123, category: heap-buffer-overflow, severity: HIGH, confidence: 0.9, title: ..., description: ..., exploit_scenario: ..., recommendation: ..., confidence_reason: ... } ], summary: {total: 0, high: 0, medium: 0, low: 0, low_confidence: 0} }发现项按confidence降序其次 severity、file、line排列因此文件头部即最高信号内容。VULN-FINDINGS.md人类可读报告先是一个摘要表id | severity | category | file:line | title然后为每条发现写一个### F-NNN小节包含完整描述。这个 JSON 容器形状被下游/triage直接识别在 .claude/skills/triage/SKILL.md 的 Phase 1a 中VULN-FINDINGS.json被列为目录摄取时按优先级识别的容器之一读取其.findings[]数组即进入标准化流程。Step 5 — 交还给用户扫描完成后向用户汇报计数N 条发现H/M/L 拆分、X 条低置信度覆盖 K 个关注领域来自 M 个源文件。Top 3按置信度最高的三条各一行。下一步 /triage target-dir/VULN-FINDINGS.json --repo target-dir提醒这些是静态候选未经验证需要执行验证的崩溃请使用vuln-pipeline run target参见 README.md 的 Step 2。这与仓库 README 的 Day 1 实操闭环完全对应README.md# 1. Build a threat model (aim before you shoot) /threat-model bootstrap targets/canary # 2. Run a static scan, scoped by that threat model /vuln-scan targets/canary # 3. Verify, dedupe, and rank what came back /triage targets/canary/VULN-FINDINGS.json # 4. Generate candidate fixes for the verified findings /patch ./TRIAGE.json --repo targets/canary该流程依次产出THREAT_MODEL.md、VULN-FINDINGS.{json,md}、TRIAGE.{json,md}与PATCHES/。约束Constraints技能末尾明确列出的安全边界运行与二次开发时都必须遵守绝不执行目标代码无 Bash、无构建、无docker、无网络。若用户要求复现或用 PoC 确认应拒绝并指向vuln-pipeline。不得伪造行号每条file:line必须是你实际 Read 或 Grep 过的不确定精确行号时引用函数并在描述中说明。停留在target-dir内不跟随符号链接不越出..。永不丢弃发现发现项是/triage的候选而非最终结论Step 3b 只做排序真正去除误报是/triage的 N 票验证职责。与自主管线的同源关系ProvenanceSKILL.md 的自述说明其设计来源关注领域侦察模式与内存安全质量分层取自本仓库 harness/prompts/find_prompt.py 和 harness/prompts/recon_prompt.py——即自主管线在 recon → find 阶段使用的同一套逻辑此处以静态方式应用。更宽泛的类别菜单、DO-NOT-REPORT 排除项、逐发现置信度复评以及exploit_scenario/recommendation输出字段则改编自公开的/security-review命令设计思路仓库不内置该外部项目此处仅作思想来源说明。与之对照的实现证据recon 阶段在 harness/recon.py 中以短轮次预算默认RECON_MAX_TURNS 100运行轻量 agent解析focus_areas标签并逐行产出关注领域find 阶段在 harness/find.py 中为每个关注领域在沙箱容器内运行 find agent解析poc_path/reproduction_command/crash_type等 XML 标签并组装CrashArtifact。/vuln-scan相当于把这两者的读取源码 划分领域 并行聚焦部分抽离出来、去掉执行与沙箱形成文件级的静态扫描技能。延伸阅读管线整体机制与 CLI 标志docs/pipeline.md三线阶段本技能的消费方的验证/去重/排序协议.claude/skills/triage/SKILL.md金丝雀目标的威胁模型样例Step 1 解析对象targets/canary/THREAT_MODEL.md关注领域配置样例targets/canary/config.yaml自主管线的提示词实现harness/prompts/find_prompt.py、harness/prompts/recon_prompt.py技能自定义与移植指南docs/customizing.md赞分享人工智能AI Agent应用安全漏洞扫描【免费下载链接】defending-code-reference-harnessSkills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize项目地址https://gitcode.com/gh_mirrors/de/defending-code-reference-harness点击查看免费下载相关推荐威胁模型驱动的漏洞扫描剖析 defending-code-reference-harness 的 canary 靶机 THREAT_MODEL威胁模型驱动的漏洞扫描剖析 defending code reference harness 的 canary 靶机 THREAT_MODEL 本文以开源仓库人工智能AI Agent应用安全漏洞扫描为自主漏洞扫描 Agent 构建 gVisor 沙箱defending-code-reference-harness 的隔离实践深度解析为自主漏洞扫描 Agent 构建 gVisor 沙箱defending code reference harness 的隔离实践深度解析 本文以仓库 docs人工智能AI Agent应用安全漏洞扫描AionUi 新手指南装好即用一个窗口管住 20 多个 AI AgentAionUi 新手指南装好即用一个窗口管住 20 多个 AI Agent AionUi 是一个免费的开源桌面应用把 Gemini CLI、Claude C人工智能AI Agent应用安全漏洞扫描上一篇TranslucentTB启动失败5种解决方案彻底修复Windows任务栏透明化工具下一篇BabelDOC让学术PDF翻译不再头疼轻松搞定跨语言阅读难题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考