Open source is all about community. While that’s usually a good thing, it’s a fact that some members of the community are jerks. No, I’m not referring to the sometimes unwelcoming nature of different communities. Instead, I’m referring to the interlopers who have hijacked different projects in so-called “supply chain” attacks like the Webmin and RubyGems exploits.
Given how increasingly interdependent open source projects have become, the potential to take advantage of this (for good and ill) has risen considerably. What can developers do to keep the world safe for the open source community?
SEE: How to build a successful developer career (free PDF)
We’re all in this together
Open source has never been an American thing. While North American developers have long played an important part in fostering open source development, many of the most prominent projects came from abroad, particularly Europe (think MySQL, Linux, etc.). This isn’t particularly surprising, given a European penchant for community mindedness.
While developers living in the US remain the single largest group of contributors, since 2014 the number of open source contributions originating outside the US has ballooned, according to GitHub’s State of the Octoverse 2019 report. Today, of the 40 million accounts on GitHub (many of which may not reflect active or even actual developers), 80% come from outside the US.
Where, in particular? Well, China, of course. Developers in China contributed dramatically more than any other country (except the US), and that activity is accelerating: Developers in China forked and cloned 48% more projects than last year, according to the same report. Even so, that’s not nearly as fast as the growth in Nigeria (59%), which tops all others in the category of growth in open source projects created in public repositories. Second place in growth? Iran.
SEE: Python bests Java for number 2 spot on GitHub’s list of most popular languages (TechRepublic)
GitHub has taken a principled stance on keeping access open to developers who happen to live on US block lists. As GitHub COO Erica Brescia told the audience at the Open Source Summit Europe, “We believe that access to GitHub and the global open-source community is not only important for continued software development but also the free flow of information with developers around the world.” In addition, she declared, “It’s our duty as a group to build bridges with developers around the world.”
It’s a good look from a company that necessarily must stand above political or national divides. The real question, however, is how much we can trust the developers on the other side of the pull request.
It’s dependencies all the way down
No, I don’t mean that developers from this or that country can be trusted more (or less) than a developer from another country–honesty and integrity don’t come with a particular passport. Rather, I’m referring to just how profoundly interconnected our open source world has become at the code level.
Across the top 1,000 GitHub repositories, Brescia said at OSSeu, 74,403 developers, on average, participate in writing and maintaining them. Those developers, in turn, write code that depends on lots of other code within the open source ecosystem. For example, according to the GitHub report, the 50 open source projects with the most dependent projects each had an average of 3.6M+ dependents. Projects like rails, jest, and axios are used by millions of other repositories. Those are the extremes, but even a run-of-the-mill open source project will have an average of 180 package dependencies.
SEE: Checklist: Security Risk Assessment (TechRepublic Premium)
It’s generally not the case that bad-faith developers are submitting pull requests to introduce backdoors and other vulnerabilities into code. One of the great things about open source is that it tends to depend on developers earning the right to commit code through consistent, valuable contributions. The idea of some rogue developer doing “drive-by” contribution hits is mostly farce. (And when, as with the RubyGems exploit that saw developer Matt Manning’s account credentials breached, a fix was quick to surface.)
No, as with Webadmin, or with the RubyGems exploit, hackers seem to be exploiting build servers or nabbing account credentials, or a variety of other approaches. Multifactor authentication (which is increasingly common) will help, as will mandating code signing. And, given that much of the world’s software is hosted on GitHub, we’re likely to see more baked-in security from GitHub, starting with its recent acquisition of Semmle. At the time of its acquisition, GitHub CEO Nat Friedman wrote:
Security researchers use Semmle to quickly find vulnerabilities in code with simple declarative queries. These teams then share their queries with the Semmle community to improve the safety of code in other codebases. Software security is a community effort; no single company can find every vulnerability or secure the open source supply chain behind everyone’s code. Semmle’s community-driven approach to identifying and preventing security vulnerabilities is the very best way forward.
With GitHub Universe this week in San Francisco, I suspect we’ll hear more announcements related to supply chain security, perhaps emerging from the Semmle acquisition. Regardless, in our increasingly interdependent open source world, the white hat hackers need better tools to combat black hat crackers.
Disclosure: I work for AWS but nothing written herein either directly or indirectly relates to my employment there.