The Office of the National Cyber Director recently released a 2023 End of Year Report on the Open-Source Software Security Initiative, or OS3I, as part of the White House National Cybersecurity Strategy. The NCS states that in partnership with the private sector and open-source software, or OSS, community, the federal government will keep investing in the development of secure software, including software development techniques, frameworks, and testing tools in addition to memory-safe languages.
According to ONCD’s report, OSS is a public good, and ensuring open-source software’s resilience is a technical necessity and a strategic imperative for protecting and promoting U.S. interests.
OSS is widely used across the federal government as well as across all critical infrastructure sectors. The security and protection of OSS are of the utmost importance as we move forward with the OS3I initiative. The question software makers are faced with is: Can this be achieved by ensuring that OSS is incorporated into applications only when using secure-by-design principles?
A Secure-by-Design approach
Because of its broad usage, vulnerabilities in OSS can have an exceptionally wide impact on products and users. To avoid these potential risks, it’s essential to establish secure software development, vulnerability management, and vulnerability disclosure practices for OSS adoption.
One best practice approach to secure OSS adoption is to follow the Cybersecurity and Infrastructure Security Agency’s Secure-by-Design model, which includes three core principles: taking ownership of customer security outcomes, embracing radical transparency, and leading security transformations with executive-level commitment from the organization.
The secure-by-design methodology starts with the developer and incorporates security across the software development lifecycle. This helps organizations create products that have security built-in from the point of code creation and avoids putting the burden and liability of security on end-users.
Other secure-by-design recommendations include creating software bill of materials, or SBOMs, and modernizing legacy code with memory-safe programming languages.
Creating SBOMs
The OS3I report also found that it’s difficult for end-users to identify all open-source software within software applications and connected products. One of the best ways to gain visibility into your systems is with an SBOM, which is another cornerstone of secure-by-design principles.
SBOMs are an inventory of components that make up software, which includes critical information about the libraries, tools, and processes used to develop, build, and deploy a software artifact. An SBOM explicitly outlines the sources of software components, allowing buyers, operators, and defenders to evaluate the origins, vulnerabilities, and risks of a software package or an entire system.
Taking it a step further, using SBOM tooling with vulnerability disclosures and security policies improves security postures and enables more secure applications and processes. The use of SBOMs, incorporated with other secure-by-design principles and best practices, is a strong method to create a secure environment for incorporating OSS.
Modernizing unsafe code
Another issue presented in the OS3I report is the use of memory-unsafe programming languages. ONCD found that the use of memory-unsafe languages, especially in system or kernel software, is common.
In support of CISA’s Secure-by-Design initiative, the CISA Technical Advisory Council Subcommittee recently released a CSAC Memory Safety Report, tackling the pressing issue of memory safety to prevent memory corruption and vulnerabilities in code. Memory safety accounts for approximately 70% of reported security issues according to Microsoft and Google Chrome.
Besides C and C++, most modern programming languages are already memory safe, meaning that the languages manage the computer’s memory so the developer and bad actors can’t introduce memory safety vulnerabilities. However, C and C++ are still the number 2 and number 3 languages in coding interest and skill set, composing about 21% of the market per the TIOBE index, meaning many decades of code will need to be refactored.
Memory-unsafe languages could eventually be refused by the government. Organizations can get ahead of this issue by investigating and prioritizing memory-safe languages, such as Rust, C#, or Python.
OSS is foundational to the software infrastructure that our nation is built on. The federal government is tackling OSS security with several recent priorities including its recent OS3I initiative and the White House’s NCS. Software makers need to fully verify OSS on the very first commit to validate downstream dependencies, code contribution origins, last known maintainer updates, and any known vulnerabilities to ensure the OSS is not malicious or abandoned.
Teams will want to lean into the secure-by-design pathway, and technology providers and software developers will soon have to take a key step to shift this burden by claiming ownership of their customers’ security outcomes. Utilizing a secure-by-design approach will address multiple gaps in OSS security – a model by which users can trust the safety and integrity of the technology that they use every day.
Joel Krooswyk is Federal CTO at GitLab, operator of the Gitlab DevOps software package that can develop, secure, and operate software.
