customize

自定义 vuln-pipeline

此流水线以 C/C++ + AddressSanitizer 演示项目的形式提供，并带有明确的设计倾向。它的实际结构更通用：一个 Agent 构造输入，在沙箱中运行目标程序，检测器触发，第二个 Agent 进行验证，第三个 Agent 分析可利用性。 这句话里的每个名词都可以替换。你的任务是采访用户，弄清楚他们想替换哪些名词，并重写相关文件。

现有的 C/C++ 代码是一个完整示例。你不需要为每个领域都准备一套操作指南——阅读现有内容，理解哪些部分是通用的、哪些是 ASAN 专属的，然后进行调整。

第 1 步 — 阅读流水线（在提问前完成）

浏览以下文件，确保你的问题有据可依：

• README.md — 流水线概览（侦察 → 查找 → 评级 → 裁决 → 报告）
• harness/cli.py — 编排逻辑；展示各阶段如何衔接，以及哪些内容会写入磁盘
• harness/find.py、harness/grade.py、harness/report.py — 三个容器 Agent 循环；主要是通用的基础逻辑
• harness/prompts/find_prompt.py、harness/prompts/grade_prompt.py — C/C++ 专属部分；缺陷分类、质量层级、评级标准
• harness/prompts/report_prompt.py、harness/prompts/report_grader_prompt.py — 同样是 C/C++ 专属部分；可利用性章节（利用原语、堆布局、提权路径）以及用于评分的标准
• harness/prompts/judge_prompt.py — 分流提示词；关注 ASAN 摘录和内存安全崩溃类别
• harness/prompts/system_prompt.py — 授权模块；硬编码了“C/C++ 目标程序”和“检测器输出”
• harness/asan.py — 用于去重／裁决签名的堆栈跟踪解析器；包含 ASAN 专属正则表达式
• harness/artifacts.py — CrashArtifact、GraderVerdict、JudgeVerdict、ReportVerdict 数据契约
• harness/config.py、targets/drlibs/config.yaml — 目标配置架构
• targets/README.md — 目标目录的结构说明（Dockerfile + config.yaml + 入口包装器）

你不必详细阅读 agent.py、docker_ops.py、recon.py、judge.py 或 novelty.py——它们都是通用基础逻辑（裁决／新颖性与领域相关的内容位于提示词和 ASAN 解析器中，而不在流程里）。但请注意：harness/ 的部分内容同时也是共享基础设施——dnr_harness/（检测与响应流水线）会导入 agent.py、sandbox.py、docker_ops.py、agent_image.py 中的 build／ensure_base、auth.py、cli.py 中的 resolve_target_dir／terminate_subprocesses，以及 prompts/system_prompt.py 中的 load_engagement_context。移植到其他领域时，只应修改领域专属文件（提示词、asan.py、artifacts.py、目标 Dockerfile）；任何对共享文件的修改都应视为会同时影响两条流水线的改动。

第 2 步 — 采访用户

使用 AskUserQuestion 收集需求。先了解整体背景，再根据用户的回答深入询问技术细节。

第 1 轮——背景信息（始终先一起询问）

两个开放式问题，用于了解对方的身份和目标。大多数回答预计会通过 Other 以自由文本形式提供——这些选项只是为了启发思路，而不是限制回答。

问题 A——运行环境

• header：Context
• question：What's your operating environment? Who will run this pipeline and why?
• options：列出几个典型场景作为参考，例如：“渗透测试公司——客户项目，需要可报告的发现结果”“内部应用安全团队——在 CI 中扫描自有服务”“智能合约审计师——部署前审查”“安全研究人员——寻找新型漏洞类别”。这些信息有助于确定重要的输出格式、评估严格程度和工作流集成方式。

问题 B——目标

• header：Goal
• question：Describe in your own words what you want this pipeline to find. What kind of target, what kind of bugs?
• options：给出 2–3 个具体示例（例如：“HTTP 服务中的 SQLi/XSS 等 Web 漏洞”“Solidity 合约中的重入和访问控制漏洞”“Java 微服务中的反序列化 RCE”）。

背景信息会帮助调整后续问题：渗透测试公司可能重视 CVSS 评分和 SARIF 输出；研究人员可能需要差分测试和新颖的检测信号；内部团队通常需要 CI 集成和较低的误报率。

第 2 轮——技术跟进问题（自适应——根据第 1 轮的回答推导）

根据对方第 1 轮的回答，按照下方的变化维度进行分析。对于每个仍不明确的维度，都要提出有针对性的跟进问题。每次 AskUserQuestion 调用最多提出 4 个问题。常见的跟进问题包括：

• 检测信号——“流水线如何判断自己发现了问题？”（崩溃、异常、出现 canary 文件、DNS 回连、差异不匹配、不变量违反）
• PoC 形式——“概念验证是什么样的？”（单个文件、HTTP 请求序列、交易列表、测试流水线代码）
• 隔离——“目标在哪里运行？”（Docker、VM、测试网、远程沙箱，或不执行——仅静态分析）
• 评估标准——“在这个领域，怎样的发现算高质量，怎样的算低质量？”
• 可利用性分析——“报告应包含哪些部分？”C/C++ 报告包含原语 · 可达性 · 堆布局 · 提权路径 · 限制条件。Web 漏洞报告可能需要注入向量 · 身份验证绕过 · 数据暴露 · 漏洞链潜力。询问对方需要哪些内容，或是否需要报告阶段。
• 新颖性／上游检查——“流水线是否应检查某项发现是否已在上游修复？”C/C++ 版本会浅克隆目标的 GitHub 仓库，并运行 git log <commit>..HEAD -- <crash_file> 进行检查。只有在目标有权威上游仓库，且有合理的“崩溃文件”可用作匹配依据时才适用——许多领域并不具备这些条件。
• 范围——“是完全替换 C/C++ 支持，还是通过配置文件系统让新领域与其并存？”

继续提问，直到能够填写 STEP 3 中架构图的每一行。如果回答含糊不清，应提出范围更窄的跟进问题，而不是自行猜测。

背景 — 变化维度（用于拟定后续问题的上下文）

客户可能希望在 C/C++ 演示的基础上调整以下维度。利用此列表找出用户描述中的缺漏，并提出后续问题——不要将其作为选项菜单呈现。

漏洞类别： 内存安全 · Web/API（SQLi、XSS、SSRF、XXE、路径遍历、IDOR）· 反序列化 RCE · 逻辑/竞态（TOCTOU、权限提升）· 加密（弱随机数生成器、时序、随机数重用）· DoS（ReDoS、哈希泛洪）· 智能合约（重入、访问控制、抢先交易）· ML/AI（提示词注入、越狱、数据提取）· 协议解析

目标形态： CLI 二进制文件 + 文件 · HTTP 服务 · 通过测试框架调用的库 · 网络守护进程 · 智能合约 · 浏览器扩展 · 移动应用

检测机制： 崩溃/中止 · 未捕获异常 · Sanitizer 钩子（Jazzer/Atheris）· 基于结果（canary 文件、DNS 回调、启动 shell）· 差分测试 · 不变量违规 · 污点跟踪

输入形式： 单个文件 · HTTP 请求链 · 多文件归档 · stdin 流 · 参数 + 环境变量 + 配置组合 · 事务序列

隔离边界： Docker 容器 · 完整虚拟机 · 远程沙箱 · 本地测试网 · 无（静态分析）

去重特征： (crash_type, top_frame) · (vuln_type, endpoint, param) · (function, state_transition) · (component, precondition)

报告结构： 原语/堆/权限提升（内存安全）· 向量/身份验证/暴露（Web）· 不变量/路径/影响（合约）· 如果交付内容是发现并评级，则可完全省略报告阶段

输出格式： result.json + poc.bin · SARIF · Nuclei 模板 · 文字报告

补丁验证信号： ASAN-clean 退出 · 无未捕获异常 · Sanitizer 钩子无触发（Jazzer/Atheris）· canary 文件未被修改 · 不变量断言成立 · 差分输出与参考结果一致。这就是 patch_grade.py 中 _t1_passes() 所编码的内容——针对新领域，“漏洞已修复”。

背景 — 架构图（哪些会变，哪些保持不变）

文件	是否特定于 C/C++？	用途
harness/prompts/find_prompt.py	是 — 重写	Bug 分类、质量等级、ASAN 输出格式、退出代码示例
harness/prompts/grade_prompt.py	是 — 重写	5 项标准评分标准假设使用 ASAN 跟踪信息和 Unix 信号退出代码
harness/prompts/report_prompt.py	是 — 重写	可利用性章节：原语、堆布局、提权路径——特定于内存安全
harness/prompts/report_grader_prompt.py	是 — 重写	对上述章节评分；评分标准与章节集合绑定
harness/prompts/judge_prompt.py	是 — 重写	根据 ASAN 摘录和崩溃类别分类法进行分诊
harness/prompts/patch_prompt.py	是 — 重写	要求提供 git diff -- '*.c' '*.h'，假设存在 ASAN 跟踪信息，并提供 memcpy 风格的根因分析指导
harness/prompts/system_prompt.py	是 — 重写	授权部分写明“C/C++ 目标”和“检测器输出”
harness/asan.py	是 — 重写	用于匹配 #N 0xHEX in func /path:line 栈帧的正则表达式；为去重、裁决和新颖性检测提供数据
targets/README.md + Dockerfile 模板	是 — 重写	gcc -fsanitize=address、entry.c 包装器模式
harness/patch_grade.py	轻微修改	_t1_passes() 检查 AddressSanitizer: 子串；其余验证流程通用
harness/report.py	轻微修改	_SECTIONS 元组和令牌列表需要与新的报告结构一致；流程通用
harness/novelty.py	轻微修改	crash_file_from_frame() 特定于 ASAN；git-log 逻辑通用。若没有上游，则完全移除。
harness/config.py	轻微修改	可能需要新增字段（profile、用 run_command 替代 binary_path）；attack_surface 可能保持不变
harness/artifacts.py	轻微修改	crash_type/exit_code 的语义可能会改变；ReportVerdict.section_scores 的键必须与新章节一致
harness/dedup.py	轻微修改	签名函数需要使用新的解析器；分组逻辑通用
harness/prompts/recon_prompt.py	轻微修改	基本不依赖语言；清理 C 语言惯用写法
harness/cli.py	不变	编排与领域无关
harness/agent.py	不变	Agent 运行器通用
harness/docker_ops.py	不变	容器处理逻辑通用（若隔离方式并非 Docker，可能需要修改）
harness/find.py、grade.py、recon.py、judge.py、patch.py	不变	流程通用；只需更换注入的提示词

第 3 步 — 提出计划并获得确认

开始修改前，先向用户总结：

1. 你的理解 — 用一句话重述他们的目标
2. 将要修改的内容 — 列出你要编辑的每个文件，并简述修改理由
3. 保持不变的内容 — 让用户放心，编排核心不会改动；如果计划涉及上面列出的共享文件，请明确指出（这些文件也供 dnr_harness/ 使用）并说明原因
4. 待确认的问题 — 列出仍不确定的事项

等待用户明确批准。如果用户调整计划，请纳入调整并再次确认。

第 4 步 — 执行

按已批准的计划编辑文件。按依赖顺序处理：先修改提示词和解析器（它们相互独立），再修改 config/artifacts，接着修改目标模板，最后修改 README。如果用户需要检查点，则逐步提交。

步骤 5 — 验证

1. 在 targets/<domain>-canary/ 下添加一个金丝雀目标，并植入 2–3 个属于新类别的漏洞
2. 运行：bin/vp-sandboxed run <domain>-canary --model <model-id> --runs 3 --parallel --stream --max-turns 50（除非用户指定其他模型，否则使用 Claude Opus）。如果尚未设置沙箱，先运行一次 ./scripts/setup_sandbox.sh。
3. 确认所有植入的漏洞均已发现并评级为 PASS
4. 确认裁判分诊正常工作：cat results/<domain>-canary/<ts>/reports/judge_log.jsonl — 每个不同漏洞应有一条 NEW 记录，重复项应标记为 DUP_SKIP
5. 确认报告已生成：ls results/<domain>-canary/<ts>/reports/bug_*/report.json，并抽查各部分的评分
6. 运行 vuln-pipeline dedup results/<domain>-canary/，确认签名正确分组