At GitLab, our Security Team has two top-level missions that all of our goals must map to:
- Secure the product and service.
- Protect the company.
We understand that source code is often the crown jewel of any organization. This is true of the open core code that powers GitLab itself, so we are constantly applying our value of results and iteration to the benefit of all GitLab users.
There are a few basic truths about security:
- Security is about people, process, and technology. Understanding how to optimally balance those pillars is crucial to an effective strategy and strong security posture.
- Security cannot block business process and the ability to get work done.
- Security is never 100 percent, and a multi-layer approach must be taken to reduce risk.
Proactive and reactive security measures
It makes sense to think about security in terms of proactive and reactive measures, as both are required to truly implement defense-in-depth security. When it comes to application security, proactive measures include conducting internal application security reviews and educating developers on secure coding best practices. However, the ratio of developers to application security engineers is high, so the feasibility for organizations to review every single line of code manually is decreasing. Code scanning measures introduce automation in reviewing, but could also miss findings.
Enter reactive measures, such as internal red teams and public bug bounty programs. These come in after the fact – after the source code is written and committed – and provide another, necessary layer of security to our environment.
Since launching GitLab’s public bug bounty program in December 2018, we’ve resolved 95 security findings, awarded more than $300,000 in bounties and rewarded over 35 hackers for those findings. The overarching goal of our bug bounty program is to make our products and services more secure, and we’re proud of the early success we’ve seen to date.
How are we measuring success?
We’re looking at several key metrics and focus areas to determine what’s working and what needs to improve. In fact, our next blog post will dive into some of our early lessons learned, and the process and program improvements we’ve made to ensure we’re meeting our goal.
Quantity of new report submissions
We look at the total number of reports received and the average of new reports created each month to help us ensure we’re moving in the right direction in terms of incentivization and engagement amongst our HackerOne reporters. In just the first three months after making our bug bounty program public, we received 266 new reports. That’s an average of 88.6 reports per month. Of those reported, 76 were triaged as valid and 89 were resolved. We classify triaged reports as those for which we’ve assessed a potential user impact, and resolved reports are those we’ve investigated and resolved.
Repeat reporters
When we have reporters who continue to submit findings to our program, that’s another signal that we are on the right track in terms of incentivizing and supporting their efforts so that they keep coming back. Out of a total of 247 reporters from the past year, 38 percent have submitted more than one, 13 percent more than five, and 6 percent more than 10 reports.
Check out the top five GitLab reporters (by bounty):
- ngalog
- jobert
- nyangawa
- fransrosen
- xanbanx
Transparency
The majority of reporters want to make their vulnerability reports public to showcase their findings and techniques and, also, just for some good ol’ fashioned bragging rights within the hacker community. There’s also a real need in this community to be constantly challenged and a dedication to learning that public disclosure helps to satisfy. Many other bug bounty programs don’t publicly release the full details of their vulnerability reports and subsequently discourage the HackerOne community from sharing or showing off their findings. However, as one of GitLab's values is transparency, we set all vulnerability details to public in our issue tracker 30 days after a patch has been released.
Responsiveness
The HackerOne community expects responsiveness in the communication of updates and payment of bounties. To help ensure we respond and triage as quickly as possible, we’ve built in automation so that we can provide timely initial and ongoing feedback to reporters, as well as continuous updates on the ETA of fixes for existing reports. We’re working in the area of bounties payment to improve our process and reward bounties immediately after triage, where applicable, rather than when fixed. Expect to hear more on this in forthcoming bug bounty blog posts!
Competitive rewards
Our desire is to be the number one paying bounty company in our industry. This aim is to keep reporters incentivized, motivated, and engaged to find bugs on our platform. Our public bug bounty program is as important to the security of our product and company as any other program we run within our Security Team here at GitLab. That's why we’re continually looking to improve our processes and incentive structure to benefit our reporter community.
We know a big, fat check speaks volumes, but we also know some cool swag is a nice little pat on the back too. So, we’re putting it out there – if you could put a GitLab Tanuki on any piece of swag – what would it be? Leave us a comment below!
