As concerns grow over how cybersecurity attacks on any single software supply chain component can impact the entire application and business ecosystem, it’s time to take a close look at your own enterprise applications. This activity starts by examining all your Software Bill of Materials (SBOMs).
The term SBOM emerged from the Bill of Materials (BOM) concept, which has been around since the Industrial Revolution in the 1800s. As manufacturers started converting raw materials into finished goods, they used BOMs to identify all the ingredients and suppliers.
SBOMs first came to light around 2010 as the open-source community developed the Software Package Data Exchange (SPDX) open standard.1 Like a BOM, an SBOM provides visibility into the ingredients used to create your software applications and supporting systems.
The National Telecommunications and Information Administration defines SBOM as a formal record containing the details and supply chain relationships of various components used in building software.2 These components—including libraries and modules—can be open source or proprietary, free or paid, and the data can be widely available or access-restricted.
Why Does SBOM Matter?
The rapid rise and increased sophistication of cybersecurity attacks, including the high-profile attack against SolarWinds, cost some of the 10’s of thousands of organizations as much as 11% of their annual revenue.3 The has raised awareness of the risk and made the use of SBOMs as part of your application delivery a mandatory policy. According to Gartner, cybercriminals have discovered that attacks on the digital supply chain can provide a high return on investment.4 As vulnerabilities (such as Log4j)5 spread through supply chains, more threats are expected to emerge.
Gartner also makes a dire prediction: By 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021.
You can avoid becoming part of this statistic by creating an SBOM and rooting out and identifying vulnerable components. This process allows you to start answering the key questions to determine your software applications’ current status and protections.
- Do you have the proper licenses in place?
- Are all the components currently supported? Commercially?
- Does each component have a patch for discovered vulnerabilities that should be applied?
How SBOM Fits into the Application Delivery Lifecycle
SBOM applies to any component used to develop an application—bespoke, commercial, or open source. This includes shared libraries, packages, and other files used to compile the application or that run within the software distribution.
Consider also that you need to identify the SBOM of each software component. There may be third-party and even fourth-party scripts or coding that go into the components of your direct digital supply chain partners.
Who Should Care About SBOMs?
SBOMs should be a shared concern among all software supply chain ecosystems. Making SBOMs transparent benefits all stakeholders. This includes software suppliers, software consumers, and the providers in between—such as API developers, open-source developers, security control managers, cloud service providers, and managed service providers.
You can monitor for software risks in your DevOps pipeline with a clear understanding of all the software components that make up your enterprise applications. You can also demonstrate the security posture of your software in cases where you need to integrate with a new business partner or are part of an acquisition. They will want to know if your software will put them at risk of a cyberattack.
When Regulations Force Actions
Other outside forces may also compel you to evaluate the contents of your software through the use of SBOMs. For example, in May of 2021, President Biden signed an executive order making SBOM a requirement for federal contractors.6
The requirement for SBOMs will likely also extend into guidelines or regulations in other countries.7 Consumers of software products need to be assured that the applications are secure and meet compliance requirements. That means allowing customers and their auditors under the hood to see exactly how an application is built.
How to Fold SBOM into Your Security Program
The “shift-left” to ensure your SBOM efforts are on target starts with thinking about what it takes to secure your supply chain. Identify all your suppliers and manage the risks they may bring to your applications.
This approach is similar to third-party risk management, requiring partners to follow secure development practices. With an SBOM to identify all the components, you can begin to identify and eliminate security gaps in your supply chain. And every time a new vulnerability appears, your InfoSec team will not need to spend as much time determining the impact on your applications.
For those operating in the federal space, the SBOM requirements for federal agencies provide solid guidelines to ensure your suppliers of software products and services conform with the NTIA’s The Minimum Elements For a Software Bill of Materials (SBOM).8 These include documenting baseline information about each component that should be tracked, and allowing for scaling across your software ecosystem by automatically generating human and machine-readable lists. Defining the preferred operational guidelines for SBOM requests, generation, and use is also a good idea.
Additional SBOM Resources
For help in developing and managing SBOMs for your enterprise applications, the Cybersecurity and Infrastructure Security Agency (CISA)9 and NTIA10 both offer a wide range of resources.
Those not operating in the federal space should still consider applying a model to benefit from the SBOM objectives. To this end, the Open Web Application Security Project (OWASP) has developed CycloneDX, a standard designed to help organizations with supply chain component analysis within relevant application security contexts.11
While compiling SBOMs may seem to add to the burdens your InfoSec and AppSec teams already face, they also offer a great way to inventory all the components of your application infrastructure. And once you know all those components, it’s easier to build the necessary security measures to protect them.
- 1. SBOM 101 – All the questions you were afraid to ask Software Bill of Materials, Sysdig, August 2022
- 2, 10. “Software Bill of Materials” (SBOM), NTIA, Accessed August 2022
- 3. SolarWinds Attack Cost Impacted Companies an Average of $12 Million, Heimdal, June 2021
- 4. Gartner Identifies Top Security and Risk Management Trends for 2022, Gartner, March 2022
- 5. Apache Log4j Vulnerability Guidance, CISA, Accessed August 2022
- 6. Executive Order on Improving the Nation’s Cybersecurity, The White House, May 2021
- 7. Bill of materials: devil’s in the software details, cybernews, March 2022
- 8. The Minimum Elements For a Software Bill of Materials (SBOM), NTIA, July 2021
- 9. “Software Bill of Materials” (SBOM), CISA, Accessed August 2022
- 11. OWASP CycloneDX Project, OWASP, Accessed August 2022
