Developers don’t agree on much, but they sure do love GitHub. It is their first stop when looking for a bit of code to solve a problem and a great place to collaborate with other developers on public repos, improving the code for all to use.
As the amount of open source code hosted on GitHub has expanded significantly in recent years and open source vulnerabilities are on the rise, the issue of how GitHub manages security for their 31 million developer users has become more of a concern.
In hopes of making their platform a better, and safer place to work, the good folks over at GitHub Security have been putting in overtime to add new features which were announced at this year’s GitHub Universe conference in October.
GitHub’s vulnerability scanner has been providing alerts for JavaScrip and Ruby for over a year now, with Python being included more recently over the summer, but in what appears to be a nod to their enterprise users the crew over at GitHub Security has added alerts for the Java and .Net.
This feature looks to solve the serious problem of a lack of visibility that developers and security teams have inside of their projects’ dependencies. It is easy to lose track of which components are built on top of others, so when one library in a dependency is discovered to be vulnerable, it is unlikely that a developer will become aware that they are using a risky component unless it is specifically flagged for them.
According to GitHub’s own data, 75% of projects on their platform have dependencies, which can hide some pretty pernicious vulnerabilities that can impact the security of their code, making tracking them manually near impossible and an important concern to be addressed.
The good folks at the GitHub security team make this information easily available on their platform where developers manage their repositories. They lay out the basics about the vulnerability, including the description provided to them by MITRE’s CVE index, its CVSS rating (Low, Medium, High, Critical), and a suggested fix.
NVD is currently their primary source of vulnerability data, they have indicated that they are attempting to widen their net to include other resources as their dataset grows, using machine learning and human review to include vulnerabilities that are not on the NVD.
Users of public repositories do not need to take any additional actions in order to receive the alerts. For those out there using private repos, they will need to enable the Dependency graph either by allowing access in their repository’s Insights tab or by giving permission in the repository settings.
One important point to remember is that in order for the Dependency graph to work, the project’s dependencies in the repository need to be defined in a supported file format using a supported language.
Image Credit: GitHub.com
Perhaps an extension of their vulnerability scanner feature, this API takes the valuable data that GitHub security has aggregated and makes it even easier for development and security teams to use within their own environments.
What the GitHub security team has given us the option to fetch the data with their API, which will be super useful for those developers who depend on external programs for working on their code.
GitHub says that they want to make their vulnerability data available for developers on the tools and platforms that they are already using.
Finally, a feature that far too many developers can probably relate to. Take a second to search for third-party service tokens in GitHub search bar that some poor developer left exposed for the taking. I’ll wait.
It happens more than we would like to admit, but plenty of developers will drop the token for a third-party service that they are using for their product in an easily searchable public repository, and forget to delete it after they have already moved it on to their config file.
So what GitHub has done is created a process that searches for known token formats and will verify with the service provider if they think that they have dug up a valid token. If it is, then the third-party will reach out to the developer to issue a new token which has not yet been compromised.
In our opinion, this is actually a pretty smart way to cut down on the amount of communication and verifications that needs to occur in order to ensure security, eliminating those which are not active and therefore do not require action.
While this feature is still listed as being in beta and only covers tokens from six providers (AWS, Azure, GitHub, Google Cloud, Slack, and Stripe), it will likely come in handy for plenty of forgetful developers out there.
At the core of GitHub’s approach to these security features is a reliance on automation, seeking to limit the amount of time developers need to invest in order to work securely. Given the scale of dependency trees and the total amount of work that developers need to contend with just to meet deadlines, they are unlikely to have the time to sift through their dependencies manually. Even the task of implementing a fix after a vulnerability has been flagged can be a daunting task as they need to seek it out to understand where and how they are using a specific vulnerable component.
The GitHub security team’s approach to dealing with the exposed tokens is well thought out and downright respectful of everyone’s time, verifying that it is still, in fact, a valid token before setting the gears in motion for a developer to have to reset the token for their product. Kudos and let us hope that they continue to come out with more fantastic innovations like this.
GitHub’s efforts are representative of a shift across the broader open source security space that utilizes automation resolve issues that can cause big problems down the line if they are not addressed. Public organizations like OWASP have come out with their own dependency checker, while companies in the Software Composition Analysis space have also released new products to provide greater visibility into what is hidden within dependencies.
Open source components have grown in popularity because they save developers time and let them focus on the more intricate parts of their product that are frankly more in need of their attention. From this perspective, the GitHub security team needs to work from the same point of view, making the vast majority of security concerns and tasks easily manageable or even unnecessary if possible.