Skip to main content
Exploring what’s next in tech – Insights, information, and ideas for today’s IT and business leaders

How to keep up with open source updates

Odds are that some of your corporate software depends on open source software projects. When a vulnerability is announced and fixed in one of them, will you know? GitHub solves this problem.

Programming these days, especially open source programming, consists of using components to do standard things such as user interface or database interaction. You include these components, which almost always are open source, as part of the program you deliver to users.

Inevitably, researchers find security vulnerabilities in these components, and developers distribute fixed versions of them. It then becomes the duty of the application programmer to make a new application version incorporating the fix and distribute it. Many enterprise applications are vulnerable through such flaws. The details are often public, and attackers are on the hunt for vulnerable programs.

Even large software companies have to keep up with these issues: The most recent updates to iOS and macOS include an updated version of the libxslt library. (Libxslt is an XML-based language for transforming XML documents into other kinds of documents, such as HTML. Do any of your applications use it? Better check.) It’s natural to groan and resist doing this work, if only because it necessarily interrupts scheduled work and revives a project you thought complete. But it’s got to be done, and anything that makes the process easier is a good thing. A good example is GitHub’s recent announcement of a feature to automate new builds of projects when a security fix for a component in the project is released. It announced the new capability at the May 2019 GitHub Satellite conference in Berlin.

Few, if any, software development tools are as successful as Git, the version control system, and GitHub, the public repository for Git use. Git was created in 2005 by Linux creator Linus Torvalds and has become popular for developing documentation and other applications that require management of changes in sets of files. So ubiquitous and accepted is GitHub that, in 2018, Microsoft bought the company and stores thousands of open source projects in its company repository.

So how does this work?

Open your GitHub project and click the Security tab below the repository name. For the example below, I cloned a friend’s old project that's based on the Ruby programming language.

In the example above, GitHub found and listed security alerts for 45 vulnerabilities in code projects that my project depends on. It knows that my project depends on these other projects because of a GitHub feature called the dependency graph.

The dependency graph keeps track of code a project depends on. The feature supports only particular languages and file formats, but these are common ones like .csproj for .NET, pom.xml for Java, package.json for JavaScript, and requirements.txt for Python. GitHub enables the dependency graph by default in public projects, and administrators of private repositories can enable it if they so choose.

When the system is alerted to a vulnerability in an existing repository or the addition of a new dependency to code for which GitHub has already received a vulnerability alert, it sends a notification to all users with admin permissions. By default, the notification is by email. You can configure the system to send alerts to other users in organization-owned repositories.

At the same time, if Automatic Security Fixes are enabled, GitHub generates a pull request. A pull request is a proposed change to the repository, in this case to update the dependency to the later version in which the vulnerability has been remediated. The notification emails include a link to the pull request, along with the severity level and link(s) to the file(s) affected.

The image below shows pull requests generated automatically by GitHub to my test project.

This ability to generate pull requests automatically comes from Dependabot, a company acquired by GitHub in May 2019. Dependabot had been a for-pay service, but GitHub has made it free. And Dependabot is widely used; in late July 2019, GitHub announced that 1 million Dependabot pull requests had been merged.

GitHub gets its vulnerability information from a variety of internal and external sources. MITRE’s Common Vulnerabilities and Exposures (CVE) list is an old and authoritative source for data on disclosed vulnerabilities. WhiteSource is a company that produces tools for open source code management. GitHub also looks at advisories published by maintainers on GitHub itself. The last source is a "combination of machine learning and human review to detect vulnerabilities in public commits on GitHub.”

Source code scanners from companies such as Veracode and WhiteHat can detect vulnerabilities along with a long list of other software problems. There are also commercial services, including Synopsys, which look for vulnerable dependencies and other security issues. Best practices dictate that you revisit the security of the application periodically. With products and services like these, you can integrate source code analysis into your security lifecycle.

An organization with a security lifecycle in place and conscientious application of best practice will catch most or maybe all of these problems and address them expeditiously. But automatic notification is better still. Having a system as popular and well-resourced as GitHub looking for and notifying you of vulnerable dependencies is a valuable security asset.

Over 1M people read Enterprise.nxt. Are you one of them?

What else can I do?

In no way do the automated security updates from GitHub replace static source code analysis tools and outside security services. Those products and services perform many valuable inspections for vulnerabilities, other bugs, and inefficiencies. This new feature addresses one critical problem that commonly leads developers to allow old, known vulnerabilities to stay on the shelf past their expiration date.

Some interesting caveats: The pull requests generated by automated security fixes update the vulnerable component to the minimum version that resolves the vulnerability. In other words, there may be a more recent version, perhaps with feature updates, but GitHub will not pull it. Also, there may be no path through your code to execute the vulnerable code in the dependent component.

These issues undoubtedly affect smaller groups more than larger, well-resourced groups. But even large organizations have some quick-and-dirty projects that don’t go through a full, formal process. And the benefits of better security in smaller groups will redound to larger groups, as many of the open source tool kits used by everyone are created by smaller groups of people who don’t have access to enterprise-class software and likely have day jobs.

Along with the severity ranking, the vulnerability alert includes a compatibility score, which is a rough indication of how likely it is that merging the fix will cause problems in the build. It’s a really good idea to review this score and other details, like the release notes and changelog entries, before you pull the trigger and merge the fix.

Historically, GitHub has not been a standard facility for enterprises to store their programming projects. But the company has created enterprise versions of its software, both for cloud services and on premises. Large enterprises do run these GitHub versions, and it’s not surprising because so many programmers are taught to manage their code through GitHub. Enterprise programmers want their beloved and familiar tools. Microsoft’s purchase of GitHub also should give it enterprise credibility where it may have had none.

GitHub’s automatic notifications of security alerts, and its automatic creation of pull requests to get the mitigation process started, is a clear advance in the technology of secure programming practices. Look for it to be emulated in development tools and related environments.

Keeping open source projects updated: Lessons for leaders

  • Just because your open source-based project is finished doesn't mean you're done with it.
  • Automating update checks is part of good development hygiene.
  • Best practices may require multiple tools.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.