Your Developer Workforce is Larger Than You Think
Do you trust your developers?
The short answer is ‘yes.’ Developers in your company have gone through background checks, passed interviews, been onboarded and trained. These developers access key company resources and intellectual property.
Your developer workforce, however, is much larger than you think.
By using open source software, you expose yourself to the influence of thousands of developers whom you don’t know and should not necessarily trust.
Analyzing author behavior is critical to securing your software supply chain.
Today's Open Source Landscape
Given the scope and complexity of modern software, using open source software is something of a forgone conclusion. Building a modern application of any reasonable scale that meets modern user expectations is prohibitively expensive without utilizing these libraries. In any given project, nearly all of an organization’s software is open source code with only a small amount of code actually written by the company.
Within the open source ecosystem, the number of packages has grown exponentially. By extension, the number of transitive dependencies in each library has skyrocketed. For every package that a project imports, the number of packages that each package requires, and that each of those packages require and so on, has vastly increased. You might see a handful of dependencies for your main products, but there is now a hidden tail of thousands of additional libraries that are required to make those dependencies function properly.
Each open source package carries the influence of its authors. Tens of thousands of maintainers and contributors support open source packages. Maintainers and contributors are largely anonymous software developers from all over the globe and the authors of open source libraries. While the vast majority of maintainers and contributors are well-meaning, recent and historical events have shown that this is not always true.
Understanding Author Influence
Most open source packages live between two separate ecosystems: a package manager and a version control system service. A package manager is where pre-built deliverables are released for consumption. A version control system service, such as GitHub, GitLab, or BitBucket, is where ongoing development happens. (Note: there are also many cases, especially in more modern package managers such as Golang's, where the two ecosystems are effectively inseparable.)
In a version control system service, there is usually a small number of maintainers who effectively function as the gatekeepers for new commits. There is generally a much larger ecosystem of independent contributors who submit suggested changes in the form of pull or merge requests. The actual shape varies widely based on the size, maturity, and needs of a given open source project. Many smaller packages have only a single maintainer and commits from a handful of other authors. Other medium-sized projects may have a number of maintainers and dozens of contributors. Still other projects, like the Linux kernel, have many maintainers, each responsible for different parts of the project, and thousands of individual contributors.
Maintainers ultimately control the libraries, how they are developed, and what additional packages the project may depend on. When using an open source library, you implicitly trust the governance of that library's maintainers. You also place some trust in the contributors. Malicious contributors or even innocent contributors who inadvertently introduce bugs can be problematic.
We will briefly discuss some security model considerations for each author class along with some historical examples of governance issues.
Maintainers and Problems with Maintainership
Within the realm of open source contributions, package maintainers essentially hold the keys to the kingdom. They make high level governance decisions around what goes into libraries under their purview. Importantly, the code they maintain also impacts every package downstream. Even maintainers of small packages that sit near the edge of a dependency graph have disproportionate amounts of power. The logic they bundle into the libraries they maintain, including code for setup and installation, gets an opportunity to execute every time their package is installed.
Beyond the possibility of a new package author inherently being malicious, there are also problems around the transition of maintainership for packages. Unless a particular package has an organization backing it, maintaining a package is a relatively thankless job. As more projects depend on a published library downstream, more requests for features and bug fixes will percolate up to the package maintainer. Maintainers are ostensibly asked for some level of free support. They may eventually grow tired of maintaining a package and wish to transition ownership to someone else.
The process of transitioning ownership is not a formally defined one. In many cases, a package maintainer will simply open an issue to try to find a new owner to take over maintainership of one of his/her packages. This will invariably result in a new manager who is now able to influence everything downstream of the package. It isn't always a problem, but there have been cases where such an event has ended with malware.
Contributors and Security Risks
While they don't have direct control over a library, contributors are far more numerous. While a moderately large package may have a small handful of core maintainers, it will likely have dozens to hundreds of anonymous, unaffiliated contributors. These contributors provide help anything from feature additions to bug fixes. While most contributors are well-meaning, the only gating factor that prevents them from getting anything into a given package is how well the maintainers handle reviewing third party contributions. Even well-established projects with very strict governance guidelines like the Linux kernel have proven to fall victim to bad actors. There are even competitions around inserting innocuous-seeming code that serves a different purpose.
Further Considerations
Beyond the above security risks, there is an implicit trust that maintainers have strong security hygiene, employ best practices, and have not fallen victim to account compromises. Additionally, organizations effectively trust that there will be safe and secure maintainer transitions. By our accounting, a huge portion of the ecosystem has simply been abandoned in place. In these cases, not only will open feature requests go unanswered, but any issues discovered in a library will continue to be issues forever, including vulnerabilities or compromises in packages that sit upstream.
To date, author behavior has largely been overlooked in the software supply chain. Yet, maintainers and contributor yield significant power over the viability and security of every piece of software that sits downstream. Understanding and analyzing author behavior is a critical part of effectively securing your software supply chain.
