Module S02 — Bug Bounty Harness Engineering

Bug Bounty Harness Engineering

Persistent engagement memory, the offensive tool suite, evidence chain engineering, and the signal/noise triage pipeline.

90
minutes
8
artifacts
4
sub-sections
A harness that operates across multi-day engagements with persistent state, structured evidence, and client-ready output. This module builds the four pillars of a production bug bounty harness: ChromaDB-backed engagement memory, Pydantic-wrapped offensive tools, hash-chained evidence logging, and a model-judged triage pipeline that turns 200 raw findings into 1-3 actionable reports.
Key Claims
Load-Bearing Claims

The context window is a session primitive, not a persistence mechanism. Bug bounty engagements span days — memory that compacts is memory that fails.

Every offensive tool is a wrapped tool — Pydantic schema, scope check, rate limiting, structured output. The model never constructs CLI commands.

The evidence chain is hash-linked and append-only. scope_ref ties every tool call to the authorization that permitted it.

Model-judged triage uses a secondary LLM separate from the finder — preventing confirmation bias in severity assessment.

After This Module
01
Design and implement a persistent target-state memory store with structured deduplication at write time.
02
Wrap offensive tools (nmap, httpx, nuclei, ffuf) as harness tools with Pydantic schemas, scope-check wrappers, and rate limiting.
03
Implement an evidence logger as hash-chained, append-only middleware with scope_ref stamping.
04
Build a signal/noise triage pipeline with model-judged triage and measure precision/recall against a labeled dataset.
05
Defend the vector store choice (ChromaDB vs Qdrant vs LanceDB) for a given engagement scale.
Artifacts