Securing software, together

Software powers virtually everything around us. There is software behind the things we build, the medicine we take, and even the food we eat. Every new breakthrough will be made with the help of software. It is increasingly a challenge to identify something that doesn’t use software today.

If software powers the world, open source is its beating heart. Today 99% of all software projects consume open source. That is simply incredible. It is a testament to the work that so many have given freely. Everyone that contributes to open source should be proud about how they have helped us all move forward.

With that success comes responsibility. Open source must be something that the world can trust. As open source creation and consumption continues to rise, this problem is becoming increasingly important—and increasingly challenging.

A new approach

Today the security lifecycle is broken:

• Identifying vulnerabilities is a manual, ad hoc process.
• Disclosures are often not made responsibly—if they’re made at all.
• Security vulnerabilities are fixed outside of normal open source workflows, without the support of critical tooling just to avoid premature disclosure.
• Developers don’t get security alerts for their projects that consume vulnerable software, or if they do, they may be overwhelmed by the number and complexity of issues to investigate; which can consist of both real and false-positives.
• Updating vulnerable dependencies takes too long or simply doesn’t happen at all.
• Nothing prevents the mistake that introduced a vulnerability from happening again.

As the home for most of the world’s open source, this is a problem that we at GitHub feel responsible for addressing. But we can’t do it alone. No one can do it alone. Software security is a collective problem, a responsibility that involves producers and consumers of code, open source maintainers, security researchers, and security teams. At GitHub, we want to give the community the tools it needs to secure the software we all depend on.

Ten years ago, GitHub introduced the pull request. For so many of us, it gave us a better way to work together. In the same way the pull request created a standard process for managing contributions, the ecosystem needs better-defined processes for managing vulnerabilities in open source code. This is what we’re setting out to build at GitHub.

The security advisory

A typical security vulnerability workflow involves researchers, maintainers, and developers.

1. Researchers identify vulnerabilities and disclose them to the maintainers.
2. Maintainers fix the issue and send an alert to the community.
3. Developers update to the fixed version and look to prevent a recurrence.

We believe this entire workflow needs to be as natural as pull requests are today. We’ve taken steps down that path already, and you’ll see us continue to take more.

Today in GitHub, a security advisory is the entity that tracks a vulnerability from the beginning to the end of this lifecycle. It connects the researcher that found the issue to the maintainer that fixed it and the developers that depend on it.

Security researchers

Security researchers play a critical role in keeping the world’s codebase safe by identifying and disclosing vulnerabilities. As software development has grown, however, the community of security researchers has not, and the ratio of security researchers to developers continues to drop.

It’s critical that these researchers can be as productive as possible. We are incredibly excited to have Semmle join GitHub.

Traditionally, vulnerabilities are discovered by penetration testing, or inspecting code by hand. Semmle scales the work of security researchers by treating code as data. Their code analysis engine—named QL—combines the latest research in compiler optimization with insights in database implementation. It understands the complex data structures inherent in code, and makes analysis available to researchers using a declarative, object-oriented query language.

Just as relational databases make it simple to ask very sophisticated questions about data, Semmle makes it much easier for researchers to identify security vulnerabilities in large code bases quickly. Many vulnerabilities have the same type of coding mistake as their root cause. With Semmle, you can find all variations of a mistake, eradicating a whole class of vulnerabilities. Furthermore, this approach makes Semmle far more effective, finding dramatically more issues and with far fewer false positives.

Security researchers identify vulnerabilities and their variants with a QL query. This query can be shared and run over many codebases, freeing up security researchers to do what they love and do best: hunt for new classes of vulnerability. Because QL is declarative and object-oriented, creating a new analysis is much easier than with traditional code analyzers. Customers frequently find vulnerabilities they couldn’t find with other tools and accomplish tasks that used to take weeks or more in hours.

An important measure of the success of Semmle’s approach is the number of vulnerabilities that have been identified and disclosed through their technology. Today, over 100 CVEs in open source projects have been found using Semmle, including high-profile projects like Apache Struts, Apple’s XNU, the Linux Kernel, Memcached, U-Boot, and VLC. No other code analysis tool has a similar success rate.

We are in the early stages of bringing the Semmle technology to GitHub users. Stay tuned!

After a researcher or developer finds a vulnerability, the next step is to coordinate disclosure with the project maintainer. Simply identifying the person, much less contacting them in a private manner, can be a challenge. Reporting a security vulnerability safely is something that anybody should be able to do for any OSS project. Security policies are a small first step toward helping folks do that on GitHub.

Once a vulnerability is reported for a project, the project’s maintainers can create a security advisory so the researcher, maintainer, and development team can privately coordinate on how best to address the vulnerability.

Maintainers

Maintainers are under incredible pressure. Not only do they have to try to make sure that every release they publish is secure, they also have the responsibility to fix vulnerabilities quickly when they are found. Making their challenge even harder, they often can’t even work on the fix using their normal tools for fear of accidentally disclosing the issue.

Within a security advisory, maintainers can create a private fork as a safe place to collaborate on a fix. In the future, we will make this private fork a fully functional environment in which to work, including private CI using Actions.

Once the maintainers have completed their fix, they will publish patched versions that address the vulnerability, and, critically, a security advisory. Making sure the community knows about vulnerabilities at the right time is one of the most valuable things we can do at GitHub. So often exploits happen using vulnerabilities that have fixes available but just haven’t been picked up by the larger community. Today, for an ever expanding set of languages, GitHub understands what dependencies that project has in the dependency graph.

This allows GitHub to alert all downstream users affected by the vulnerability, both within GitHub and via email—and we’re continuing to optimize the way we communicate these alerts.

GitHub currently issues alerts for advisories that were reported directly on GitHub, as well as vulnerabilities from other sources, such as the National Vulnerability Database, MITRE, and WhiteSource. GitHub hand curates every vulnerability to confirm the impact and affected users before we issue alerts, ensuring users are always getting actionable alerts.

GitHub is now a CVE Numbering Authority

We believe that fast, unfettered movement of vulnerability data is critical to improving software security. This is why we’re excited to share that GitHub has been approved as a CVE Numbering Authority for open source projects. We’ll be able to issue CVEs for security advisories opened on GitHub, allowing for even broader awareness across the industry.

Developers

Developers have the all-important job of keeping their projects secure. A huge part of this means keeping their dependencies updated.

We know that alerts aren’t enough. A significant percentage of critical vulnerabilities go unpatched for months—and the risk to an organization from unpatched vulnerabilities grows as the unpatched code is proliferated.

Updating dependencies needs to be as easy as possible. Earlier this year, we acquired Dependabot, and we now provide automatic security fixes natively within GitHub. With automatic security fixes, developers no longer need to manually patch their dependencies: when a vulnerability is found in a dependency, GitHub will automatically issue a pull request on downstream repositories with the information needed to accept the patch.

Developers also want to be able to prevent new vulnerabilities from occurring. In many ways, this is the hardest of the challenges we face. While this will be an area of continued innovation in the industry, there are a couple of things that we are doing now.

GitHub Token Scanning scans public code for secrets from more than 15 providers. GitHub works with providers like Azure and AWS to validate the secret is active and to notify secret owners to safely disable and remediate the exposure. This capability will soon include optional scanning of private code for our community.

Finally, Semmle QL benefits both developers and maintainers. It has a library of thousands of queries, all open source, that have been defined by some of the industry’s best security researchers. These queries can be used to detect vulnerabilities as part of your pull request workflows to prevent vulnerabilities before they are ever released.

Security teams

Developers are busy folk, and we know sometimes things like security vulnerabilities can slip through the cracks. In enterprises, this can expose customers to vulnerabilities, so we provide security, compliance, and open source offices a turnkey way to audit your organization’s open source dependencies for security vulnerabilities with dependency insights.

A safer future for all of us

While the largest open source communities are backed by organizations that have security researchers, the vast majority of projects simply don’t have the tools, expertise, or resources to investigate, address, and propagate security issues.

This is a problem we are committed to help fix. At GitHub, our mission is to build the global platform for developer collaboration—one that all of us can use to secure the world’s software, together.

Written by

Shanku Niyogi

@shankuniyogi