Back to Details

customize

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Customize the vuln-pipeline

定制漏洞检测管道

This pipeline ships as an opinionated C/C++ + AddressSanitizer demo. Its real shape is more general: an agent crafts an input, runs a target in a sandbox, a detector fires, a second agent verifies, a third agent analyses exploitability. Every noun in that sentence can be swapped. Your job is to interview the user, figure out which nouns they want to swap, and rewrite the relevant files.
The existing C/C++ code is the worked example. You don't need a playbook for each domain — read what's there, understand what's generic vs. ASAN-specific, and adapt.
该管道最初是一个偏向C/C++ + AddressSanitizer的演示版本，但它的实际架构更具通用性：一个Agent生成输入，在沙箱中运行目标程序，检测器触发告警，第二个Agent验证问题，第三个Agent分析可利用性。这句话中的每个核心模块都可以替换。你的任务是与用户沟通，明确他们想要替换哪些模块，然后重写相关文件。
现有C/C++代码是一个完整示例。你不需要每个领域的操作手册——只需阅读现有代码，区分通用模块和ASAN特定模块，然后进行适配即可。

STEP 1 — Read the pipeline (do this BEFORE asking anything)

步骤1 — 阅读管道（询问用户前务必完成）

Skim these files so your questions are grounded:
  • README.md
    — pipeline overview (recon → find → grade → judge → report)
  • harness/cli.py
    — orchestration; shows how stages wire together and what lands on disk
  • harness/find.py
    , 
    harness/grade.py
    , 
    harness/report.py
    — the three container-agent loops; mostly generic plumbing
  • harness/prompts/find_prompt.py
    , 
    harness/prompts/grade_prompt.py
    — the C/C++-specific parts; bug taxonomy, quality tiers, grading rubric
  • harness/prompts/report_prompt.py
    , 
    harness/prompts/report_grader_prompt.py
    — also C/C++-specific; exploitability sections (primitive, heap layout, escalation path) and the rubric that scores them
  • harness/prompts/judge_prompt.py
    — triage prompt; keys on ASAN excerpts and memory-safety crash classes
  • harness/prompts/system_prompt.py
    — authorization block; hard-codes "C/C++ target" and "sanitizer output"
  • harness/asan.py
    — stack-trace parser for dedup/judge signatures; ASAN-specific regex
  • harness/artifacts.py
    — 
    CrashArtifact
    , 
    GraderVerdict
    , 
    JudgeVerdict
    , 
    ReportVerdict
    data contracts
  • harness/config.py
    , 
    targets/drlibs/config.yaml
    — target config schema
  • targets/README.md
    — how a target directory is structured (Dockerfile + config.yaml + entry wrapper)
You don't need 
agent.py
, 
docker_ops.py
, 
recon.py
, 
judge.py
, or 
novelty.py
in detail — they're generic plumbing (judge/novelty domain-specificity lives in the prompts and the asan parser, not the flow).
浏览以下文件，让你的问题更有针对性：
  • 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++ target"和"sanitizer output"
  • harness/asan.py
    — 用于去重/判定签名的堆栈跟踪解析器；ASAN特定正则表达式
  • harness/artifacts.py
    — 
    CrashArtifact
    、
    GraderVerdict
    、
    JudgeVerdict
    、
    ReportVerdict
    数据契约
  • harness/config.py
    、
    targets/drlibs/config.yaml
    — 目标配置 schema
  • targets/README.md
    — 目标目录的结构说明（Dockerfile + config.yaml + 入口包装器）
你无需深入了解
agent.py
、
docker_ops.py
、
recon.py
、
judge.py
或
novelty.py
——它们是通用基础逻辑（判定/新颖性的领域特异性体现在提示词和ASAN解析器中，而非流程本身）。

STEP 2 — Interview the user

步骤2 — 与用户沟通

Use AskUserQuestion to gather requirements. Start with broad context, then narrow to technical specifics based on what they say.
使用AskUserQuestion收集需求。先从宽泛的背景开始，再根据用户的回答细化到技术细节。

Round 1 — Context (always ask these first, together)

第一轮 — 背景（务必先问这两个问题）

Two open-ended questions to understand who you're talking to and what they're after. Expect most answers to come via Other as free text — the options are there to prompt thinking, not to constrain.
Question A — Operating context
  • header: 
    Context
  • question: 
    What's your operating environment? Who will run this pipeline and why?
  • options: a few archetypes as inspiration — e.g. "Pentesting firm — client engagements, need reportable findings", "Internal appsec team — scan our own services in CI", "Smart-contract auditor — pre-deployment reviews", "Security researcher — hunting novel bug classes". These tell you what output format, grading rigor, and workflow integration matter.
Question B — Goal
  • 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 concrete examples (e.g. "Web vulnerabilities like SQLi/XSS in HTTP services", "Reentrancy and access-control bugs in Solidity contracts", "Deserialization RCE in Java microservices").
The context answer calibrates your follow-ups: a pentesting firm probably cares about CVSS scoring and SARIF output; a researcher may want differential testing and novel detection signals; an internal team likely wants CI integration and low false-positive rates.
两个开放式问题，用于了解用户身份和需求。大部分回答会以Other形式的自由文本呈现——选项仅用于启发思考，而非限制。
问题A — 运行场景
  • 标题: 
    Context
  • 问题: 
    你的运行环境是什么？谁会使用这个管道，目的是什么？
  • 选项: 几个典型场景作为参考 — 例如"渗透测试公司 — 客户项目，需要可上报的检测结果"、"内部应用安全团队 — 在CI中扫描自有服务"、"智能合约审计师 — 部署前审查"、"安全研究员 — 挖掘新型漏洞类别"。这些信息会告诉你输出格式、分级严谨性和工作流集成的重要性。
问题B — 目标
  • 标题: 
    Goal
  • 问题: 
    用你自己的话描述你希望这个管道检测什么。目标类型是什么，要检测哪种漏洞？
  • 选项: 2-3个具体示例（例如"HTTP服务中的SQLi/XSS等Web漏洞"、"Solidity合约中的重入和访问控制漏洞"、"Java微服务中的反序列化RCE"）。
背景回答会指导后续提问：渗透测试公司可能关心CVSS评分和SARIF输出；研究员可能需要差分测试和新型检测信号；内部团队可能希望CI集成和低误报率。

Round 2 — Technical follow-ups (adaptive — derive from round-1 answers)

第二轮 — 技术跟进（自适应 — 根据第一轮回答推导）

Parse their round-1 answers against the axes of variation below. For each axis left ambiguous, ask a targeted follow-up. Batch up to 4 questions per AskUserQuestion call. Common follow-ups:
  • Detection signal — "How will the pipeline know it found something?" (crash, exception, canary file appears, DNS callback, differential mismatch, invariant violation)
  • PoC shape — "What does a proof-of-concept look like?" (single file, HTTP request sequence, transaction list, test-pipeline code)
  • Isolation — "Where does the target run?" (Docker, VM, testnet, remote sandbox, or no execution — static-only)
  • Grading criteria — "What makes a finding high-quality vs. low-quality in this domain?"
  • Exploitability analysis — "What sections should a report contain?" The C/C++ report has primitive · reachability · heap layout · escalation path · constraints. A web-vuln report might want injection vector · auth bypass · data exposure · chaining potential. Ask what they need, or whether they want the report stage at all.
  • Novelty/upstream check — "Should the pipeline check if a finding is already fixed upstream?" The C/C++ version shallow-clones the target's GitHub and checks 
    git log <commit>..HEAD -- <crash_file>
    . Only applies if targets have a canonical upstream and a sensible "crashing file" to key on — many domains won't.
  • Scope — "Replace the C/C++ support entirely, or keep it alongside the new domain via a profile system?"
Keep going until you can fill in every row of the architecture map in STEP 3. If an answer is vague, ask a narrower follow-up rather than guessing.
根据以下变异维度分析用户的第一轮回答。对于每个模糊的维度，提出针对性的跟进问题。每次AskUserQuestion最多可批量提出4个问题。常见跟进问题：
  • 检测信号 — "管道如何判断发现了问题？"（崩溃、异常、标记文件出现、DNS回调、差分不匹配、不变量违反）
  • PoC形态 — "概念验证（PoC）是什么样的？"（单个文件、HTTP请求序列、交易列表、测试管道代码）
  • 隔离方式 — "目标程序在哪里运行？"（Docker、虚拟机、测试网、远程沙箱，或无需执行——仅静态分析）
  • 分级标准 — "在该领域中，什么样的检测结果是高质量的，什么样是低质量的？"
  • 可利用性分析 — "报告应包含哪些章节？"C/C++报告包含原语·可达性·堆布局·提权路径·约束条件。Web漏洞报告可能需要注入向量·权限绕过·数据泄露·链式利用潜力。询问用户需求，或确认是否需要报告阶段。
  • 新颖性/上游检查 — "管道是否需要检查检测结果是否已在上游修复？"C/C++版本会浅克隆目标的GitHub仓库，并检查
    git log <commit>..HEAD -- <crash_file>
    。仅适用于目标有规范上游仓库且有明确"崩溃文件"的场景——很多领域不适用。
  • 范围 — "是完全替换C/C++支持，还是通过配置文件系统在保留原有支持的同时新增领域？"
继续提问，直到你能填写步骤3中的架构映射表的每一行。如果回答模糊，提出更具体的跟进问题，而非猜测。

Background — axes of variation (context for formulating follow-ups)

背景 — 变异维度（用于制定跟进问题）

These are the dimensions along which customers might want to deviate from the C/C++ demo. Use this list to spot gaps in the user's description and generate follow-up questions — do not present it as a menu.
Vulnerability class: memory safety · web/API (SQLi, XSS, SSRF, XXE, path traversal, IDOR) · deserialization RCE · logic/race (TOCTOU, privilege escalation) · crypto (weak RNG, timing, nonce reuse) · DoS (ReDoS, hash flooding) · smart contracts (reentrancy, access control, front-running) · ML/AI (prompt injection, jailbreaks, data extraction) · protocol parsing
Target shape: CLI binary + file · HTTP service · library via test harness · network daemon · smart contract · browser extension · mobile app
Detection mechanism: crash/abort · uncaught exception · sanitizer hooks (Jazzer/Atheris) · outcome-based (canary file, DNS callback, shell spawn) · differential testing · invariant violation · taint tracking
Input modality: single file · HTTP request chain · multi-file archive · stdin stream · args + env + config combo · transaction sequence
Isolation boundary: Docker container · full VM · remote sandbox · local testnet · none (static analysis)
Dedup signature: (crash_type, top_frame) · (vuln_type, endpoint, param) · (function, state_transition) · (component, precondition)
Report structure: primitive/heap/escalation (memory safety) · vector/auth/exposure (web) · invariant/path/impact (contracts) · or drop the report stage entirely if find+grade is the deliverable
Output format: result.json + poc.bin · SARIF · Nuclei template · prose report
Patch verification signal: ASAN-clean exit · uncaught-exception-free · sanitizer hook silent (Jazzer/Atheris) · canary file untouched · invariant assertion holds · differential output matches reference. This is what 
_t1_passes()
in 
patch_grade.py
encodes — "the bug is gone" for the new domain.
这些是用户可能希望偏离C/C++演示版本的维度。使用此列表发现用户描述中的空白，并生成跟进问题——不要将其作为菜单展示给用户。
漏洞类别: 内存安全 · Web/API（SQLi、XSS、SSRF、XXE、路径遍历、IDOR）· 反序列化RCE · 逻辑/竞争条件（TOCTOU、权限提升）· 加密（弱随机数生成、计时攻击、随机数重用）· DoS（ReDoS、哈希洪水）· 智能合约（重入、访问控制、抢先交易）· ML/AI（提示注入、越狱、数据提取）· 协议解析
目标形态: CLI二进制文件+文件 · HTTP服务 · 带测试 harness的库 · 网络守护进程 · 智能合约 · 浏览器扩展 · 移动应用
检测机制: 崩溃/终止 · 未捕获异常 · sanitizer钩子（Jazzer/Atheris）· 基于结果（标记文件、DNS回调、Shell生成）· 差分测试 · 不变量违反 · 污点跟踪
输入形式: 单个文件 · HTTP请求链 · 多文件归档 · 标准输入流 · 参数+环境变量+配置组合 · 交易序列
隔离边界: Docker容器 · 完整虚拟机 · 远程沙箱 · 本地测试网 · 无（静态分析）
去重签名: (崩溃类型, 顶层栈帧) · (漏洞类型, 端点, 参数) · (函数, 状态转换) · (组件, 前置条件)
报告结构: 原语/堆/提权（内存安全）· 向量/权限/泄露（Web）· 不变量/路径/影响（合约）· 或者如果仅需要发现+分级，则完全去掉报告阶段
输出格式: result.json + poc.bin · SARIF · Nuclei模板 · 书面报告
补丁验证信号: ASAN无报错退出 · 无未捕获异常 · sanitizer钩子静默（Jazzer/Atheris）· 标记文件未被修改 · 不变量断言成立 · 差分输出与参考匹配。这是
patch_grade.py
中
_t1_passes()
的逻辑——针对新领域的"漏洞已修复"判定标准。

Background — architecture map (what changes vs. what stays)

背景 — 架构映射（哪些需要修改，哪些保持不变）

FileC/C++-specific?What it does
harness/prompts/find_prompt.py
Yes — rewriteBug taxonomy, quality tiers, ASAN output format, exit-code examples
harness/prompts/grade_prompt.py
Yes — rewrite5-criterion rubric assumes ASAN traces and Unix signal exit codes
harness/prompts/report_prompt.py
Yes — rewriteExploitability sections: primitive, heap layout, escalation path — memory-safety-specific
harness/prompts/report_grader_prompt.py
Yes — rewriteScores the above sections; rubric is tied to the section set
harness/prompts/judge_prompt.py
Yes — rewriteTriage keys on ASAN excerpts and crash-class taxonomy
harness/prompts/patch_prompt.py
Yes — rewriteAsks for 
git diff -- '*.c' '*.h'
, assumes ASAN trace, 
memcpy
-style root-cause guidance
harness/prompts/system_prompt.py
Yes — rewriteAuthorization block says "C/C++ target", "sanitizer output"
harness/asan.py
Yes — rewriteRegex for 
#N 0xHEX in func /path:line
frames; feeds dedup, judge, novelty
targets/README.md
+ Dockerfile template		Yes — rewrite
gcc -fsanitize=address
, 
entry.c
wrapper pattern
harness/patch_grade.py
Light edit
_t1_passes()
checks 
AddressSanitizer:
substring; rest of the verification ladder is generic
harness/report.py
Light edit
_SECTIONS
tuple and token lists need to match the new report structure; flow is generic
harness/novelty.py
Light edit
crash_file_from_frame()
is ASAN-specific; git-log logic is generic. Drop entirely if no upstream.
harness/config.py
Light editMay need new fields (
profile
, 
run_command
instead of 
binary_path
); 
attack_surface
likely stays
harness/artifacts.py
Light edit
crash_type
/
exit_code
semantics may shift; 
ReportVerdict.section_scores
keys must match new sections
harness/dedup.py
Light editSignature function needs the new parser; grouping logic is generic
harness/prompts/recon_prompt.py
Light editMostly language-agnostic; scrub C idioms
harness/cli.py
UnchangedOrchestration is domain-neutral
harness/agent.py
UnchangedAgent runner is generic
harness/docker_ops.py
UnchangedContainer plumbing is generic (may need changes if isolation ≠ Docker)
harness/find.py
, 
grade.py
, 
recon.py
, 
judge.py
, 
patch.py
UnchangedFlow is generic; only injected prompts change
文件是否为C/C++特定？功能说明
harness/prompts/find_prompt.py
是 — 需要重写漏洞分类、质量等级、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++ target"、"sanitizer output"
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日志逻辑是通用的。如果没有上游仓库则可完全移除。
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
无需修改流程是通用的；仅注入的提示词需要改变

STEP 3 — Present a plan and get confirmation

步骤3 — 展示计划并获得确认

Before editing anything, summarize back to the user:
  1. What you understood — restate their goal in one sentence
  2. What will change — list each file you'll edit with a one-line rationale
  3. What stays — reassure them the orchestration core is untouched
  4. Open questions — anything you're still unsure about
Wait for explicit approval. If they adjust the plan, incorporate and re-confirm.
在编辑任何文件之前，向用户总结：
  1. 你的理解 — 用一句话重述用户的目标
  2. 需要修改的内容 — 列出每个要编辑的文件及一行理由
  3. 保持不变的内容 — 向用户保证编排核心逻辑不会改动
  4. 未明确的问题 — 任何你仍不确定的点
等待用户明确批准。如果用户调整计划，整合后再次确认。

STEP 4 — Execute

步骤4 — 执行

Edit the files per the approved plan. Work through them in dependency order: prompts and parser first (they're standalone), then config/artifacts, then the target template, then README. Commit incrementally if the user wants checkpoints.
根据批准的计划编辑文件。按依赖顺序处理：先处理提示词和解析器（它们是独立的），然后是配置/数据契约，接着是目标模板，最后是README。如果用户需要检查点，可分步提交。

STEP 5 — Validate

步骤5 — 验证

  1. Add a canary target under 
    targets/<domain>-canary/
    with 2–3 planted bugs of the new class
  2. Run: 
    bin/vp-sandboxed run <domain>-canary --model <model-id> --runs 3 --parallel --stream --max-turns 50
    (use Claude Opus unless the user specifies a different model). Run 
    ./scripts/setup_sandbox.sh
    once first if the sandbox isn't already set up.
  3. Confirm all planted bugs are found and graded PASS
  4. Confirm judge triage worked: 
    cat results/<domain>-canary/<ts>/reports/judge_log.jsonl
    — expect one NEW per distinct bug, DUP_SKIP for repeats
  5. Confirm reports landed: 
    ls results/<domain>-canary/<ts>/reports/bug_*/report.json
    and spot-check section scores
  6. Run 
    vuln-pipeline dedup results/<domain>-canary/
    and confirm signatures group correctly
  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/
    并确认签名分组正确