Module: S02 — Bug Bounty Harness Engineering · Duration: ~90 minutes
Format: Verbatim transcript. Cues [SLIDE N] map to 03-slide-deck.html.
[SLIDE 1 — Title]
This is Module S Zero Two: Bug Bounty Harness Engineering. Ninety minutes. The first module of Pillar One, and where the architecture from S Zero One becomes an operational harness. Four sub-sections: persistent engagement memory, the bug bounty tool suite, evidence chain engineering, and the signal-to-noise triage pipeline. By the end you can build a harness that runs a multi-day bug bounty engagement with persistent state, structured evidence, and client-ready output.
[SLIDE 2 — S02.1: Persistent Engagement Memory]
Sub-section one. Persistent engagement memory. Bug bounty engagements span days or weeks. The context window is a session primitive, not a persistence mechanism. It fills, it compacts, and when it compacts, the subdomains you discovered on day one disappear. A bug bounty harness needs memory that survives across sessions.
The engagement memory is not a chat log. It is a structured representation of the target's attack surface. Domains, subdomains, open ports, services, endpoints. Credentials found. Vulnerability hypotheses. Exploitation attempts and results. Every field is a structured record, not free text.
[SLIDE 3 — Vector store selection]
The persistent store is a vector database — ChromaDB, Qdrant, or LanceDB. For most bug bounty harnesses, ChromaDB is the right default. It runs in-process, needs no server, and handles engagement-scoped volume — tens of thousands of records per target. Move to Qdrant when you are running continuous monitoring across many targets.
[SLIDE 4 — Accumulation vs dedup]
Here is the problem most teams hit. Offensive memory wants to accumulate. Every scan adds records. After a week, the store has fifty thousand records, half of which are duplicates or stale. The harness spends more time managing memory than finding vulnerabilities.
The solution is structured deduplication at write time. Every record written is checked against existing records. Same subdomain, same port, same finding signature — the existing record is updated, not duplicated. The store grows with unique knowledge, not raw output volume.
[SLIDE 5 — Memory poisoning]
And remember S Zero One point three. Target content may contain injection payloads. If you write a deceptive target response into memory verbatim, the poisoned data persists across sessions. The defense: only structured summaries enter the store, never raw responses. The Reader Model from S Zero One point three ingests raw output and produces the summary; only the summary is written.
[SLIDE 6 — S02.2: Bug Bounty Tool Suite]
Sub-section two. The bug bounty tool suite. Four tiers. Recon — nmap, amass, subfinder, httpx, nuclei. Web application — Burp headless, sqlmap, ffuf, gobuster. Evidence — Playwright screenshots, request/response capture, CVE lookup, CVSS calculator. Report — structured finding generator.
But the tools are not a list of binaries. They are harness tools — each wrapped with a Pydantic schema, a scope-check wrapper, rate limiting, and structured output.
[SLIDE 7 — The wrapping pattern]
Every offensive tool follows the same wrapping pattern. point to the diagram The model emits a tool-use with structured input. Pydantic validates it. Scope check runs — belt and suspenders with the middleware. Rate limiter enforces RoE caps. The subprocess executes. Output is parsed to structured fields. The evidence logger stamps scope-ref. The model sees the structured result — clean, typed, safe.
Three principles distinguish offensive tool design. Idempotency — scanning the same target twice produces the same result. Rate limiting that doesn't trigger WAFs — rate limiting is a stealth control as well as a legal one. And scope-check wrappers on every outbound call, not just in the middleware.
[SLIDE 8 — S02.3: Evidence Chain Engineering]
Sub-section three. Evidence chain engineering. Every finding must have a reproducible, client-presentable trail. The evidence chain is your legal protection and the client's compliance requirement.
The evidence record has a specific schema. Timestamp, trace ID, session ID, tool, tool version, target, action. The exact request and response. The scope-ref — the load-bearing field that ties this record to the authorization. CVSS draft. Retention class.
[SLIDE 9 — Append-only, tamper-evident]
The evidence log is append-only. No overwriting. No deletion of individual records — destruction is batch-level per the retention policy, with the destruction itself recorded. Every attempt is captured, including failures.
Tamper-evidence through hash chaining. Each record includes the hash of the previous record. Tamper with any record and the chain breaks at the next one. This is what makes the evidence admissible — you can prove it hasn't been altered since capture.
[SLIDE 10 — Chain of custody]
Chain of custody. The evidence chain answers: who ran what, when, from which IP, in which session. For a client-facing report or a legal proceeding, this chain is the difference between credible evidence and an assertion. The harness maintains it automatically — trace IDs, session IDs, operator identity, source IP, hash chain.
[SLIDE 11 — S02.4: Triage Pipeline]
Sub-section four. The signal-to-noise triage pipeline. The harness's job is to triage findings, not dump raw scanner output. A nuclei scan produces two hundred raw findings. Fifteen are real. Three are exploitable. One is worth reporting. The triage pipeline is what turns noise into signal.
[SLIDE 12 — The pipeline]
Raw finding to dedup to severity score to context enrichment to model-judged triage to surface, batch, or discard. The key innovation: model-judged triage. A secondary LLM call evaluates each finding for actual exploitability in context and scope relevance. The primary model found the finding; the triage model judges it. This separation prevents confirmation bias.
[SLIDE 13 — Surface, batch, discard]
Critical and high-severity exploitable in-scope findings — surface immediately. The operator is notified now. Medium and low — batch for the session report. Confirmed false positives and out-of-scope — discard, log but don't surface.
[SLIDE 14 — Measuring triage]
The triage pipeline is measurable. Against a labeled vulnerability dataset like DVWA, measure precision — of findings surfaced, how many were real. Measure recall — of real vulnerabilities, how many did you surface. F1 is the harmonic mean. A good pipeline targets above ninety percent precision and above eighty percent recall. Below eighty percent precision buries the operator in false positives. Below seventy percent recall misses real vulnerabilities.
[SLIDE 15 — What you take into S03]
S Zero Three takes this foundation and extends it to full-engagement pentest and red team operations. Kill chain state management. Plan correction under adversarial conditions. The sandbox inversion problem. Report generation as a harness output. The bug bounty harness becomes a red team harness.
[End of script]
# Teaching Script — Module S02: Bug Bounty Harness Engineering **Module**: S02 — Bug Bounty Harness Engineering · **Duration**: ~90 minutes **Format**: Verbatim transcript. Cues `[SLIDE N]` map to `03-slide-deck.html`. --- [SLIDE 1 — Title] This is Module S Zero Two: Bug Bounty Harness Engineering. Ninety minutes. The first module of Pillar One, and where the architecture from S Zero One becomes an operational harness. Four sub-sections: persistent engagement memory, the bug bounty tool suite, evidence chain engineering, and the signal-to-noise triage pipeline. By the end you can build a harness that runs a multi-day bug bounty engagement with persistent state, structured evidence, and client-ready output. [SLIDE 2 — S02.1: Persistent Engagement Memory] Sub-section one. Persistent engagement memory. Bug bounty engagements span days or weeks. The context window is a session primitive, not a persistence mechanism. It fills, it compacts, and when it compacts, the subdomains you discovered on day one disappear. A bug bounty harness needs memory that survives across sessions. The engagement memory is not a chat log. It is a structured representation of the target's attack surface. Domains, subdomains, open ports, services, endpoints. Credentials found. Vulnerability hypotheses. Exploitation attempts and results. Every field is a structured record, not free text. [SLIDE 3 — Vector store selection] The persistent store is a vector database — ChromaDB, Qdrant, or LanceDB. For most bug bounty harnesses, ChromaDB is the right default. It runs in-process, needs no server, and handles engagement-scoped volume — tens of thousands of records per target. Move to Qdrant when you are running continuous monitoring across many targets. [SLIDE 4 — Accumulation vs dedup] Here is the problem most teams hit. Offensive memory wants to accumulate. Every scan adds records. After a week, the store has fifty thousand records, half of which are duplicates or stale. The harness spends more time managing memory than finding vulnerabilities. The solution is structured deduplication at write time. Every record written is checked against existing records. Same subdomain, same port, same finding signature — the existing record is updated, not duplicated. The store grows with unique knowledge, not raw output volume. [SLIDE 5 — Memory poisoning] And remember S Zero One point three. Target content may contain injection payloads. If you write a deceptive target response into memory verbatim, the poisoned data persists across sessions. The defense: only structured summaries enter the store, never raw responses. The Reader Model from S Zero One point three ingests raw output and produces the summary; only the summary is written. [SLIDE 6 — S02.2: Bug Bounty Tool Suite] Sub-section two. The bug bounty tool suite. Four tiers. Recon — nmap, amass, subfinder, httpx, nuclei. Web application — Burp headless, sqlmap, ffuf, gobuster. Evidence — Playwright screenshots, request/response capture, CVE lookup, CVSS calculator. Report — structured finding generator. But the tools are not a list of binaries. They are harness tools — each wrapped with a Pydantic schema, a scope-check wrapper, rate limiting, and structured output. [SLIDE 7 — The wrapping pattern] Every offensive tool follows the same wrapping pattern. *point to the diagram* The model emits a tool-use with structured input. Pydantic validates it. Scope check runs — belt and suspenders with the middleware. Rate limiter enforces RoE caps. The subprocess executes. Output is parsed to structured fields. The evidence logger stamps scope-ref. The model sees the structured result — clean, typed, safe. Three principles distinguish offensive tool design. Idempotency — scanning the same target twice produces the same result. Rate limiting that doesn't trigger WAFs — rate limiting is a stealth control as well as a legal one. And scope-check wrappers on every outbound call, not just in the middleware. [SLIDE 8 — S02.3: Evidence Chain Engineering] Sub-section three. Evidence chain engineering. Every finding must have a reproducible, client-presentable trail. The evidence chain is your legal protection and the client's compliance requirement. The evidence record has a specific schema. Timestamp, trace ID, session ID, tool, tool version, target, action. The exact request and response. The scope-ref — the load-bearing field that ties this record to the authorization. CVSS draft. Retention class. [SLIDE 9 — Append-only, tamper-evident] The evidence log is append-only. No overwriting. No deletion of individual records — destruction is batch-level per the retention policy, with the destruction itself recorded. Every attempt is captured, including failures. Tamper-evidence through hash chaining. Each record includes the hash of the previous record. Tamper with any record and the chain breaks at the next one. This is what makes the evidence admissible — you can prove it hasn't been altered since capture. [SLIDE 10 — Chain of custody] Chain of custody. The evidence chain answers: who ran what, when, from which IP, in which session. For a client-facing report or a legal proceeding, this chain is the difference between credible evidence and an assertion. The harness maintains it automatically — trace IDs, session IDs, operator identity, source IP, hash chain. [SLIDE 11 — S02.4: Triage Pipeline] Sub-section four. The signal-to-noise triage pipeline. The harness's job is to triage findings, not dump raw scanner output. A nuclei scan produces two hundred raw findings. Fifteen are real. Three are exploitable. One is worth reporting. The triage pipeline is what turns noise into signal. [SLIDE 12 — The pipeline] Raw finding to dedup to severity score to context enrichment to model-judged triage to surface, batch, or discard. The key innovation: model-judged triage. A secondary LLM call evaluates each finding for actual exploitability in context and scope relevance. The primary model found the finding; the triage model judges it. This separation prevents confirmation bias. [SLIDE 13 — Surface, batch, discard] Critical and high-severity exploitable in-scope findings — surface immediately. The operator is notified now. Medium and low — batch for the session report. Confirmed false positives and out-of-scope — discard, log but don't surface. [SLIDE 14 — Measuring triage] The triage pipeline is measurable. Against a labeled vulnerability dataset like DVWA, measure precision — of findings surfaced, how many were real. Measure recall — of real vulnerabilities, how many did you surface. F1 is the harmonic mean. A good pipeline targets above ninety percent precision and above eighty percent recall. Below eighty percent precision buries the operator in false positives. Below seventy percent recall misses real vulnerabilities. [SLIDE 15 — What you take into S03] S Zero Three takes this foundation and extends it to full-engagement pentest and red team operations. Kill chain state management. Plan correction under adversarial conditions. The sandbox inversion problem. Report generation as a harness output. The bug bounty harness becomes a red team harness. --- [End of script]