BugCrowd & Researcher Philosophy Thoughts
Organisations Should never use in-house triage, Hunters and researchers should only use them as a payment platform. that's it on a napkin.
My wife had given me some play time over the festive period late 2025, and instead of using it to improve my Division2 Striker Build I decided to just put on some good music, shut the door and get back into pulling things apart, I've spent a fair amount of time in GRC settings and while I think that position is more valuable for meaningful change, I felt my hacker thinking-distance was getting shallow, or I wasn't thinking about it enough.
Anyway first on my list was a VPN Client, nothing to do with the vendor but a personal frustration led me to the target (a client had a really bad implementation of it and they would ignore me, so, it was cathartic) anyway, I got myself a nice chained Local Privilege Escalation (CVE-2025-37186) and the journey it's self was a nice re-learner and validator that I can still spar with software vulnerabilities, confidence boost and for my ADHD more dopamine than any Division2 legendary mission. cool.
Who Do I Speak Too ?
So, I logged into my bugcrowd.com account and see that the vendor has a bug bounty, now, I've had a few Bugcrowd accounts mostly because I lose my shit with the unfortunately incompetent triagers, I don't know how many useful people are at Bugcrowd, and I mean useful in the context of supporting their outsourced workforce, I can tell you that it's close to 100% the number of well intended people at bugcrowd, but that's out of scope for me.
I check the scope, I submit my nicely formatted submission, screen recording, LPE PoC, nice. now I just need to sit back wait for some pat on the back and a random amount of money be offered to me for my time and creativity.
Out Of Scope (OoS)
Bugcrowd had deemed this Out-of-Scope, So, I replied to them in the submission conversation, that's cool, I'll use it for blog-fodder (I like to think my posts keep me in peoples minds for projects, work, referrals whatever, it's why I publish) and I provide them with a link to my post, and I also send the link to the product guys (as I believe I'm dealing with another wet-wipe in the triage team)

So, that was annoying no Benjamins but excited to share the work... no, no no, I get this email

I point out that it actually is in scope, by name, on the company's Bugcrowd page...

So, in good faith, I take the article down, I remove links socially etc... and for my efforts I get this beauty

What am I actually looking at here ? I reply telling everyone I could to get fucked (with rage typos).

So I took the post out of draft, and got on with my day, but digesting this posturing here's where I'm at this isn't a relationship. It's subjugation with a "community" label. 'Final warnings' and 'Unauthorized Disclosure' fuck off. ... anyway
A few days pass and I get a new email from Michael Skelton, he's a good security professional, he's Bugcrowds SVP, Service & Delivery, here's the conversation:

Sounds good! ... once more, I remove things (again, again) getting pretty childish now but this looks like an adult conversation

Was this tactical deception ?
I'm having a hard time thinking it wasn't, Michael Dropped me a convincingly decent email and just bounced, I took to Twitter DM's as a last stretch I've got that 'Make it right' money on my mind, or more accurately, my 2026 research box (a maxed out Lenovo P3)

And a final shameful DM

What a fucking Circus.
Recommendations for Organisations Using outsourced triage
If you must use these platforms, payments and aquisition only, don't let them triage, they're just low quality, and that's a conscious move for shareholder appeasement, cheap labour yields low experience, they offset the education and wisdom to be transferred during the submission, and quite honestly, you can explain it to triagers, you can't understand it for them. - Unless you give them an unauthed IDOR, or a GET Based XSS.
For the Hunters & Researchers
The Security Researcher's Decision Tree: Protecting Your Rights
Why This Exists
Bug bounty platforms have positioned themselves as the default channel for vulnerability disclosure. This is a marketing success, not a security necessity. The platforms benefit from this positioning. Researchers do not.
When you submit through a platform, you:
- Surrender control of your own research - if you let it.
- Accept unilateral terms you cannot negotiate - if you let it.
- Grant confidentiality rights over work you conducted independently - if you let it.
- Subject yourself to disciplinary systems with no recourse - if you let it.
- Become a managed resource rather than an independent professional - if you let it.
When you go direct, you:
- Maintain ownership of your work
- Negotiate terms as equals
- Control your own disclosure timeline
- Build direct relationships with security teams
- Retain the right to publish your research
- They are 10000% more intimate with the software and services you're speaking about, they're the SME's not some OWASP top 10 Aficionado.
The decision tree below prioritises your interests.
Stage 1: Discovery
You've found a vulnerability. Before doing anything else, document everything independently.
- Screenshot or record your findings
- Write up your methodology
- Timestamp your documentation (email it to yourself, commit to a private repo, whatever creates a verifiable record)
- Do not submit anywhere yet
This establishes that the research existed before any platform involvement.
Stage 2: Identify the Vendor
Find the vendor's direct security contact.
Check for: security.txt file at /.well-known/security.txt, security@ email address, dedicated vulnerability disclosure page, PSIRT (Product Security Incident Response Team) contact.
If direct contact exists: proceed to Stage 3.
If no direct contact exists and only a bug bounty programme is listed: proceed to Stage 4.
Stage 3: Direct Disclosure (Preferred Path)
Contact the vendor directly. Your communication should establish:
- You are an independent security researcher
- You have identified a vulnerability in their product/service
- You are offering coordinated disclosure
- You expect acknowledgment, a timeline for remediation, and (if applicable) compensation
If they respond with "please submit through our bug bounty platform": proceed to Stage 4.
If they do not respond: proceed to Stage 5.
Stage 4: Platform as Payment Processor Only
The vendor has directed you to a bug bounty platform, or no direct channel exists. You will use the platform, but you will not accept their standard terms.
Before submitting, send a message through the platform (or to the vendor directly, CC'ing the platform) that explicitly rejects the default terms.
Proposed language:
"I am submitting this vulnerability report at the direction of [Vendor Name], who has indicated that [Platform Name] is their preferred channel for receiving security research and processing payment.
I wish to make the following explicit:
I do not accept [Platform Name]'s Standard Disclosure Terms or Code of Conduct as governing this submission. My agreement is with [Vendor Name], not with [Platform Name]. [Platform Name] is acting as a payment processor and communication relay, not as a party to any confidentiality or disclosure agreement.
My terms are as follows: I will provide full technical details to [Vendor Name] through this platform. I will refrain from public disclosure for [90 days] from the date of this submission, or until a fix is deployed, whichever comes first. This confidentiality is contingent on [Vendor Name] acknowledging receipt within [7 days] and confirming that compensation will be provided for valid findings. In the absence of such confirmation, I reserve all rights to disclose this research through channels of my choosing.
If [Vendor Name] or [Platform Name] do not agree to these terms, please inform me immediately and I will withdraw this submission and pursue alternative disclosure.
By submitting through this platform, I am not consenting to any terms beyond those explicitly stated above."
What this achieves:
- Establishes the platform as a payment processor, not a governing authority
- Creates a written record that you rejected their standard terms
- Makes your actual agreement explicit and bilateral
- Preserves your right to disclose if they reject your work or fail to respond
- Puts the burden on them to object rather than assuming your consent
If they accept or process your submission without objection: your terms govern.
If they reject your submission citing their standard terms: you have lost nothing. Your research remains yours. Proceed to Stage 5.
If they mark it Out of Scope: your confidentiality obligation (under your terms) does not apply because they have declined the work. You are free to publish.
Stage 5: Alternative Disclosure
The vendor has not responded, or has rejected your submission, or has refused your terms.
Your options:
Full public disclosure. Publish your research. You owe nothing to parties who have declined to engage. Consider: CERT/CC coordination, your own blog, security conferences, or security media outlets.
Coordinated disclosure through a neutral third party. CERT/CC, national CSIRTs, or sector-specific ISACs can mediate disclosure without the commercial conflicts of bug bounty platforms.
Hold for future leverage. If the vendor is unresponsive now, they may become responsive when a competitor is breached or a regulator asks questions. Your documented, timestamped research remains yours.
Do not submit to a bug bounty platform under their standard terms after being rejected or ignored through direct channels. You gain nothing and surrender rights.
The Core Principles
Go direct first. Always. The platform is not the gatekeeper. The platform is a service provider that has convinced everyone it's the gatekeeper.
Document independently before any submission. Your research exists before they see it. Maintain evidence of this.
Never accept unilateral terms. If you cannot negotiate, you are not a partner. You are a resource being extracted.
Treat platforms as payment processors. They are useful for converting vulnerability reports into money. They are not useful for anything else. Do not grant them authority they have not earned.
Confidentiality is a trade, not a default. You offer confidentiality in exchange for acknowledgment, remediation, and compensation. If they offer nothing, you owe nothing.
Out of Scope means Out of Agreement. If they reject your work, the submission is nullified. You submitted an offer. They declined. No contract exists.
Your research is yours. You conducted it. You documented it. You own it. Platforms and vendors acquire rights through negotiation, not through the act of viewing your submission.
Quick Reference
| Situation | Action |
|---|---|
| Found a vulnerability | Document independently first, always |
| Vendor has direct security contact | Go direct, propose your own terms |
| Vendor says "use our bug bounty" | Submit with explicit rejection of platform terms |
| Platform accepts submission silently | Your terms govern (you stated them, they didn't object) |
| Platform rejects citing their terms | Withdraw, pursue alternative disclosure |
| Submission marked Out of Scope | No agreement exists, publish freely |
| Vendor unresponsive for 7+ days | Send final notice, then alternative disclosure |
| Platform threatens disciplinary action | They have no authority you didn't grant them |
Final Note
Bug bounty platforms exist because vendors wanted to externalise the cost and liability of security research. Researchers accepted this because the platforms marketed themselves as the legitimate channel and because, frankly, getting paid through a platform is easier than negotiating directly.
But easier is not better. The platforms have built systems that serve vendors at researcher expense. The only leverage you have is the willingness to not participate on their terms.
Use them when useful. Reject their authority always. Your work is yours until you explicitly agree otherwise, and "clicking submit" is not explicit agreement when you've stated your own terms.