The Office of the National Cybersecurity Director recently released the End of 2023 Report on the Open Source Software Security Initiative, or OS3I, as part of the White House’s National Cybersecurity Strategy. The NCS states that in partnership with the private sector and the open source software, or OSS, community, the federal government will continue to invest in the development of secure software, including software development techniques, frameworks and testing tools in addition to secure languages.
According to the ONCD report, OSS is a public good, and ensuring the resilience of open source software is a technical necessity and strategic imperative to protect and advance US interests.
OSS is widely used in the federal government, as well as in all sectors of critical infrastructure. Security and protection of OSS is of utmost importance as we move forward with the OS3I initiative. The question facing software developers is: Can this be achieved by ensuring that OSS is embedded in applications only when secure design principles are used?
Secure-by-Design approach
Because of their widespread use, vulnerabilities in OSS can have an extremely large impact on products and users. To avoid these potential risks, it is 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 commitment level from the organization.
A secure design methodology starts with the developer and incorporates security throughout the software development lifecycle. This helps organizations create products that have built-in security from the point of code generation and avoids placing the burden and responsibility of security on end users.
Other safety-by-design recommendations include creating software bills of materials, or SBOMs, and modernizing legacy code with memory-safe programming languages.
Creation of SBOMs
The OS3I report also found that it is difficult for end users to identify all open source software within software applications and related products. One of the best ways to achieve visibility into your systems is SBOM, which is another cornerstone of the Security by Design principle.
SBOMs are an inventory of the components that make up software, which includes key information about the libraries, tools, and processes used to develop, build, and deploy a software artifact. SBOM explicitly delineates the sources of software components, enabling customers, operators and defenders to assess the origin, vulnerabilities and risks of a software package or an entire system.
Taking it a step further, using SBOM tools with vulnerability detection and security policies improves security postures and enables more secure applications and processes. Using SBOMs, embedded with other security-by-design principles and best practices, is a powerful method for creating a secure environment for incorporating OSS.
Modernization of insecure code
Another issue presented in the OS3I report is the use of memory-insecure 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, a subcommittee of CISA’s Technical Advisory Council recently released the CSAC Memory Security Report, addressing the pressing issue of memory security to prevent memory corruption and vulnerabilities in code. Memory security is responsible for approximately 70% of reported security issues according to Microsoft and Google Chrome.
Except for C and C++, most modern programming languages are already memory-safe, meaning that the languages manage the computer’s memory so that the programmer and bad actors cannot introduce security flaws in the memory. However, C and C++ are still the #2 and #3 languages by coding interest and skill set, accounting for about 21% of the market according to the TIOBE index, which means many decades of code will need to be refactored.
Languages that are not safe to remember could eventually be rejected by the government. Organizations can pre-empt this problem by researching and prioritizing memory-safe languages such as Rust, C#, or Python.
OSS is the foundation of the software infrastructure on which our nation is built. The federal government is addressing OSS security with several recent priorities, including the recent OS3I initiative and the White House’s NCS. Software manufacturers must fully verify OSS upon initial download to verify downstream dependencies, origin of code contributions, last known maintainer updates, and any known vulnerabilities to ensure OSS is not malicious or deprecated.
Teams will want to rely on a secure design path, and technology vendors and software developers will soon have to take a crucial step to shift this burden by claiming ownership of their customers’ security results. Using a secure-by-design approach will address multiple OSS security gaps—a model where users can trust the security and integrity of the technology they use every day.
Joel Krooswyk is the Federal CTO at GitLab, the operator of GitLab A DevOps software suite that can develop, secure and manage software.