Socket
Socket
Sign inDemoInstall

Security News

White House Report Highlights Persistent Challenges and Urgent Needs in Open Source Software Security

New report from the White House aims to address gaps in open source security, calling for more funding, tighter supply chain controls, and stronger collaboration.

White House Report Highlights Persistent Challenges and Urgent Needs in Open Source Software Security

Sarah Gooding

August 13, 2024


In recognition of the ubiquity of open source software, and the critical need to secure U.S. infrastructure, the White House has published a summary of the 2023 RFI on the Open Source Software Security. This effort is aimed at establishing a strategic approach for the secure use of open source software and determining how the federal government can invest resources in the ecosystem and engage with the OSS community.

The White House Office of the National Cyber Director, in partnership with members of the Open Source Software Security Initiative (OS3I), received 107 public responses regarding the five focus areas the government is prioritizing to improve resiliency:

  • Secure Open Source Software Foundations
  • Sustaining Open Source Software Communities and Governance
  • Behavioral and Economic Incentives to Secure the Open Source Software Ecosystem
  • R&D/Innovation
  • International Collaboration

The RFI asked participants to comment on the which sub-areas of focus should be prioritized for action and what technical or policy changes the government should consider when implementing solutions. The majority of responses concentrated on securing open source software foundations.

Participating companies and organizations include Red Hat, Apache Software Foundation, OSI, Rust Foundation, GitLab, OWASP, MITRE, IBM, Google, Sonatype, OpenSSF, Tidelift, AWS, Python Software Foundation, Cloudflare, GitHub, US Chamber of Commerce, among others.

Supply Chain Recommendations: Secure Package Registries, Standardize SBOMs#

Strengthening supply chain security was among the sub-areas for securing OSS foundations, including the following potential actions:

  • Designing tools to enable secure, privacy-preserving security attestations from software vendors, including their suppliers and open-source software maintainers
  • Detection and mitigation of vulnerable and malicious software development operations and behaviors
  • Incorporating automated tracking and updates of complex code dependencies
  • Incorporating zero trust architecture into the open-source software ecosystem

The summary highlights respondents’ recommendation for standardizing SBOMs. Manifest Cyber recommended supplying agencies with “SBOMs and attestation management tools that provide a high level of vulnerability database integration.” They also recommended using tools that create SBOMs during the build process:

Additionally, respondents noted that while current practice is that SBOMs are often created by analyzing the final binary or another software artifact, it is preferable to use tools that create SBOMs during the build process because build-time tools generally have access to more detailed and accurate information than what is available from analyzing an artifact.

Respondents also emphasized the need to secure package registries that distribute open source software, with some recommending the government participate in developing best practices for these services and fund non-profits that operate them. The goal of additional funding would contribute to sustained security improvements.

OpenSSF advocated for using federal funds to support package repositories, which “are a focal point for all manner of supply chain attacks where attackers can leverage techniques such as typosquatting and dependency confusion:”

To tackle the security of OSS supply chains at scale, a key focus must be on securing these repositories. Because each repository is managed by different entities, foundations, or corporations, and handles different types of software distributed in different ways with different installation mechanisms, approaches will need to be tailored for each. Funding and/or experts’ time is a key limitation. Many are inadequately funded; even those with commercial backing are often little monetized and are costs to their commercial backers. We believe the US government should work with these repositories, including either direct funding or using their experts to help repositories improve their security.

OpenSSF proposed a number of recommended actions for securing package registries, including enabling malicious package detection. Package repositories could check for malicious indicators and provide security testing of code before allowing contribution of a package, preventing a wide range of trivial malicious software from getting publicly distributed. Implementing this in a way that doesn’t slow innovation would be challenging but could have a significant impact on supply chain security.

RFI respondents also advocated for additional security initiatives, including the adoption of memory safe programming languages, funding development of new OSS security tools and libraries, and research on the use of AI (LLMs and ML) to accelerate secure software development.

These organizations commenting on the RFI impressed upon OS3I the importance of reducing entire classes of vulnerabilities at scale, and other collaborative efforts such as public-private partnerships with OSS ecosystems, the sharing of known vulnerabilities throughout the global software supply chain, establishing standards at the purchasing-level to guide the ecosystem, and international collaboration on frameworks and policies.

Government Funding for OSS Maintainers#

The summary highlighted one of the unique challenges of sustaining the open source software ecosystem - the fact that the software everyone relies upon isn’t always provided by or backed by a commercial vendor:

In the open-source software ecosystem, individual contributors to open-source software voluntarily support projects of their own choosing, unlike a traditional supply chain model where “suppliers” are tasked and compensated for their contributions. According to Tidelift, Inc., more than half of open-source software maintainers describe themselves as “unpaid hobbyists” who do not earn their income from sustaining open-source software projects.
Respondents stressed the importance of government funding to support libraries commonly used in critical infrastructure and incentivizing third-party analysis and validation. A respondent noted that effective funding for open-source software security improvements cannot be limited to identifying vulnerabilities, but must support remediating vulnerabilities as well.

This situation is underscored by recent supply chain attacks like the 2021 Log4Shell vulnerability and the 2024 XZ Utils backdoor attempt. Securing software supply chains is a top priority of the U.S. government following these incidents.

“The lack of consistent support for OSS by commercial users can jeopardize the maintenance and security of these OSS projects,” the Open Source Initiative (OSI) commented. “The maintainers of popular and mature OSS projects generally understand the importance of security and endeavor to deliver secure software. But the growing complexity and quickening pace of technology change, the increasingly hostile threat landscape, and the increase in regulatory requirements present OSS communities and projects with growing, costly demands.”

The Python Software Foundation’s comments highlighted how many maintainers lack the capacity to track evolving security methods:

A large volume of projects on PyPI, including widely-used projects such as urllib3 or cryptography, however, are maintained by volunteers, not by corporations. Many projects are even maintained by a sole maintainer, often without the resources or even the knowledge to update their package publishing processes to more secure methods. Out of 490,000 projects on PyPI, 91% of projects have a single account with the maintainer role. For example, maintainers using a username/password for publishing packages may receive an email directing them to adopt API Tokens, but still places the burden of adoption on the maintainer. Providing maintainers with tools to easily adopt the newer practice could accelerate better security practices, reducing risk exposure across the ecosystem.

The Apache Software Foundation’s comments noted that the 2022 Census II of Free and Open Source Software found that “94% of projects had fewer than ten developers accounting for more than 90% of the lines of code added. In 49 of the top 50 non-npm projects reviewed, nearly a quarter of them had only one developer responsible for more than 80% of the lines of code added.” The foundation emphasized the value of companies giving employees the time and freedom to participate in OSS projects, in combination with contributions to a foundation.

The RFI summary outlines how the government is mobilizing on these recommendations through 12 activities that the OS3I plans to complete or has already completed in 2024. These include advancing research and development, securing package registries, partnering with OSS communities, promoting the use of SBOMs, and establishing a U.S. government Open-Source Program Office (OSPO), to highlight a few initiatives. OS3I concluded the report by reiterating its commitment to creating cyber policy with the “end user” in mind that champions a proactive cybersecurity posture.

Subscribe to our newsletter

Get notified when we publish new security blog posts!

Try it now

Ready to block malicious and vulnerable dependencies?

Install GitHub AppBook a demo

Related posts

Back to all posts
SocketSocket SOC 2 Logo

Product

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc