customizeSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

> /customize

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: customize
description: Adapt this C/C++ ASAN vulnerability pipeline to a different vulnerability class, target shape, language, or detection mechanism. Use when the user wants to port, migrate, retarget, customize, or fork the pipeline for something other than C/C++ memory-safety bugs — web apps, smart contracts, deserialization, ML systems, or any other domain.
---

# 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 analyzes 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.

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

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). One caution: part of `harness/` doubles as shared infrastructure — `dnr_harness/` (the detection-and-response pipeline) imports `agent.py`, `sandbox.py`, `docker_ops.py`, `agent_image.py`'s `build`/`ensure_base`, `auth.py`, `cli.py`'s `resolve_target_dir`/`terminate_subprocesses`, and `prompts/system_prompt.py`'s `load_engagement_context`. A domain port should touch only the domain-specific files (the prompts, `asan.py`, `artifacts.py`, target Dockerfiles); treat any edit to the shared files as a change to both pipelines.

## STEP 2 — Interview the user

Use **AskUserQuestion** to gather requirements. Start with broad context, then narrow to technical specifics based on what they say.

### 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.

### 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 f

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.

[![ModelsAtlas audit: customize](https://modelsatlas.com/skills/anthropics/customize/badge.svg)](https://modelsatlas.com/skills/anthropics/customize/)

Not your listing, or something out of date? Claim or update your listing.