Executive Summary

The modern software supply chain relies pervasively on open source software (“OSS”) for both underlying components and operation. The ability for organizations (including companies and governments) to innovate faster, and at a higher level of quality, is often linked to their adoption of OSS components. Roughly 70-90% of any software “stack” consists of OSS¹². That shared benefit also comes with shared risk in the form of exposure to vulnerabilities in those OSS components.

Vulnerabilities and weaknesses in widely deployed software present systemic threats to the security and stability of modern society as government services, infrastructure providers, nonprofits and the vast majority of private businesses rely on software in order to function.

The software supply chain is complex and as susceptible to disruption and corruption as any physical supply chain. While the private sector constantly invests in protecting the software supply chain via standards, shared services, and solutions to reduce risk of both inadvertent errors and intentional attacks, just as with physical infrastructure (ports, power grids, telecommunications networks, etc) the public sector can and should play a role in hardening the systems. The public and private sectors must work together to meet the collective security and safety needs of citizens and stakeholders, facing even greater challenges in addressing these threats.

While there are considerable ongoing efforts to secure the OSS supply chain, to achieve acceptable levels of resilience and risk, a more comprehensive series of investments to shift security from a largely reactive exercise to a proactive approach is required. Our objective is to evolve the systems and processes used to ensure a higher degree of security assurance and trust in the OSS supply chain.

This paper suggests a comprehensive portfolio of 10 initiatives which can start immediately to address three fundamental goals for hardening the software supply chain. Vulnerabilities and weaknesses in widely deployed software present systemic threats to the security and stability of modern society as government services, infrastructure providers, nonprofits and the vast majority of private businesses rely on software in order to function.

With OSS we have the ability to directly and systematically mitigate the risks associated with OSS use that we do not have with proprietary software. This is due to the availability of the underlying source code, the way most development teams do their work in the open, and the significant amount of cross-project reuse of components and concepts.

Smart investments into systematic enhancements in the way OSS is developed, recombined, distributed, and deployed, as well as into specific highly re-used “critical” pieces, would be a highly leveraged and cost-effective way to reduce the risk for all downstream users. This includes the many proprietary and custom software solutions that incorporate OSS.

All software should be assumed to have defects, and all software development teams will at one point or another inadvertently allow a defect into their code, despite best efforts. Working with the teams managing open source projects is critical to the success of any of the above objectives. The managers of OSS projects are typically called “maintainers”; they actively manage the roadmap and release cadence of an open source project, as opposed to the broader category of “contributors”. Maintainers are also the first line of defense in holding off any malicious attempts to insert bad code into projects, or to protect against changes in other OSS projects that are implicitly or explicitly included in their software that may harm their users.

Thus, all forms of investment and intervention should be focused on delivering new value to OSS maintainers — from making it easier to adopt practices that enhance the security and integrity of their work, to funding activities like third party code reviews that most projects struggle to afford to perform on their own. Any investments or policies that place additional burdens on developers, increase their personal or professional liability for working on code, or issue unfunded mandates upon them, would struggle for adoption and potentially inhibit further advancements in open source software. Any successful approach must be collaborative, offering not only guidance but also education, support, and technical resources. This will be crucial in striking the balance between creating a strong impetus for change and winning the trust of OSS communities to drive adoption.

Companies who make extensive use of OSS long ago realized it was in their best interest to know what OSS was coming in through their supply chain. Initially this was for legal and software license compliance, but now increasingly is for tracking of vulnerable software assets. Those companies have tended to also create Open Source Program Offices (OSPOs) to systematically manage their engagement with the OSS projects they consume, as well as to follow professional and technical standards for the OSS code they upstream or release themselves. Those companies tend to put an emphasis on security best practices, train their employees on how to develop secure software, fund security audits for the OSS they rely upon, and invest in tooling to spot issues or projects of concern before they become an issue.

It’s time we apply these software security best practices to the whole of the software ecosystem, and the OSS ecosystem is the critical place to start because of the shared dependency most organizations in the world have on the same commonly-used OSS components.