We’ve published a blog post that goes into detail about the way Bugcrowd prioritizes vulnerability submissions. Make sure to read this as it’s a great way to get an understanding of which bugs will pay out the most and increase your likelihood of acceptance.
The only way for a security team to effectively manage risk is vulnerability prioritization and management. There are many different prioritization models used across the industry that are based on vulnerability risk and impact. Without a clear prioritization model, how do you know what to fix first? Highest CVSS Score? FIFO? LIFO? Externally known issues? Whatever your prioritization plan is, it needs to be documented and updated as threats to your business change.
At Bugcrowd, all valid bugs are assigned a priority rating based on the severity of the security impact – higher severity issues that are rated as Critical such as SQLi resulting in remote code execution receive higher rewards than low severity issues. Note that this is our prioritization framework for web application vulnerabilities in managed programs, and may be modified by individual customers based on their business priorities and risk tolerance. Host Infrastructure, Mobile OS or Apps, IoT, and desktop application bounty programs are adjusted appropriately.
Read more on the Bugcrowd Blog
“@Kym_Possible why is direct object reference p3? Ive downloaded site backups exposing pii that way. Not a bugcrowd bounty.”
The truth is that no priority model is perfect. Heartbleed was a CVSS 5.0 but definitely had critical impact, if that had been treated like a moderate class vulnerability it still wouldn’t be patched (well okay so we know not everyone has patched it everywhere still, but we’re getting there). So Bugcrowd’s priority model - like most every other priority model - is simply a starting point for assessment that inevitably has edge cases. Fundamentally the answer to the question is found in another question: regardless of the vulnerability type, what is the impact of the vulnerability? (I like the STRIDE model for categorizing impact, your mileage may vary). Is it remotely exploitable? Is user interaction required? What is the value of the asset being compromised?
If you’ve found an IDOR vulnerability that discloses directory structure, that’s going to be a P3. But if you’re disclosing user names, that’s probably a P2, and if the information disclosure includes usernames and passwords, P1. When you report that direct object reference, be clear about the impact. This can be done in as few as two sentences at the start of your vulnerability report that make the impact incredibly clear:
> $VULNTYPE resulting in $IMPACT
> Attacker does X, User does Y (where Y may be ‘nothing’), Attacker now pwns Z
That makes it super clear to the person reading your vulnerability report exactly why they should care about this issue and what the impact is to their business. 
Thank you for the replies! I agree no structure is perfect. I have my own priority system and adjust it on impact as well. I was hoping that was the same with bugcrowd. Impact sure makes a difference. Yes, a lot of us start off going off the top ten, but there are so many more bugs then that. If anyone went to defcon or read about it, you’ll know the top ten doesn’t even cut through the surface of bugs. Of course, it has it’s place. I am on a off-topic rant. So, back to the priority system. I think it makes sense to have it as a default p3 after your reply. I mean, okay you can get the database structure. Can you use that information to exploit anything? No, but someone else may find something you didn’t and tie it together… so I guess that’s why it’s a p3 and not a p4. Thanks @kymberlee!
1 Like
Hey,
First off if you haven’t read the post about what ranks as a higher priority and how that converts to payment by Kymberlee on bugcrowd you should https://blog.bugcrowd.com/vulnerability-prioritization-at-bugcrowd/. I am making this post, because Twitter is limited in how much you can say, so @kymberlee suggested moving to the forum.
I noticed direct object reference(DOR) was put as priority 3. I understand that a lot of things that fall under DOR don’t always expose sensitive data, but the ones I go after do. I almost always get PII when I go after direct object reference, whether it be the entire database, a backup of the entire site with all the code the company tried to obscure along with PII, etc.
I’ll play devils advocate for a moment and use facebook public images as an example of an issue that was DOR and still is if you can guess or know the sequence of numbers used in the URL, but I see a public picture as p5. If you are able to DOR the private pictures, which I think you can then I see that as PII and p2 to p1. So, with all that said why is DOR p3?
hahaha I was writing a reply to your twitter question in the blogpost comment thread here on the forum when you posted this!
Truth is, IDOR isn’t what drives the priority, the IMPACT of the IDOR is what drives priority. Not all security teams and bug bounty hunters think in terms of impact as much as OWASP Top Ten though, so we try to come at this from both angles. We describe impact and list a few example bug types at each priority level, but realize that those bug types could have multiple impacts - IDOR could disclose a database structure or a file of user credentials - one is a P3 and the other is a P1.
My full comment is at https://forum.bugcrowd.com/t/vulnerability-prioritization-at-bugcrowd, I’ll let @samhouston figure out if the two threads should be compressed into one. 
