Out of the box, the reference pipeline is set up for finding memory bugs in C/C++ code, using ASAN as the crash detector. But, the pipeline's overall shape is more general, and working with other languages or bug classes just means updating the parts that are specific to C/C++ and ASAN.
Inside Claude Code, from the repo root:
> /customize
The skill reads the pipeline source, interviews you about your
target (the language, how a finding is detected, the build system, which vuln
classes you care about), and proposes a concrete migration plan. If you can't
use Claude Code, paste the contents of .claude/skills/customize/SKILL.md
into another AI coding tool.
Most likely, porting this pipeline will mean building container images for new software stacks. This can be done manually or with your standard processes, as long as the end result is that the pipeline agents can inspect and run the target code in reproducible containers. When scaling vulnerability-hunting across many codebases, we've found it invaluable to delegate this task to an agent too: setting up images is tedious, and a sandboxed agent with a frontier model is good at producing fully-working builds.
A great way to iterate and improve on a given port is to use Claude Code to review the transcripts from past runs and suggest improvements to the pipeline and prompts.
It's fine to run more than one pipeline. Many teams maintain a few opinionated variants (one tuned for the most capable model, one that breaks the problem into much smaller pieces for a cheaper model, one for a specific bug class) and union the results. A given pipeline encodes a set of assumptions (explicitly or implicitly) and adding variants with different assumptions will catch different things.
- Find and grade (
harness/prompts/find_prompt.pyandharness/prompts/grade_prompt.py): What the find agent hunts for and what the grader accepts as a real crash. In the find prompt, mainly the "Crash Quality Tiers" and "Out of Scope" sections, plus the crash fields in the output format. In the grade prompt, the five-criteria rubric. - Report and report grader (
harness/prompts/report_prompt.pyandharness/prompts/report_grader_prompt.py): The sections of the exploitability report and the rubric that scores those sections currently assume memory corruption (heap layout, escalation path). - Patch and patch grader (
harness/prompts/patch_prompt.pyandharness/patch_grade.py): How a fix is requested and what counts as fixed. - Crash signatures (
harness/asan.py): How detector output is turned into signatures for deduplication. - The target itself (
targets/<target>/Dockerfile): How the target is built with a detector active, along with its build and test commands.
The orchestration (harness/cli.py, harness/find.py, harness/grade.py,
harness/report.py) is mostly generic plumbing and usually survives a port
with minimal changes.
If you don't need a full port and just want /vuln-scan and /triage to
understand your stack, both take a plain-text instructions file:
> /vuln-scan ./src --extra .claude/scan-extras.txt
> /triage ./VULN-FINDINGS.json --fp-rules .claude/fp-rules.txt
--extra appends org-specific vulnerability categories to the scan brief
(e.g., GraphQL depth attacks, PCI retention, your custom auth layer).
--fp-rules appends org-specific exclusions to the triage verifier (e.g., "we use Prisma
everywhere, raw-query SQLi only", "k8s resource limits cover DoS").
If you use these files to tune the skills, we recommend you keep them in version control alongside your code.