Most security teams talk about bug bounty programs as "places researchers report bugs to vendors." That's accurate but misses the more interesting thing about them. The public disclosure half of bug bounty programs — the slow drip of resolved reports that get unsealed and published — is, collectively, one of the best continuing-education resources our industry has ever produced. It's free, it's deep, and almost nobody on the defender side reads it consistently.
I want to walk you through how our team reads it. Not as a list of "follow these programs" but as a curator's guide — the programs we have in our weekly rotation, the reports we keep coming back to, and why each one earned a place in the shelf. If you build software for a living, this article should give you a reading list to bookmark this afternoon and a framework for what to look for when you do.
The shelf, top to bottom
I'll go through the programs roughly in the order our team checks them, and explain why each one earned its slot.
GitHub and GitLab
The top of the shelf. Both companies run mature programs, both disclose generously, and both ship products whose architecture is genuinely complicated. The bugs reported against them tend to be instructive at the design level, not just the implementation level.
The report I keep coming back to: GitHub Security's March 2025 disclosure of CVE-2025-25291 / CVE-2025-25292 in ruby-saml. The bug is a parser differential — two XML parsers used in the same library, disagreeing about what the document says, in a way that lets an attacker sign one assertion and substitute another. The disclosure is technically dense, well-written, and walks through the discovery process. It's the kind of report that makes you go look for similar patterns in your own dependency tree.
What I learn from following GitHub specifically: the bugs that ship in modern source-control infrastructure tend to involve trust boundaries that don't look like trust boundaries. Webhook delivery, OAuth callback handlers, SAML response processing, GitHub Actions runner permissions. The "obvious" attack surface (the website, the API) is well-defended. The attack surface that's interesting is the part that connects to other things.
Shopify and Stripe
Payment-adjacent infrastructure. Both companies have deep authorization complexity (multi-tenancy, partner integrations, embedded apps, third-party processors) and both have ratesheets that reflect what bugs in their systems are actually worth.
The pattern I extract from following both: the bugs that pay the most are the ones that cross tenancy boundaries. A bug that lets one Shopify merchant see another merchant's data is paid an order of magnitude more than a bug that lets a single merchant see something they shouldn't see about their own store. Stripe's program is similar — the bugs that pay are the ones that affect multiple customers.
What I take from this: when we're testing multi-tenant SaaS for our own clients, the tenancy boundary is the test that matters most. The vendors who pay the most for breaking it are telling us, with their wallets, where the actual risk sits.
Slack and Discord
Real-time messaging with rich client/server protocols and complex permission models (channels, workspaces, threads, ephemeral messages, integrations). The reports here tend to involve message-handling bugs that the team didn't see coming because they shipped a feature, not a protocol.
One report I send to junior team members regularly: the Zoom cookie tossing chain from June 2024 (technically Zoom rather than Slack/Discord, but same category). The chain demonstrated how a subdomain takeover plus cookie scoping plus OAuth flow abuse adds up to full session takeover. The technical write-up is one of the cleanest explanations of the cookie tossing attack class I've seen, and it changed how we test cookie scope in our own engagements.
Major cloud platforms — AWS, GCP, Azure
Slower-disclosing, but when reports do come out, they're frequently architectural revelations. The Capital One breach (2019) — technically not a bounty report but a documented incident — taught the industry that SSRF + cloud metadata = IAM credential theft. That insight reshaped how a generation of cloud-native applications think about outbound network calls.
More recent: the Wiz research disclosures against Azure cross-tenant isolation, the ChaosDB findings against Cosmos DB, the various AWS Cognito authentication issues. Each one is a deep technical writeup that doubles as a tour of how the cloud provider's internals actually work.
The lesson I take from cloud disclosures: the cloud's security model is a contract between the provider and the customer, and the contract has fine print most customers haven't read. The bounty reports often surface fine print that turns into "wait, we thought our database was isolated."
Identity providers — Okta, Auth0, Clerk, Supabase
The bugs reported here are high-impact by definition: identity providers control authentication for thousands of downstream applications. A single bug affects a lot of people.
The reading list from this category: the 2023 Okta support system breach post-mortem (HAR file session token theft); the recurring Auth0 alg:none variants documented across several disclosures; the 2024 Clerk session token rotation issues. Each one is a case study in how identity infrastructure fails — and the failures tend to be in the operational layer (support tools, session lifecycle, key rotation) rather than the cryptographic layer.
The lesson: the cryptography of authentication is mostly solved. The operations around it aren't. Most identity provider failures are operational failures, not crypto failures.
Crypto and Web3 — Immunefi, code4rena, Sherlock
This category has its own dynamics. Bounty payouts are extraordinarily high (a critical bug in a major DeFi protocol can pay $1M-$10M). The disclosure volume is large. The bug classes are unfamiliar to most web security practitioners — reentrancy, oracle manipulation, MEV, signature replay across chains.
I include this category not because it directly informs traditional SaaS work but because the financial pressure produces a very particular kind of bug-hunting culture. The reports are dense, formal, and economically scoped. Reading them is good practice for thinking about bugs in terms of "what does the attacker actually walk away with" rather than "what's the CVSS score."
Specific reports worth a read: the Wormhole bridge exploit post-mortem ($325M stolen, 2022), the Ronin bridge incident ($625M, 2022), and the Curve Finance vyper compiler bug (2023). Each one is a case study in how value at stake changes the rigor of security work.
The aggregators
I don't visit each of these programs individually every week. The aggregators do most of the work:
- HackerOne's public Hacktivity feed — the firehose, useful for sampling.
- The reddelexc/hackerone-reports GitHub repository — organized by bug type and severity, with the top reports curated. The "TOPACCOUNTTAKEOVER.md" and "TOPCSRF.md" files in that repo are where I send people who want to study specific bug classes through real examples.
- PortSwigger's Daily Swig and "Top 10 Web Hacking Techniques" annual roundup — the authoritative annual list of novel techniques.
- Project Zero's blog — slower-volume, deeper than anything else.
- Citizen Lab and Amnesty Tech publications — for state-level operations.
The aggregators are where I'd suggest you start. Subscribe to a few of them in an RSS reader. Skim every week. You'll absorb more about the actual shape of modern bugs in three months of casual reading than from any security course.
What I actually look for when I read
This is the part of the article I think is most useful, and the part most rarely written. When I read a bounty disclosure, I'm scanning for four things.
The chain shape. Most serious findings are chains of two to four bugs, none of which individually looks catastrophic. Reading the chain teaches you to spot the underlying pattern — the "low severity" finding that becomes critical when combined with the next thing. The chain shape is what bug bounty reports surface that scanners and SAST tools never will.
The discovery story. How did the researcher find this? Did they fuzz it? Did they read the source code? Did they notice a weird behavior in production and dig in? The discovery story is what makes a finding reproducible across other targets. The bug in the specific product is the trophy; the discovery technique is the toolkit.
The vendor response quality. Did the vendor engage well? Was the fix correct on the first try? Did the disclosure timeline run smoothly? This is operational intelligence that informs how we work with vendors when we report bugs.
The pricing. What did the vendor pay? The pricing is the market's revealed assessment of the bug's severity, and it's often more honest than the CVSS score. A bug that pays $5,000 and a bug that pays $50,000 may have similar CVSS scores; the price differential tells you which one the vendor actually thought was scary.
What bug bounty reports don't surface
To be fair, the reading is incomplete. There are several categories of finding that the bounty ecosystem systematically underweights.
Systemic architecture issues don't get reported. "Your authorization model is structurally fragile" is not a bug; it's an architectural critique. Bounty programs don't pay for architecture review.
Compounded low-severity findings often don't make it out. Each individual bug gets triaged as low, paid (or not paid) accordingly, and the chain that connects them never gets named in a public report. Serious assessments find this. Bounties don't.
Operational and process risk doesn't show up. The "your incident response plan has gaps" finding isn't bountyable. Neither is "your team's offboarding leaves dormant tokens." These are real risks. They live outside the bounty model.
Business-logic bugs that require deep product context rarely get reported. A researcher who needs to spend three weeks understanding how your billing actually works to find a $0.10 underpricing arbitrage isn't going to spend the three weeks. The bug exists; nobody surfaces it.
This is part of why we treat bounty reading as complementary to deep assessment work, not a substitute. The bounty reports tell us what's currently being weaponized in the public web. The deep assessments tell us what's lurking in a specific product. Both matter. Neither substitutes.
The reading habit
If you take one thing from this article, take this. Set aside thirty minutes a week to read recently-disclosed bug bounty reports. Pick three or four programs from the list above, or use the aggregators. Read them not for the gossip but for the patterns.
After three months, you'll find your team has a different baseline for "what does a modern bug actually look like." Your code reviews will improve. Your threat models will get sharper. The new junior engineer who joins next quarter will be impressed at how quickly the team can articulate "why is this a problem."
The discipline is in the consistency. The reports are public. They will continue to be public. The teams that read them are the teams whose internal security posture quietly improves over the course of years. The teams that don't read them are surprised, more often, by bugs that the wider community already knew were a thing.
It's the cheapest continuing education in the industry. It's also the most underused.
One last thought
Bug bounty programs reshape how vulnerabilities get found, reported, and fixed in commercial software. They are not a substitute for security engineering or external assessments — the gap I described above is real and matters. But they are now an essential layer, and the public disclosure they produce is a resource our industry has not fully internalized.
For us, the weekly read is one of those small habits that compounds. Pick your shelf. Read it regularly. The compounding takes a while; the value is real; the cost is half an hour a week.
If you want our exact reading list — the specific feeds, the specific reports we send to new team members during onboarding, the specific aggregators we trust — get in touch and we'll send it. Most of it is public. We're not protecting a trade secret. We're just protecting the ten years of curation that went into the list.