As readers of the AppSec Observer blog are aware, application attacks have continued unabated throughout the massive economic and social changes of the past two years. Most readers are also aware that an increasing number of cyberattacks target the software supply chain. The devastating SolarWinds attack in 2020 was followed by the supply chain attack on Colonial Pipeline that disrupted fuel supplies in the eastern U.S., the attack on Kaseya that impacted hundreds of its customers’ customers, and many more. Frequent supply chain attacks have become something of a “new normal” for those of us whose everyday work involves protecting applications.
WHY ARE WE HERE?
Even the U.S. federal government is concerned about this wave of supply chain attacks. After all, cybersecurity is national security, and software supply chains are connected to everything from election systems to defense logistics to critical infrastructure. The SolarWinds attack in particular impacted multiple federal agencies that were users of the company’s Orion infrastructure management solution—including agencies that manage top-secret military and intelligence information.
That is why the White House issued a comprehensive executive order (EO) in May that directed federal agencies to bolster cybersecurity, and ordered the National Institute of Standards and Technology (NIST) to issue new guidelines to support the EO’s provisions. Tellingly, the software supply chain was one of the most important issues in the EO and is covered in a lengthy Section 4.
Section 4 of the EO calls upon NIST, under the jurisdiction of the Department of Commerce, to outline a plan to safeguard the nation’s software supply chain, in consultation with the heads of many federal agencies, private-sector companies, and academics. Subsection (e) lists 10 areas of software supply chain security to focus on. The seventh of those 10 items requires software creators to provide federal purchasers with “a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website.”
WHAT IS AN SBOM?
In practice, an SBOM is exactly what it sounds like—an “ingredient list” of every software component that makes up an application, which could be compared to the ingredients list mandated by the FDA found on any packaged food sold in the United States. The SBOM ingredient list includes every library—both open-source software (OSS) and commercial off-the-shelf (COTS)—that is included in an application’s code. It includes services, dependencies, compositions, and extensions. In some cases, it also includes tooling and environmental information.
The need for SBOMs has been recognized for a number of years, and the Open Web Application Security Project (OWASP) designed the CycloneDX standard for SBOMs back in 2017. CycloneDX provides a common, accepted format by which SBOMs can be standardized across all industries. Jeff Williams, Contrast’s co-founder and CTO, serves on the advisory council for CycloneDX and helped shape the framework. This helps Contrast deliver on these exacting requirements.
ARE SBOMs NOW REQUIRED FOR EVERYONE?
President Biden’s Executive Order mandates that any organization that provides software meeting NIST’s definition of “critical software” to the U.S. government will need to provide an SBOM in order to do business with any federal agency. This applies to both software vendors as well as device manufacturers who rely on software to deliver critical capabilities to the U.S. government.
While the EO does not mandate SBOMs for the private sector, many large enterprises already demand them as a part of their Master Service Agreement (MSA) with a software provider. This is particularly true in highly regulated industries like healthcare and financial services where a software supply chain failure could result in costly non-compliance. With this EO, SBOM requirements could easily become a more routine part of the procurement process, even for smaller organizations.
HOW ARE SBOMs BENEFICIAL?
Just as other required labels keep consumers informed about what is in their food, how energy efficient an appliance is, and how to properly use a child safety seat, SBOMs help organizations understand how healthy and safe their applications are. An SBOM can help a variety of parties in an organization:
- Developers. For software engineers, an up to date SBOM is critical for managing technical debt and keeping libraries updated, as it helps them understand which libraries are related to which underlying dependencies.
- Security and compliance teams. These teams need to benchmark their third-party software risk to understand what is deployed, what version they are on, what dependencies could be adding to security debt, and what licensing implications are present with each component. The SBOM is the perfect tool for this required work.
- Incident response teams. SBOMs help these professionals research where a vulnerability originated and, if it is exploited, quickly inform customers.
- Procurement. SBOMs help organizations understand what risk they are assuming pre-purchase and use that information to negotiate discounts based on the terms described in the contract or MSA.
- Investors. SBOMs can help provide documentation of critical software assets for mergers and acquisitions (M&A), venture capital fundraising, and initial public offerings (IPOs)—helping investors avoid the oft-repeated tale of “buying a breach.”
HOW CONTRAST HAS DELIVERED
Contrast Security customers can generate an SBOM directly in a way that meets the specifications of OWASP's CycloneDX SBoM standard and the White House EO. The capability is available through a simple API or a command through the Contrast command-line interface (CLI) and exports to a digestible JSON export. Users will soon be able to produce a PDF version of an SBOM as well.
Contrast also goes beyond these requirements by flagging library usage, including active and inactive libraries and library classes. As our 2021 State of Open-Source Security Report found, 62% of libraries in applications are inactive—not used by the software in any way. And within active libraries, 69% of library classes are unused. The result is that only 9.4% of code in the typical application is active open-source library and class code, and most developers have no visibility into this.
Contrast helps developers effectively prioritize and streamline library remediation by highlighting code that is active. This level of feedback allows security teams to identify, manage, and respond to vulnerabilities within software packages deployed in applications—while giving developers the context they need to push actionable fixes that have a tangible impact on the integrity of their code.
The SBOM requirement in the White House EO is a sensible requirement—something that governments and other organizations need to demand to protect their software supply chain. Contrast provides its customers with the tools necessary to provide an up to date SBOM for an application at any time.
For more information on Contrast’s ongoing mission to safeguard the software supply chain that powers businesses and federal agencies alike, visit our Software Supply Chain Solutions Page.
