With continued pressure to keep systems secure and no reduction in the general threat landscape, a machine-readable Software Bill of Materials (SBOM) may help teams stay on top of security problems in the libraries that they rely on. Since the original Executive Order was published, the industry has gained clarity and understanding of what an SBOM is and how to create one; the National Institute of Standards and Technology (NIST), for example, now has more specific advice on how to comply with the order. We've had production experience using SBOMs on projects ranging from small companies to large multinationals and even government departments, and we're convinced they provide a benefit. More organizations and governments should consider requiring SBOMs for the software they use. The technique will be strengthened by the new tools that continue to emerge, such as the Firebase Android BOM that automatically aligns an application's library dependencies to those listed in the BOM.
With continued pressure to keep systems secure and no reduction in the general threat landscape, a machine-readable Software Bill of Materials (SBOM) may help teams stay on top of security problems in the libraries that they rely on. The recent Log4Shell zero-day remote exploit was critical and widespread, and if teams had had an SBOM ready, it could have been scanned for and fixed quickly. We've now had production experience using SBOMs on projects ranging from small companies to large multinationals and even government departments, and we're convinced they provide a benefit. Tools such as Syft make it easy to use an SBOM for vulnerability detection.
In May 2021, the U.S. White House published its Executive Order on Improving the Nation's Cybersecurity. The document puts forward several technical mandates that relate to items we've featured in past Radars, such as zero trust architecture and automated compliance scanning using security policy as code. Much of the document is devoted to improving the security of the software supply chain. One item in particular that caught our attention was the requirement that government software should contain a machine-readable Software Bill of Materials (SBOM), defined as "a formal record containing the details and supply chain relationships of various components used in building software." In other words, it should detail not just the components shipped but also the tools and frameworks used to deliver the software. This order has the potential to usher in a new era of transparency and openness in software development. This will undoubtedly have an impact on those of us who produce software for a living. Many, if not all software products produced today contain open-source components or employ them in the build process. Often, the consumer has no way of knowing which version of which package might have an impact on the security of their product. Instead they must rely on the security alerts and patches provided by the retail vendor. This executive order will ensure that an explicit description of all components is made available to consumers, empowering them to implement their own security controls. And since the SBOM is machine-readable, those controls can be automated. We sense that this move also represents a shift toward embracing open-source software and practically addressing both the security risks and benefits that it provides.
