The Application Security (AppSec) team at GitLab works closely with engineering and product teams to ensure the security of our products. There’s another group we also work with regularly to secure our product -- the amazing hackers who submit reports to us via our bug bounty program. These talented individuals from around the world research and identify security vulnerabilities in GitLab and submit bug reports detailing their findings. GitLab’s AppSec team verifies and triages the findings and the reporters are rewarded a bounty for making our product stronger.
Beyond the cold hard cash, we’re continually looking for ways to recognize and further engage the deep talent and expertise of the security researchers that contribute to our program. We’ve started a new blog series, “Ask a Hacker” and just featured @ajxchapman in this latest blog post. We’ve also kicked off a series of public Ask Me Anything (AMA) sessions with hackers who contribute to our program and we’ve got one coming up with Alex Chapman on March 22 at 15:30 UTC (see the world clock) and we hope you’ll join us!
Get all of the details in this Google Form, including how to get an invite.
Achieving consistent severity and bounty assessments through collaboration
We strive to be open about as many things as possible and one of GitLab’s core values is transparency. In bug bounty programs, we know there can be confusion around how severity levels and specific bounty awards are determined for a given report. So, we want to provide some insight into the GitLab Bug Bounty Council process and how we use it to ensure collaboration and consistency across our severity and bounty assessments.
The mechanics of the council
We try to dogfood as much as possible, so our Bug Bounty Council process relies heavily on the use of an issue tracker specifically set up for the AppSec team. Every week, a bot creates a new Bug Bounty Council issue, which serves as the source of truth for discussions and decisions made about any verified vulnerabilities that came in through HackerOne that week. Asynchronous communication is critical for bounty discussions since our AppSec team is distributed around the world. As of writing this post, we have team members spread across multiple time zones in 10 different countries.
When a HackerOne report gets triaged, an issue comment thread is created on the current week’s Bug Bounty Council issue. This comment thread is where any discussion about a specific report and/or bounty will happen and typically includes:
- Link to the HackerOne report
- Brief description of the finding
- A recommendation for the bounty amount
- References to similar issues and bounty amounts that were paid, if available
- The CVSSv3 vector string for the vulnerability
The team member triaging the report can add any additional information, discussion items, or questions that they may have for the broader team, and the weekly council has become a great place for our AppSec engineers to solicit feedback from team members about the findings themselves. Other members of the AppSec team are then encouraged to share their feedback about the severity, consistency with other similar reports, or bounty amount. In the case of bounty amounts, this number is ultimately determined once a particular suggestion has received at least two thumbs-up emoji (👍) from other AppSec team members.
Applying iteration to improve efficiency and accuracy
We’re always looking for ways to embrace iteration and improve our processes. Recently our amazing security automation team configured things so that triaged reports are automatically added to the Bug Bounty Council issues, which saves our triagers time and ensures that every report gets discussed.
Another iteration implemented in the past few months is the addition of a requirement that each vulnerability get an approval on the CVSSv3 vector string in addition to the bounty amount. CVSS scores attempt to describe the characteristics of a vulnerability and include a numerical score that represents the severity. Each proposed CVSSv3 score is up for discussion and requires at least two bug emoji (🐛) from other AppSec team members. The goal here is to make our CVSSv3 vector strings as accurate as possible before a CVE is requested through GitLab’s CVE Numbering Authority.
Iterating towards increased transparency
The Bug Bounty Council is an internal process meant to increase collaboration on the decision making involved in severity and bounty determinations. And, through this function-wide collaboration and documented discussion, we can already see improvements in consistency across level-setting. Naturally, transparency around this process can be improved and that’s what we’re aiming to do. We’re exploring ways to further utilize CVSS in our process as well as incorporating a CVSS calculator around both severity and bounty determinations, bringing a whole new level of transparency to this process. We’re really looking forward to when we can implement and announce these changes and know it will be a welcome iteration by the bug bounty reporter community.
New features released, 22nd of each and every month
Our bug bounty program is open (public since December 2018) and anyone can participate. If you’re interested in collaborating with us to make our platform more secure please feel free to submit a bug bounty report to us! This feels like a great time to remind first-time and veteran reporters, too, that we release new features on the 22nd of every month. You can learn more about our release process, see the latest monthly release blog post and see what's coming in future releases. Interested bug hunters may just find something new that piques their interest.😜
