Linux and open-source communities rise to Biden's cybersecurity challenge
Anyone who thought computer security problems were some abstract trouble that had little to do with their daily life was rudely awakened recently. The Colonial Pipeline ransomware attack saw gas and oil deliveries shut down throughout the southeast. Cybersecurity failures had already become a major problem with the SolarWinds software supply chain attack and the FBI having to step in to fix broken Microsoft Exchange servers. So, on May 12th President Joe Biden signed an executive order to boost the federal government cyber defense and to warn all of America that technology security must be job one now. The Linux Foundation and its related organizations are stepping up to better Linux and open-source security.
ZDNET Recommends
The executive order recognized the vital importance of open-source software. It reads in part: "Within 90 days of publication of the preliminary guidelines … shall issue guidance identifying practices that enhance the security of the software supply chain." Open-source software is specifically named.
The government must ensure "to the extent practicable, to the integrity and provenance of open-source software used within any portion of a product." Specifically, it must try to provide a Software Bill of Materials (SBOM). "This is a formal record containing the details and supply chain relationships of various components used in building software." It's an especially important issue with open-source software because:
Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open-source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems.
So how much code is this anyway? The managed open-source company Tidelift has found that 92% of applications contain open source components. Indeed, the average modern software application may be made up of as much as 70% open-source software. Tidelift offers a service for providing open-source SBOMs.
The open-source community itself has long been addressing this issue. In particular, the Software Package Data Exchange (SPDX) project has been working for the last ten years to enable software transparency and SBOM. SPDX is in the final stages of review to be the ISO/IEC International Standard 5962, and is supported by global companies with massive supply chains, and has a large open and closed source tooling support ecosystem.
SPDX 2.2 already supports the National Telecommunications and Information Administration (NTIA) current guidance minimum SBOM elements. In short, if your open-source software provides an SPDX SBOM it already meets the executive order's requirements. For examples of SPDX see:
An NTIA "plugfest" demonstrated ten different producers generating SPDX. SPDX supports acquiring data from different sources (e.g., source code analysis, executables from producers, and analysis from third parties).
A corpus of some LF projects with SPDX source SBOMs is available.
Various LF projects are working to generate binary SBOMs as part of their builds, including Yocto and Zephyr.
To assist with further SPDX adoption, the Linux Foundation is paying to write SPDX plugins for major package managers.
Of course, many programs don't support SPDX… yet. They will. It's the only way to make certain you know what's really in your open-source programs and that's become a matter of national importance.
This is not just a problem, of course, with open-source software. With open-source software, you can actually see the code so it's easier to make an SBOM. Proprietary programs, like the recently, massively exploited Microsoft Exchange disaster, are black boxes. There's no way to really know what's in Apple or Microsoft software.
Indeed, the biggest supply-chain security disaster so far, the Solarwinds catastrophic failure to secure its software supply chain, was because of proprietary software chain failures.
Besides SPDX, the Linux Foundation recently announced a new open-source software signing service: The sigstore project. Sigstore seeks to improve software supply chain security by enabling the easy adoption of cryptographic software signing backed by transparency log technologies. Developers are empowered to securely sign software artifacts such as release files, container images, and binaries. These signing records are then kept in a tamper-proof public log. This service will be free for all developers and software providers to use. The sigstore code and operation tooling that will make this work is still being developed.
Before sigstore, the Linux Foundation's earlier Core Infrastructure Initiative (CII) and its current Open Source Security Foundation (OpenSSF) have been working to secure open-source software, both in general and its components. The OpenSSF, in particular, is a broad industry coalition "collaborating to secure the open-source ecosystem."
To further ensure the integrity of supply chains, the executive order demands that agencies employ "automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code." The Linux Foundation oversees multiple projects to help with this besides sigstore.
The LF has many projects that support SC integrity, in particular:
in-toto is a framework specifically designed to secure the integrity of software supply chains.
The Update Framework (TUF) helps developers maintain the security of software update systems, and is used in production by various tech companies and open source organizations.
Uptane is a variant of TUF; it's an open and secure software update system design that protects software delivered over the air to the computerized units of automobiles.
OpenChain (ISO 5230) is the International Standard for open source license compliance. Application of OpenChain requires identification of OSS components. While OpenChain by itself focuses more on licenses, that identification is easily reused to analyze other aspects of those components once they're identified (for example, to look for known vulnerabilities).
The executive order also asks:
The Secretary of Commerce [acting through NIST] shall solicit input from the Federal Government, private sector, academia, and other appropriate actors to identify existing or develop new standards, tools, and best practices for complying with the standards, procedures, or criteria [including] criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices [and guidelines] for enhancing software supply chain security.
To address this, the OpenSSF's CII Best Practices badge project specifically identifies open-source software best practices. This focuses on security. It includes criteria to evaluate the security practices of developers and suppliers. Today, it has over 3,800 participating projects. The Linux Foundation is also working with Supply-chain Levels for Software Artifacts (SLSA) to further deal with supply chain issues.
The Executive Order also requires agencies to adopt "encryption for data at rest and in transit." Encryption in transit is already implemented on the web using the Transport Layer Security (TLS) protocol. The Internet Security Research Group (ISRG) open Let's Encrypt project is the world's largest certificate authority for TLS certificates.
In addition, the LF Confidential Computing Consortium is dedicated to defining and accelerating the adoption of confidential computing. Confidential computing protects data in use, at rest, and in transit by testing them in a hardware-based Trusted Execution Environment. These secure and isolated environments prevent unauthorized access or modification of applications and data.
Of course, there always will be bugs. To address these the CII Best Practices badge passing criteria requires that OSS projects specifically identify how to report vulnerabilities to them. More broadly, the OpenSSF Vulnerability Disclosures Working Group is working to help "mature and advocate well-managed vulnerability reporting and communication" for OSS.
For example, while most widely used Linux distributions, especially Red Hat, have a robust security response team, not everyone does. The Alpine Linux distribution, which is widely used in container-based systems, until recently didn't have one. The Linux Foundation and Google funded various improvements to Alpine Linux, including a security response team.
Biden's executive order also called on everyone to focus on "critical software." The Linux Foundation has been doing this for some time. The Linux Foundation and the Laboratory for Innovation Science at Harvard (LISH) recently released the Vulnerabilities in the Core, a Preliminary Report and Census II of Open Source Software. This, like the name says, analyzed critical and vulnerable open-source software. This report is being updated.
The CII also identified many important projects and assisted them in becoming more secure. These include small but vital projects -- aka the all-important program supported by one person working out of their farmhouse in Nebraska including OpenSSL (after Heartbleed), OpenSSH, GnuPG, Frama-C, and the OWASP Zed Attack Proxy (ZAP). The OpenSSF Securing Critical Projects Working Group has been working to better identify critical OSS projects and to focus resources on critical OSS projects that need help. There is already a first-cut list of such projects, along with efforts to fund such aid.
Thinking of security jokes, the executive order recognizes that most Internet of Things (IoT) device security bugs are never fixed. As the joke goes the "S in IoT is for security." The responsibility for that lies with IoT vendors who sometimes don't even provide options to update their software, never mind actually issuing security patches. While the Linux Foundation can't do that, Linux Foundation members can and do supply secure software and operating systems. These include:
The Linux kernel itself, which is used by many IoT devices.
The Yocto project, which creates custom Linux-based systems for IoT and embedded systems. Yocto supports full reproducible builds.
EdgeX Foundry, which is a flexible open-source software framework that facilitates interoperability between devices and applications at the IoT edge, and has been downloaded millions of times.
The Zephyr project, which provides a real-time operating system (RTOS) used by many for resource-constrained IoT devices and is able to generate SBOM's automatically during build. Zephyr is one of the few open-source projects that is a CVE Numbering Authority.
The seL4 microkernel, which is the most assured operating system kernel in the world; it's notable for its comprehensive formal verification.
Finally, the Linux Foundation is already addressing the call for a consumer software labeling program [that reflects] a baseline level of security practices with several projects. Besides the aforementioned OpenSSF's CII Best Practices badge project, these are:
Community Health Analytics Open Source Software (CHAOSS) focuses on creating analytics and metrics to help define community health and identify risk
The OpenSSF Security Metrics Project, which is in the process of development, was created to collect, aggregate, analyze, and communicate relevant security data about open source projects.
The OpenSSF Security Reviews initiative provides a collection of security reviews of open-source software.
The OpenSSF Security Scorecards provide a set of automated pass/fail checks to provide a quick review of arbitrary OSS.
Put it all together, and the Linux and open-source community are already well on their way to meeting the demands of this new security order. Much more needs to be done, but at least the framework is in place.
This is essential work. The Linux Foundation would welcome your help with it. As David A. Wheeler, the Linux Foundation's Director of Open Source Supply Chain Security, said, "We couldn't do this without the many contributions of time, money, and other resources from numerous companies and individuals; we gratefully thank them all. We are always delighted to work with anyone to improve the development and deployment of open-source software."
As the events of recent months have shown--indeed recent hours with the ransomware attack on Ireland's health system--security must become job number one not just for the federal government, but for everyone.
Related Stories: