finding-tracker

name	finding-tracker
description	Aggressive offensive finding management for authorized red team bug bounty work. Use to log, track, chain, and promote attack leads as fast as possible while still preventing real duplicate effort. Designed for hunters who want to stay aggressive: log weak signals early, keep promising leads alive longer, and only de-escalate after real effort. Works with the rest of the red-team skill suite (especially the aggressive code-vulnerability-review).
metadata	{"short-description":"Red-team finding tracker — log fast, chain aggressively, de-escalate only after effort","category":"vulnerability-research","priority":"critical"}

Finding Tracker (Red Team Edition)

This is your attack surface memory.

The goal is not to keep a perfectly clean database. The goal is to never lose a promising lead, surface real exploit chains, and move the highest-impact findings to proof as quickly as possible.

You are allowed (and encouraged) to be somewhat messy in the early stages. A half-baked but high-upside idea is more valuable than a perfectly documented de-escalated non-finding.

Red Team Philosophy

• Log first, overthink later. If something feels interesting or "smells like a bug," put it in the tracker immediately in discovered state. Momentum matters more than perfect categorization early on.
• Keep weak signals alive. Many critical bugs start as low-confidence or "probably not exploitable" notes. Do not rush to de-escalate.
• De-escalation is expensive. Only move something to de-escalated after you have actually spent meaningful effort trying to make the attack work.
• Chains are more important than individual findings. Actively look for and record relationships between leads.
• Duplicate policy is a tool, not a religion. When in doubt during active hunting, log it separately for a while. You can always merge later.

States (Use Them, Don't Fear Them)

• discovered — Anything that looks like it might be a bug or a useful primitive. Low bar. This is where most things should live during active hunting.
• confident — You have reasonable evidence + a plausible attack path or reachability story. This is the state you want to push interesting leads toward.
• proofed — Only set this after a successful triage-verifier run (or equivalent strong reproduction + negative controls). Do not abuse this state.
• de-escalated — The lead was pursued and does not appear to yield high-severity impact under the current threat model. Still keep these — they are useful context for future chains.

When to Log Aggressively

Log a new discovered finding when you see:

• A strange trust boundary or missing check
• An interesting primitive that could be useful in a chain
• A code path that "feels wrong" even if you can't yet articulate the full attack
• A weak signal from a subagent that deserves follow-up
• Any potential bypass, confusion, or assumption violation

Do not wait until you have a full exploit or high confidence. That is what the confident state is for.

Duplicate Policy (Red Team Version)

Only treat something as a hard duplicate during active hunting if the root cause and attack surface are essentially identical.

Slightly different attack paths, different privilege levels, different impact boundaries, or different components are often worth tracking separately for a while — especially if one path looks more promising than the other.

When you do merge, always add a milestone explaining why.

State Transitions (Preferred Direction)

Preferred flow: discovered → confident → proofed

Backward movement is allowed and should be documented:

• confident → discovered (new information made it weaker)
• confident / proofed → de-escalated (after real effort)

Do not treat de-escalation as a failure. Treat it as "this particular path is not high-value right now."

Helper Script Usage

The script is at: .grok/skills/finding-tracker/scripts/findings.py

Key commands (run from inside a programs/{program}/ or target directory):

# Overview
python3 .grok/skills/finding-tracker/scripts/findings.py summary
python3 .grok/skills/finding-tracker/scripts/findings.py list --state active

# Search before adding (still do this, but don't let it paralyze you)
python3 .grok/skills/finding-tracker/scripts/findings.py search --title "..." --target "..." 

# Log a lead fast (this should feel lightweight)
python3 .grok/skills/finding-tracker/scripts/findings.py add \
  --title "Interesting AC behavior in Schnorr MP DKG" \
  --target "COIN-004" \
  --category "crypto" \
  --summary "Possible issue with share verification under certain refresh trees" \
  --evidence "src/cbmpc/protocol/ec_dkg.cpp:842"

# Promote when evidence justifies it
python3 .grok/skills/finding-tracker/scripts/findings.py update F-00XX --state confident \
  --note "Confirmed via subagent review + manual trace"

# Record real effort before de-escalating
python3 .grok/skills/finding-tracker/scripts/findings.py update F-00XX --state de-escalated \
  --note "Spent 3 iterations + subagent pass. No practical path to key exposure under malicious minority model."

# Chain findings
python3 .grok/skills/finding-tracker/scripts/findings.py add \
  --title "DKG share verification → Schnorr signing forgery chain" \
  --category "exploit-chain" \
  --related F-0012 --related F-0017

The script will refuse obvious duplicates by default. Use --force if you have a good reason to log something similar anyway.

Integration With Red Team Workflow

• After every significant chunk of code-vulnerability-review work, dump promising leads into the tracker.
• Before starting a new /goal iteration, check summary or list --state active so you don't lose context.
• Use this tracker to feed exploit-chain-analysis and triage-verifier.
• Update the human-readable ANALYSIS.md + FINDINGS.md after major tracker changes.

Output Style When Reporting

Keep it short and useful:

Finding tracker:
- F-0042 confident: AC tree verification gap in refresh path (COIN-004)
- F-0043 discovered: Potential nonce bias via early ElGamal commitment in Schnorr MP
- F-0039 de-escalated: TDH2 duplicate rid (no key exposure path after deeper review)
- New chain: F-0042 + F-0047 (possible full DKG state poisoning)

Rules (The Non-Negotiable Ones)

• Never fabricate evidence or invent impact.
• Never delete de-escalated findings (they are context).
• Always search before adding a completely new finding.
• proofed is sacred — only set it after real verification work.

Everything else is flexible in service of actually finding serious bugs.

This tracker exists to help you win, not to make you look responsible. Use it like a weapon.