GitHub Seeks Security Dominance With Developers

Source:-forbes.com

GitHub has decided to make a play for being a one-stop-shop for all things code security with a series of announcements made at its annual GitHub Universe conference.

GitHub has mapped what it believes is a generally useful workflow for how various people involved in security—developers, security researchers, supply-chain partners, vulnerability database providers, etc.—work together to write and maintain secure code. It has then built features and tools, and in some cases acquiring companies, to match these user needs with platform functions all centred on GitHub.

Particular attention has been paid to the open source ecosystem that underpins so much of modern software. Rather than taking a point-by-point approach, GitHub is taking a more holistic view, where substantial individual features or tools nonetheless fit into a broader story about how security is managed.

“It’s an ecosystem level issue that spans from open source developer to open source maintainer to security researcher to developer in a company who’s using open source to the security team at a company,” said GitHub CEO Nat Friedman. “There’s very few players in the ecosystem that can pull all that together and solve that problem.”

To bring all these different players together on its products, GitHub has announced a raft of security-focused offerings.

Security Lab is GitHub’s collaborative centrepiece. It aims to provide a meeting ground for security researchers, software maintainers, and partner companies, and has a focus on open source software. Since so much open source software is hosted on GitHub these days, it’s a logical thing for GitHub to do.

CodeQL, obtained from its acquisition of Semmle in September 2019, is being provided free-of-charge to open source developers and academic researchers. The goal is to build up a library of CodeQL queries that can detect security flaws in an automated fashion, and GitHub has created financial incentives under a bug bounty program with two main payout classes: individual bugs and broader, cross-ecosystem bug types.

GitHub has added a way to work on bug fixes in private (so as not to tip off bad actors too early) with its Security Advisories, which includes a streamlined workflow for applying for a Common Vulnerability and Exposures (CVE) number. Security alerts for known vulnerabilities are also now generally available to repos that want them, and it includes automated pull-requests to fix bugs (where that’s possible) using Dependabot, another acquisition GitHub made earlier this year.

The process of triaging security issues and merging pull requests has also been made easier with a new mobile app for both iOS and Android that is designed to provide a similar experience to that of GitHub Desktop or in a browser, but optimised for the mobile form-factor. While few people will write code on their phones or tablets, many people involved in the software development can manage tasks, comment on code, and operate the main branch-and-merge process without needing a heavyweight client. GitHub has spent considerable effort making the experience feel similar no matter which access method you use.

There are a lot of different components here, some bigger than others, but taken together they’re designed to work as a cohesive whole. Small changes, such as how notifications are presented and CVE requests, support the bigger functions such as CodeQL and vulnerability disclosure. Each component works in harmony with the others so that the whole becomes more than the sum of its parts.

“We’re acutely aware that securing software needs researchers working with maintainers and then working with developers as well as the end users, all together,” said Grey Baker, Director Product Management, Security at GitHub. “We’re trying to create at least the tooling to make that possible.”

The overall consistency of experience reduces the friction of working in a particular way, to the point that it becomes almost unconscious. The tools tend to disappear while you concentrate on the work and the objectives, and this is clearly GitHub’s intent.

While GitHub likes to stress that it wants to provide developers with choice, it clearly wants to make the integrated experience so compelling that developers don’t choose to work anywhere but on GitHub. Extending this experience to the information security domain brings in a wealth of new customers whose participation is sorely needed if we are to have more secure software.

It would be unwise to paint all this as some kind of altruistic plan on GitHub’s part, ensuring a healthy and flourishing ecosystem serves GitHub’s ends well. If GitHub becomes the de facto standard way to manage security maintenance of open source code, those processes will also become the de facto standard way to manage the security of proprietary code, just as feature branches and pull requests have become the main known-good way to write code.

GitHub, so far, is setting the standard by which other methods will be measured. This is ultimately good for customers, provided that GitHub’s competitors are able to provide a similarly compelling vision that isn’t completely incompatible and forces developers to disappear behind the walls of one walled garden or another.

In speaking with other security vendors and researchers since the conference, all were generally supportive of GitHub’s moves here. While they were keen to explain that other offerings (particularly their own) did more, or were more powerful in various ways, no one thought GitHub’s actions here were making things worse. In the sometimes fractious world of information security, this is an encouraging sign that perhaps collaboratively fixing system security is an idea whose time has come.