May 3, 2022
Buying down risk: Open source software
Open source software (OSS) is software granted under licenses that allow others to use and modify it under limited conditions—the “source (code)” is “open” to public viewing and modification. Some of the most common software systems in use today are open source: the Linux operating system, Apache Web Server, and many other critical libraries and packages. Most software, proprietary or not, relies on OSS in some way. The open source ecosystem benefits software development itself, providing packages, libraries, and tools for widespread use while allowing interaction with a greater number of developers than any single entity could provide, all spurring innovation and development speed. Any final product might contain dozens or hundreds of open source packages—one 2018 report found that 96 percent of applications in sampled commercial codebases had open source components. Researchers estimate developers downloaded over 2.2 trillion open source packages from the top four open source communities alone in 2021.
Project maintenance
Open source projects are not simply text files of freely editable source code floating around the internet. Rather, a specific developer, team, or organization maintains them. Others can come along, copy that code, and make changes, but the maintainers review the submissions and decide whether to integrate them into the code (often called a pull request). Alternatively, the contributor can host their own branch of the original code independently, preserving the identities of the original maintainers while still allowing the code itself to evolve and spread. Version control, changelogs, and ownership rules are crucial to the open source ecosystem, and many hosting services allow developers can upload projects for others to use, edit, make pull requests, perform independent reviews, and more. Popular open source repositories and hosting services include Github, GitLab, BitBucket, and PyPI.
Open source security
Owing to the structure of open source software, version control, ownership, repository management, dependency tracking, and even naming conventions impact the ecosystem’s security deeply. In a worrisome trend, reports indicate that 29 percent of the most popular open source projects contain at least one known security vulnerability. The Cyber Statecraft Initiative’s Breaking Trust dataset recorded forty-two supply chain attacks or vulnerability disclosures involving open source projects and repositories from 2010 to 2021. That is not to say that open source software is inherently less secure than proprietary—proprietary code’s significant reliance on open source makes that conclusion circular at best. Some even argue that open source is more secure because of the greater number of eyes that can review and repair it, all else being equal. Regardless, the same transparency and mutability that make open source software so useful to the entire ecosystem also present security challenges.
Many open source projects are maintained by developers in their free time, and the developers do not always update their own dependencies, creating “trickle-down” vulnerabilities. According to a report by Veracode, open source developers do not update project packages 79 percent of the time. The installation of just one package can result in an average of eighty indirect dependencies, as packages themselves frequently rely upon other open source components. Although these dependencies drastically reduce the need for developers to “reinvent the wheel” for every product they create, they also exponentially increase the attack surface of any given piece of code in an already resource-constrained environment.
Failures to mitigate open source vulnerabilities can have catastrophic consequences due to their widespread use and ambiguous ownership. For example, OpenSSL, responsible for managing website security certificates and implementing the transport layer security protocol (TLS), had a serious vulnerability called Heartbleed, which allowed attackers to steal and eavesdrop on encrypted internet traffic and left massive numbers of users vulnerable. Another popular package, event-stream, was compromised in 2018 when a malicious actor inserted into the program code that stole Bitcoin wallets to compromise copay-dash, a Bitcoin platform dependent on event-stream. It remained undetected for months. A new report from the cybersecurity firm Sonatype found a 650 percent increase in open source repository attacks in 2021. Most recently, the disclosure of a critical vulnerability in the ubiquitous log4j software put tens of millions of devices at risk.
Recommendations
- Invest in open source software as infrastructure: Open source consumers, including large private-sector entities and federal agencies, should commit regular contributions to any of a handful of organizations supporting security education, training, response, and governance to the OSS ecosystem. Organizations like the Open Source Technology Improvement Fund (OSTIF) specialize in open source vulnerability detection and bug-hunting. Similarly, the Open Source Security Foundation (OpenSSF), a Linux Foundation “cross-industry collaboration,” funds and assists critical open source projects. Although IT companies have made contributions in this vein to date, all software-intensive companies should consider their contribution to the security of the ecosystem on which they depend: automotive firms like Ford and Tesla, manufacturing giants like General Electric, 3M, and Boeing, and even retail titans like Walmart. Such firms can either contribute tooling developed in-house, the talents of developers, the use of maintenance hours, or direct financial resources. The federal government must also approach funding open source as an investment in infrastructure, but it will never be the sole source of support for open source—nor should it be. To support the work of the Critical Technology Security Centers (CTSCs) discussed below, CISA should partner with the private sector to make this kind of contribution to open source a baseline expectation for large-cap companies’ inclusion in security advisory and collaboration bodies.
- Institutionalize collaboration on OSS security and governance: At present there is no single, clear point of partnership for open source security in the US government, leaving a patchwork of private and nonprofit efforts to support the ecosystem without a clear public sector partner. The federal government should establish three critical entities explicitly designed to support and invest in the security of open source as critical infrastructure.
- Establish federal outreach: The CTSCs added to the House-passed COMPETES ACT (HR 4521) by amendment provide a model for channeling federal funds to open-source projects and security issues. The provisions would create at least four CTSCs for the security of network technologies, connected industrial control systems, open source software, and federal critical software. These CTSCs would collaborate with the input of the DHS Under Secretary of Science and Technology and the Director of CISA to study, test the security of, coordinate community funding for, and generally support CISA’s work regarding their respective technologies, providing a clear output entity from the US government to the open source ecosystem.
- Create an Open Source Office in CISA: The scale of modern IT’s dependence on open source is difficult to overstate; CISA should have a strong and central stake in open source policy and security work under the Cybersecurity Division (CSD).This office, established by Congress, could allocate funds and direct grants while serving as a focal point for operational efforts on open source security and governance across the federal enterprise, complementing the strategic frame of the ONCD. The office would have an important complementary role to efforts like OpenSSF, providing long-term perspective, resources, and insights from federal cybersecurity priorities as in input entity from the open source world to government. The CISA OSS office should be a source of support and advocacy for open source security as a component of supply-chain security policy work, coordinating across government agencies and offices to ensure that open source security is no longer tied to a crisis cycle.
- Bring OSS to the JCDC: CISA’s Joint Cyber Defense Collaborative (JCDC) should commit to the security and examination of open source software components as part of its partner activities and in coordination with the OSS CTSC and CISA’s OSS office. The three entities should coordinate with public and private entities to identify the most critical open source software repositories and packages and then take a proactive role in searching for vulnerabilities in critical open source software and allocating funding or staffing for patching, general maintenance, and tooling and service subsidies for the benefit of the entire ecosystem. The JCDC should begin to incorporate representatives of the OSS development and support network as well, acting as a vehicle for ongoing planning and coordination in support of the newly created OSS office in CISA.
- Maintain regular dialogue on open source: The ONCD and CISA’s OSS office should assemble with industry representatives and open source organizations semi-annually to assess the broader security needs of the open source ecosystem and commit to regular policy-goal adjustments to meet these needs while maintaining an ongoing dialogue with representatives of the ecosystem, from nonprofit coordinators to developer organizations. Ultimately, cybersecurity discussions should come to include an open source track from the get-go.
- Recommend and require best practices in open source incorporation during software development: NIST should, in its response to Executive Order 14028, recommend a minimum-acceptable examination for entities incorporating OSS. As a model, the Open Source Maturity Model is an existing framework for evaluating the reliability and safety of open source applications.Open source developers and maintainers, as well as industry should be an integral part of this process. NIST should also recommend routine information-flow analyses that assess how the integration of open source software affects application metrics within critical applications. If integration does affect critical application metrics significantly, developers should quantify that blast radius and take steps to insulate the applications from compromise. Open source should receive at least as much scrutiny and support as proprietary code.
- Establish voluntary repository best practices: The managers of open source repositories should agree upon the provision of minimum tooling to developers for versioning, security checks, integrity verification, checksums, dependency mapping, and so on, as well as best practices for flagging and slowing the download of code known to be vulnerable. This could take place through an existing collaborative group like OpenSSF’s Securing Software Repositories Working Group. Industry, coordinated by CISA through the JCDC, should identify the most critical repository-management gaps and fill them with public and private funding and direct contributions of tooling and developers.
- Leverage buying power to speed improvement and adoption: The federal government, through its acquisition processes, both civilian and military, and private-sector customers should require that products and services reliant on open source components adhere to those best practices, as identified by NIST at the developer level, and industry collaboration at the repository level, to some measurable, publicly stated degree. This lever will push vendors to demonstrate careful and deliberate selection, monitoring, and maintenance of open source product components from the most reputable repositories. The approach to this requirement might initially begin as the adoption of voluntary codes of conduct by repositories and IT product providers, evolving through customer requirements and toward explicit standards.
