| ▲ | cdbdbspt 2 hours ago | |
I also used to work at Google and what you have described is not the way the VRP works at all. 1. The engineers on the VRP teams set the severity of the bug based on impact. The engineering team responsible for the fix can argue the severity but only if they can show there is some other mitigating factor that the VRP team wasn't aware of. 2. Google has a great security culture and while it may be true that maintaining existing code may not be as sexy as building new features, fixing vulnerabilities does look good on GRAD (performance) because the impact is already well documented. 3. Believe it or not, the VRP team does like to give away rewards. However, to do this, they have to follow a rubric to keep all of the payouts consistent and fair. 4. Constructive and polite discourse is welcome and a researcher may reply to their bug asking for more details or to make their case in the event that they think the VRP team did not understand the severity. The team is made up of humans who are open to the idea that they missed something in the initial report. They, like all other bug bounty programs, are also struggling to keep up with the huge influx of AI generated slop so mistakes can happen. | ||
| ▲ | jonahx 2 hours ago | parent [-] | |
My first thought when reading the article was: "The generous interpretation here is that whoever is fielding reports gets so many false positives that they miss true positives (like this report), especially if there's any gray area." I'm not saying that excuses it, but it is one likely explanation for how it happened. When looking at just one report, the response seems negligent. When looking at a pile of 1000 nonsense reports, with a handful like this, I understand the difficulty. | ||