Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
As more developers draw from existing code libraries to build new tools, tracking changes in dependencies like security vulnerabilities has become more difficult. Since the launch of security alerts last…
As more developers draw from existing code libraries to build new tools, tracking changes in dependencies like security vulnerabilities has become more difficult. Since the launch of security alerts last year, we’ve taken an active role in alerting project maintainers of known-vulnerable libraries in RubyGems for Ruby and npm for Javascript. In almost all cases, there’s a new, patched version of the library we can recommend in the alert. Here’s a summary of how security alerts have been used to protect your code so far.
In the security community, there are standardized and shared lists of vulnerabilities. The most comprehensive of these is Common Vulnerabilities and Exposures (CVEs). The security community works together to document vulnerabilities consistently and shares them in this list. GitHub’s security alerts notify you when Ruby and Javascript library vulnerabilities from the list are detected in your repositories.
Initially, we took our list of vulnerable libraries and compared it to the dependency graphs of all public repositories. We found over four million vulnerabilities in over 500,000 repositories and displayed an alert to repository admins in their dependency graphs and repository home pages (for Ruby and Javascript).
By December 1 and shortly after we launched, over 450,000 identified vulnerabilities were resolved by repository owners either removing the dependency or changing to a secure version. Since then, our rate of vulnerabilities resolved in the first seven days of detection has been about 30 percent. Additionally, 15 percent of alerts are dismissed within seven days—that means nearly half of all alerts are responded to within a week. Of the remaining alerts that are unaddressed or unresolved, the majority belong to repositories that have not had a contribution in the last 90 days.
In other words, for almost all repositories with recent contributions, we see maintainers patching vulnerabilities in fewer than seven days. With the recent launch of our regular vulnerability digest emails, we’re working to make this even easier for maintainers and security teams.
Security alerts are opening the door to new ways we can improve code checking and generation by combining publicly available data with GitHub’s unique data set. And this is just the beginning—we’ve got more ways to help you keep code safer on the way!
