Why CISOs Should Make Software Bills of Materials (SBOMs) a Top Priority in 2023

Software supply chains are soft targets for attackers seeking to take advantage of the lack of transparency, visibility, and security of open source libraries they use to embed malicious code for widespread distribution. In addition, when companies don’t know where code libraries or packages used in their software come from, it creates greater security and compliance risks.

The latest Synopsys Open Source security and risk analysis Report found that 97% of commercial code contains open source code and 81% contains at least one vulnerability. In addition, 53% of the analyzed codebases had license conflicts and 85% were at least four years out of date.

It is common for development teams to use libraries and packages found on GitHub and other code repositories. Software Bills of Materials (SBOMs) are necessary to track every open-source software (OSS) and library used during the devops process, including as it enters the software development life cycle (SDLC).

Security of software supply chains

Software development leaders must take action and integrate SBOMs into their SDLC and workflows to avoid the risk of Log4j and similar infected OSS components corrupting their code and infecting their customers’ systems. Software Composition Analysis (SCA) and the SBOMs they create provide devops teams with the tools they need to track where open source components are being used. One of the critical goals of using SBOMs is to create and keep current inventories of where and how each open source component is used.

“A lack of transparency about what software organizations buy, acquire and deploy is the biggest obstacle to improving supply chain security,” said Janet Worthington, senior analyst at Forrester, during a recent interview with VentureBeat.

The White House Implementing Decree 14028 improving the country’s cybersecurity requires software vendors to provide an SBOM. EO 14028 focuses on solving the lack of visibility of the software supply chain by requiring the NTIA, NIST and other government agencies to provide greater transparency and visibility into the software procurement and procurement process throughout the product lifecycle.

In addition, the implementing decree requires organizations that provide software to provide information not only about direct suppliers, but also about their suppliers’ suppliers, tier-2, tier-3 and tier-n suppliers. The Cybersecurity and Infrastructure Security Agency (CISA) Software Bill of Material Resource Center also provides valuable resources for CISOs to get started with SBOMs.

EO 14028 was followed by a memorandum written by the director of the Office of Management and Budget (OMB) to the heads of executive departments and agencies addressing the need to improve federal software supply chain security beyond the executive order requires.

“The combination of the executive order and the memo means that SBOMs will become important in the not-too-distant future,” he said. Matt Rose, ReversingLabs field CISO. Most noteworthy about the memorandum is that it requires agencies to obtain self-certification from software vendors that their devops teams are following the secure development processes defined in the NIST Secure Software Development Framework (SP800-218) and the NIST Software Supply Chain Security guidelines.

SBOMs help create trusted code at scale

Integrating SBOMs into devops processes, in addition to EO 14028 compliance, ensures that every downstream partner, customer, support organization, and government agency receives trusted apps built on solid, secure code. SBOMs do more than protect code. They also protect the brands and reputations of the organizations that ship software worldwide, especially web-based apps and platforms.

There is a growing lack of trust in code that has not been documented, especially among government procurement and procurement organizations. The challenge for many software vendors is to achieve a more successful shift-left strategy in integrating SBOMs and SCA into their continuous integration/continuous delivery (CI/CD) process. Shift-left security seems to close the holes that attackers look for to inject malicious code into payloads.

“CISOs and CIOs are increasingly realizing that teams need to embrace a secure devops culture to move quickly and achieve business goals. Developing an automated development pipeline allows teams to deploy frequently and with confidence because security testing is embedded from the earliest stages. Due to a security vulnerability escaping into production, having a repeatable pipeline ensures that the offending code can be rolled back without impacting other operations,” said Worthington.

CISOs now also need to familiarize themselves with the formal definitions of SBOMs, especially if they are part of a software supply chain that provides applications to the federal government. Formal standards include Data Exchange Software Package (SPDX), Software ID Tag (SWID) and CycloneDX. Of these, CycloneDX is the most commonly used standard. These standards aim to establish a data exchange format and common infrastructure that shares details about each software package. As a result, organizations that adopt these standards find they save time recovering and resolving disconnects, while increasing collaboration and the speed at which joint projects are executed.

For SBOMs, compliance is just the beginning

EO 14028 and the follow-up memorandum are just the beginning of the compliance requirements that devops teams and their organizations must meet to be part of the federal government’s software supply chain. SBOM requirements from the Federal Energy Regulatory Commission (FERC), Food and Drug Administration (FDA), and the European Union Agency for Cybersecurity (ENISA) now also require SBOM visibility and traceability to be a prerequisite for doing business. With SBOMs becoming the core of how U.S. and European governments determine who and how to do business with, CISOs must make this area a priority by 2023.