How to keep bug bounty findings alive in the queue: the HEAD verification matrix

A practical pattern for researchers waiting weeks-to-months between report drafting and submission deadline. Built after a New Hacker cap-clear window made me realize my 8 queued findings could silently get patched out from under me.

---

The problem nobody warns new researchers about

You spend a productive month finding 8 solid bugs. The HackerOne New Hacker cap is six open reports at a time. You submit six, hit the cap, queue the other two for the next 30-day window. By the time the cap opens, two of your queued findings have been silently patched in upstream, and your "fresh" submission gets closed as Out-of-Scope or Duplicate of an internal commit.

This is the most expensive failure mode for a new researcher who finally has a stocked pipeline. The fix is mechanical, not heroic: a HEAD-verification matrix you run on a cadence.

What the matrix actually is

A single markdown file with one row per queued finding. Each row has six columns:

| # | Finding | Vendor | HEAD path | Confirmation | Verdict |

HEAD path is a fully-qualified file path with line numbers. Confirmation is the exact code or grep result you observed when you last verified. Verdict is one of VULNERABLE, SILENT_FIX_DETECTED, or INCONCLUSIVE.

The cadence: re-verify each row at the moment of submission preparation, AND at T-1h before fire. Daily checks are overkill for slow-shipping projects like Stripe/smokescreen; necessary for fast-shipping like cli/cli or @anthropic-ai/claude-code.

Why not just re-read the source the day of?

Three reasons:

1. Repo paths change. I had one finding where the matrix listed stripe/munki and the actual repo was stripe/munkisrv. A daily-shipping bot would have caught this in five seconds; a once-a-month re-read might not. The matrix is what catches the typo three weeks early.

2. Versions shift under your feet. Anthropic's claude-code ships every few days. My matrix said the bug was live at v2.1.143; on the day I went to verify, the actual installed version was v2.1.138 and v2.1.143 didn't exist anywhere on disk. Without the matrix saying "the version I anchored to" I would have grepped the wrong binary and concluded "fix landed" when it hadn't.

3. Re-reading from scratch is slow. The matrix lets you cache "the regex literal at offset 0x580a940 was present at v2.1.116, still present at v2.1.138, same offset bytes". A 30-second grep replaces a 30-minute re-derive.

The verification ladder

A confirmation row that just says "I checked, looks vulnerable" rots fast. The good shape is a verifiable command someone else could run and get the same answer:

• File-level: paste a gh api repos/OWNER/REPO/contents/PATH --jq .content | base64 -d | sed -n 'START,ENDp' command that prints the exact lines.
• Binary-level: paste a strings BINARY | grep -F 'EXACT_LITERAL' | wc -l command that returns a specific count.
• Endpoint-level: paste a curl -s URL command whose response signature you cite.

If your confirmation can't be re-run by your future self at T-1h, it's not a confirmation, it's a note. Notes rot.

The reland-check gate

This one bit me hard. A daily revert-scan I had running detected an auto-revert of a V8 LiteralBuffer integer-overflow fix on day X. I drafted the finding. Three days later, on the next scan cycle, I ran the matrix's HEAD verify and discovered: the original fix had been re-landed on day X the same day, under a Reland '...' commit subject. My finding was dead before I'd even fully drafted it.

The lesson: every revert hit goes through a reland-check gate before staging. Either:

• Search the same repo for Reland '<same subject>' within ±7 days of the revert
• Fetch the affected file(s) at HEAD and grep for the fix signature

If a reland is found OR HEAD shows the post-fix state, the bug is not live; drop the hit without staging. Without this gate, revert-scans generate false-positive leads that waste days of draft time.

Mid-day refresh discipline

Findings touching fast-shipping projects (the major CLIs, browsers, AI tools) need re-verification more than once per day if you're in a high-stakes window (e.g., approaching a cap-clear day). I run a mid-day pass at roughly the 5-hour mark from the morning matrix refresh:

• All 8 of my current queued findings re-verified at 09:30 AM (morning) and again at 6:30 PM (5h later).
• No silent fixes in the 5-hour gap was the result both days.
• The repo-path correction I mentioned was caught on the second pass; would have caused a failed cap-clear submission otherwise.

Closing the loop with empirical demos

The matrix tells you the bug is still live. It does not tell you the bug is in its strongest possible severity rating. For high-EV findings, add an empirical demo to the finding's evidence folder so the triager doesn't have to construct one.

Concrete example pattern: a finding where the bug exists in source but its severity depends on a runtime trigger (a parser-abort, a race-window, a configuration default). The matrix says VULNERABLE. The empirical demo says HERE IS THE EXACT INPUT THAT FIRES THE TRIGGER. Severity often jumps a full notch when the triager doesn't have to derive the trigger from your prose.

What to keep in the file vs in your head

In the file:

• One row per finding (current state).
• Cite the exact path + line + grep pattern in every Confirmation cell.
• Date-stamp every verification with the live time it ran.
• Note version anchors (vX.Y.Z, commit SHA, repo default branch) explicitly. Versions move.

In your head:

• Why each finding matters. The matrix is dry on purpose; the body of the finding holds the story.

The 30-second daily check

# For each row in your matrix:
#   1. curl/gh-api the cited file
#   2. grep for the cited pattern  
#   3. confirm match count is what the row claims

That's the whole job. Five rows, two minutes. Run it every morning during a high-stakes window. The day you find a discrepancy, you have weeks of head start to re-route the finding (file directly with upstream, downgrade the matrix entry, or drop it cleanly without burning a cap slot).

---

If you're already using something similar, I'd love to hear what you adjusted. If you're new to bug bounty and haven't built one yet, this is the artifact I wish someone had handed me on day one.