For decades, the public and private sectors have steadily increased their use of open source software (OSS), representing a significant evolution in software development and deployment. In contrast to traditional proprietary software development models, OSS is published under an open license so that anyone can scrutinize, modify, or build upon it for their own purposes, commercial or otherwise. This decentralized model, along with a vibrant and diverse community of OSS developers, offers tremendous benefits for innovation, cost-effectiveness, and flexibility, which is why IBM has been investing in and contributing to open source ecosystems for over 20 years.

 

OSS is now ubiquitous, used by governments, businesses, and consumers alike in applications like Mozilla Firefox, Linux, and countless other pieces of valuable software that incorporate OSS in their codebases. As policymakers grapple with improving cybersecurity, they should be willing to embrace new solutions while being careful to protect what makes OSS and the OSS community so valuable in the first place.

 

In late 2021, a major vulnerability in a widely used piece of OSS called Log4j set companies and governments alike scrambling to protect the potentially millions of affected devices, making the critical importance of OSS security more evident than ever. One of the main reasons the Log4J vulnerability was so severe is that many technology providers did not know if and how Log4J was used throughout their code, so when new, more secure versions were released, or patches to critical vulnerabilities became available relatively quickly, it was extremely difficult to identify when and where providers needed to take action.

 

Log4j should serve as a case study for policymakers interested in bolstering OSS security and software security as a whole. It highlights the problems that can arise in software supply chain management and tees up a valuable new approach to help combat these challenges. As policymakers consider this, it is critically important that they recognize that how code is developed – either entirely through proprietary means or through the use of OSS – does not play a significant role in how vulnerable the code is to security vulnerabilities.

 

One of the more effective ways policymakers could help prevent a future Log4j-style crisis is to promote the development and utilization of a software bill of materials (SBOM). An SBOM is a formal record of all the components needed to build a particular piece of software and the supply chain relationships of these components. SBOMs are not a silver bullet and will need to be part of a much broader, comprehensive approach to cybersecurity to be effective. Still, they hold the promise to solve one of the greatest challenges associated with the use of OSS: technology providers may not be aware of where and how OSS code is used throughout their codebase, making identifying and responding to security threats cumbersome and unreliable.

 

The goal that SBOMs aim to achieve is to provide better visibility into the software supply chain of modern application development. All stakeholders should explore other opportunities to adopt solutions that complement the use of SBOMs. Most importantly, this includes placing a greater emphasis on code curation – the process of thoroughly vetting and documenting new portions of code integrated into a codebase. Better code curation could help technology providers stay more informed about security risks and encourage better cyber hygiene overall. Increasing the attention paid to code curation could, for example, prevent a developer from inadvertently incorporating an outdated piece of OSS with security vulnerabilities that subsequent releases of that code have addressed.

 

While SBOMs may be especially useful for software incorporating OSS, they can offer similar benefits to all software, regardless of whether OSS is involved. Thus, while OSS security may be the impetus for policymakers to take action, the use of SBOMs should cover both OSS and proprietary software.

 

Importantly, SBOMS are only useful if developers actually rely on them to identify and address vulnerabilities in the dependency chain throughout the software development lifecycle rather than treat them merely as a reporting requirement. There are several ways policymakers could encourage the meaningful utilization of SBOMS and support code curation:

 

• • Invest in accelerating the maturation of standards and best practices for SBOMs that meet industry and government needs while minimizing compliance burdens. In particular, this should focus on the use of SBOMs throughout the software development lifecycle, including the early concept and design phases.
• • Align existing efforts to improve cybersecurity, such as the National Institute for Standards and Technology’s Secure Software Development Framework (SSDF), with the goal of the widespread utilization of SBOMs, rather than just their development.
• • Leverage the government’s procurement authority to preference software vendors that attest to the meaningful use of SBOMs for their software provided to the government. There should be procurement preferences for curated, supported software generally.

 

In addition to these actionable recommendations, there are two key principles that all stakeholders should bear in mind as they work to improve security. The first is that improving security is primarily a matter of improving execution, not developing new interventions. Secure software design, development, build, and distribution practices are well understood and defined in many industry standards and guidelines, and have been for years. Software development organizations typically don’t need to invent new approaches to solving this problem but instead should focus on using and executing such well-established practices. IBM leverages the ISO20243 standard, as well as the NIST SSDF, as the foundation for its security-by-design practices and would recommend these standards to others as well.

 

The second principle is that users of OSS should contribute to improving OSS for all. Rather than depend on each and every contributor to open source communities to implement security-by-design best practices on their own, the OSS ecosystem can avoid the tragedy of the commons if those that regularly consume OSS contribute back to the OSS communities from whom they most often ingest code. Those heavily reliant on OSS, including government agencies, must stop thinking about OSS as “free” software and contribute directly to the open source communities they depend on to ensure that they have the support necessary to truly embrace security.

 

Those that do not have the engineering resources to directly contribute and participate on their own should instead acquire OSS through other companies or organizations that do so. IBM has been strongly committed to contributing to open source for decades as a founding member of the Open Source Security Foundation and a longtime supporter of Linux, Java, Apache, and other bedrock open source components. IBM is committed to increasing its contributions in the future, including by training new developers on cybersecurity through its IBM Skills program and by directly embedding skilled developer resources into each of the top 50 open source projects most critical to IBM and our clients, with these developers dedicated to assisting on security testing and vulnerability remediation.

 

As policymakers pursue these strategies to improve OSS security, they should also be careful to avoid strategies that may seem prudent but would likely be ineffective or undermine the qualities that make OSS valuable. Funneling more money to OSS developer organizations may be helpful to promote education on best practices for security but would not be sufficient to address how security challenges manifest in the real world, which often arise not from a lack of awareness about best practices, but from a lack of mechanisms to encourage adherence to best practices. Proposals that would fundamentally alter the dynamics of the OSS community, such as attempting to police contributors to open source projects based on their nationality, would similarly fall short. The OSS community is the key reason OSS is so valuable, as it encourages passionate developers from all walks of life and of all skill levels to create, hone their skills, and contribute to the public good. Fundamentally altering this dynamic risks sabotaging the nature of OSS and the valuable innovation it enables.

 

Security is never “done” – any actions policymakers and other stakeholders take to improve OSS security should be viewed as part of a perpetual commitment to enhancing the resilience of the critically important infrastructure that OSS supports. It may take years for SBOMS to reach maturity and widespread utilization or for better code curation to be ingrained in all developers, but policymakers can and should take steps to make progress toward solving OSS security as soon as possible.

 

-Jamie Thomas, IBM Enterprise Security Executive

 

 

 

 

 

 

 

-Joshua New, Senior Fellow, IBM Policy Lab

 

 

 

 

 

 

 

 

Share this post: