GitLab's Brian Neel on Secure Software Development and Bug Bounties

Did you miss our webinar with GitLab, Innovating Faster Without Sacrificing Security or Quality? It is jam packed with insights into how they partner with HackerOne to make their products more secure. The crux of the webinar, however, had their security lead diving deep into why the “typical” security process leaves a multitude of gaps, and how their bug bounty program helped to provide a necessary layer that is both efficient and cost-effective.

Watch the webinar replay here, or read on for more details.

At GitLab, one of their goals is to innovate faster without sacrificing security. That means bringing security into the development process earlier and more often, which impacts the entire software development lifecycle, helps developers think about security as they’re writing the code, and making code reviews a collaborative process that starts when development starts.

This approach helps developers find bugs earlier, but also ensures the right security experts are reviewing code before it’s merged. And, it encourages conversations to happen earlier and more often.

So where do hackers and bug bounties come into their process? To explain, Brian Neel, GitLab’s security lead, looked at how the software security apparatus has grown over time, and how hacker-powered security has become a critical component.

In a typical development process, as Brian explained, engineers are developing versions to be released periodically. Years ago, as security vulnerabilities started to be found more often, companies implemented internal security audits before a version release. The audits remain similar today, and are one-time events and relatively simplistic.

As security became more of an issue, security teams ran periodic vulnerability scans, which resulted in a list of vulnerabilities that may or may not be valid. Penetration tests then appeared, which brought in expensive consultants maybe once per year (or less) to look for security issues. 

As more of the same types of security issues were found again and again, teams looked to train developers in techniques that avoided those issues. But taking developers away from coding was expensive, so it happened infrequently, for only a day or two, and was executed at a high level. That combined to leave much distance between what the developers were working on and what was taught in the trainings.

Static analysis tools then became popular to cover a few specific areas. Again, these tools were used right before a release and usually resulted in many false positive reports, which required time to evaluate and dispose of. However, a static analysis could be run much more frequently than the previous methods, and could even be incorporated into continuous development cycles. But with more frequent analyses came more false positives, which delayed releases. Security teams combated this by “tuning down the analyses to find only the most egregious vulnerabilities.” That then left plenty of smaller and mid-level vulnerabilities to go unreported.

Dynamic analysis (web application scanners, database scanners, etc.) tools then appeared, and became another checkbox before a release. The results were limited, and required a lot of research to determine their origination and impact. It was another tool that filled some gaps but still left many, many open.

Test-driven development then appeared to give developers more control over what was analyzed and what the test should look for. The challenge with that came when code was changed, which frequently involved other developers who might not know some of the nuances of potential vulnerabilities. 

Even with all of those tests and tools and techniques, as Brian shows in the slide above, many gaps still remained in the typical development process. That’s where bug bounties come into play for GitLab. They see bounties as providing “endless coverage” across the entire development lifecycle for any new or existing vulnerabilities, as seen in the slide below.

With a bounty program, “you’re constantly going to have professional hackers out there testing this code against new types of vulnerabilities,” Brian said.

Brian went on to showcase a couple of examples—one critical, one less so—where vulnerabilities reported to GitLab through HackerOne specifically fell through the gaps of their “typical” security efforts. Without a bug bounty program, they wouldn’t have found either, and that underscores their reliance on their bug bounty program to find vulnerabilities they never would have found otherwise.

Watch the full GitLab webinar replay here and see the slides here.

Want to compare HackerOne's platform with your existing security solutions? Start a 4-week Challenge today!

https://www.hackerone.com/zerodaily/2017-07-07