Third post in my "AI-assisted OSS contribution" series. The first two were about pre-fork due diligence and shipping a fix to ONNX with my own PR scanner. This one is about a harder game: security research and coordinated disclosure.
For a while my AI-assisted open-source work was about contributions — typo fixes, docs, small bug fixes, the occasional feature. Pull requests have a forgiving feedback loop: if a PR is wrong, a maintainer comments and you iterate. Bug bounty work is different. The feedback loop is slower, the bar for "novel and correct" is much higher, and a lot of the difficulty has nothing to do with the vulnerability itself.
I ran a small experiment: use Claude (Opus) to help me find, verify, and write up vulnerabilities in public, in-scope open-source bug bounty programs — the kind that publish a scope and a safe-harbor policy and explicitly invite testing. Here's what actually mattered, mostly the things I didn't expect.
1. The duplicate problem is the real boss fight
The single biggest risk to a bounty submission is not "is it a real bug" — it's "did someone already report it." And you usually cannot see the answer.
