On Dec. 17, 2025, U.S. Sen. Tom Cotton, the chairman of the Senate Intelligence Committee, sent a letter to Sean Cairncross, the National Cyber Director, concerning what he called the “critical national security risk” posed by open source software (OSS). OSS – code that is generally free to use and customize – continues to grow in popularity. According to an October 2025 report from The Linux Foundation, “OSS has achieved mission-critical status across enterprise technology stacks.” But according to Cotton, “there are reports that state-sponsored software developers and cyber espionage groups have started to exploit this communal environment [of OSS], which assumes that contributors are benevolent, to insert malicious code into widely used open source codebases.”
This post provides a brief overview of OSS, highlights upcoming regulations aimed at mitigating OSS security risks, and offers practical guidance for organizations seeking to safeguard against these threats.
What Is OSS?
Even for those of us steeped in techno-speak on a regular basis, defining terms at the outset is always a helpful exercise. Generally, OSS is computer software whose source code is made publicly available under a license that allows the public to use, study, modify, and redistribute the software and its source code. OSS is typically developed in a collaborative manner through an open community participating in its ongoing improvement. While license terms vary, OSS licenses generally grant broad permissions for use, modification and distribution as opposed to license models that restrict access and modification rights.
Why Is OSS Seen as Mission-Critical?
According to the October 2025 report from The Linux Foundation, OSS is being used across core technology domains, with the top five being operating systems (55 percent), cloud/container technologies (49 percent), web/application development (46 percent), database/data management (45 percent) and DevOps (45 percent). According to its survey results, The Linux Foundation reported that 46 percent of organizations saw increased business value from OSS last year on the grounds that it improves productivity, reduces vendor lock-in, lowers cost of software ownership, facilitates innovation and improves software quality.
Why Is Cotton Concerned About OSS Security Risks?
It is all about “malicious code” or packages. Unintentional vulnerabilities in OSS are not a new problem. Since 2024, the Open Worldwide Application Security Project has published a list of the top 10 risks associated with OSS, and “known vulnerabilities” have been the top risk since the beginning. However, Cotton is concerned about the combination of (a) increased reliance on OSS for government and critical infrastructure and (b) increased instances of malicious packages – intentionally created security flaws – being found in OSS. While Cotton’s letter to the National Cyber Director notes several examples of malicious packages being inserted into OSS code, a recent report from a security scanning company claims to have found hundreds of thousands of malicious packages across multiple OSS ecosystems.
Governmental Efforts To Address OSS Security Risks
From a U.S. federal perspective, most work is being done through executive orders (EOs). In 2021, the Biden administration published EO 14028, Improving Our Nation’s Cybersecurity. Among other things, this EO directed multiple agencies and organizations to enhance software supply chain security by mandating secure development practices, use of Software Bills of Material (SBOMs) and vetting of open source components. The National Institute of Standards and Technology’s (NIST) Secure Software Development Framework (SSDF) V1.1 guidelines stem from this EO.
The Trump administration then built on EO 14028 with EO 14144 in early 2025. This EO expanded accountability in third-party software supply chains used by the federal government and pushed for secure development standards and stronger transparency with respect to vulnerabilities.
In spite of these EOs, NIST SSDF frameworks, and agency-level requirements for SBOMs or secure software development attestations, there has been precious little guidance for the private sector on what they must do. As recently as Dec. 19, 2025, the draft Federal Acquisition Regulation clauses that would clarify these requirements continue to be bogged down in discussion between multiple federal agencies. See FAR Case No. 2023-002 (noting that while the draft clauses will implement EO 14028 so that suppliers “may comply with applicable secure software development requirements,” the OFPP, FAR and DAR staff “are still resolving issues”). Only time will show if Cotton’s letter will spur finalization of this language.
From an international perspective, the European Union already has passed the Cyber Resilience Act, a regulation covering certain types of hardware and software (including some open source material). While the regulation includes a variety of security requirements for covered products, a key requirement regarding vulnerability reporting will go into effect on Sept. 11, 2026. Among other things, products must include proactive vulnerability handling processes throughout the product life cycle and vulnerabilities must be reported within 24 hours of anyone becoming aware of active exploitation.
Practical Considerations To Address OSS Security Risks
Assess the Adequacy of Your OSS Governance Structures
The Linux Foundation report notes that “despite open source’s widespread adoption in mission-critical infrastructure . . . organizational maturity lags behind usage.” It reports that only 26 percent of organizations have implemented a dedicated governance program for OSS and only 34 percent have defined clear open source strategies. As noted in the report, this governance gap creates substantial risk exposure given the mission-critical nature of these deployments.
Prepare for Increased Regulatory Oversight
Work with your legal or compliance teams to understand whether your organization is likely in scope for new or pending regulations. For example, federal contracts may soon start requiring software development attestations or SBOMs, and it will take time for your organization to prepare these materials. Work now with your appropriate stakeholders to avoid or mitigate risk of future noncompliance. Similarly, if your company or products are in scope for the European Union’s Cyber Resilience Act, work now to align internally and build the necessary processes so you can satisfy your obligations for vulnerability reporting starting in September 2026.
Work with Security Teams To Develop Strategies To Identify and Respond to Threats Associated with Malicious Packages.
There will be no silver bullet for all organizations, and solutions will need to be tailored to specific risk tolerances and use cases. As you work with your team members to find the right balance for your organization, consider asking questions such as:
- Should we leverage more automated tools to scan for known vulnerabilities and malicious packages in dependencies?
- Should we develop and maintain an SBOM for all applications, even if that is not contractually required, to track open source components and versions so that we can quickly identify affected components when new threats emerge?
- Do our vulnerability and threat intelligence feeds cover the open source software we use?
[View source.]
