Why an SBOM is Vital to Application Security and Compliance

Attacks targeting the software supply chain are on the rise. Indeed, data from the Mend Open Source Risk Report shows a steady quarterly increase in the number of malicious packages published in 2022, with a significant jump in Q3, which jumped 79 percent from Q2. The European Cybersecurity Agency (ENISA) predicts that supply chain attacks will increase fourfold by 2022.

The devastating vulnerabilities found in Log4j — and other serious software supply chain breaches, like SolarWinds, Kaseya and Codecov — clearly illustrate the gravity of the situation. Governments are taking notice, and many are issuing guidelines and legislation requiring organizations to reinforce the security of their software supply chains.

The United States is a case in point. In 2021, the White House issued Executive Order (EO) 14028, entitled “Improving the Nation’s Cybersecurity,” aimed at boosting the security and integrity of the software supply chain. In 2022, the Executive Office of the President of the United States issued a further memorandum for the heads of U.S. government and federal executive departments and agencies, which doubled down on the executive order to reinforce the security of the software supply chain through secure software and application development practices.

To this end, the Cybersecurity & Infrastructure Security Agency (CISA) in the United States has pointed to the software bill of materials (SBOM) as a way to simplify remediation of similar vulnerabilities in the future. 

In light of this, here’s an overview of SBOMs — what they are, how to obtain them, and how to effectively generate and audit an SBOM.

What Is a SBOM?

An SBOM is a formal, machine-readable description of the many open source and proprietary software components that make up a piece of software. It provides a structured approach to achieving supply chain security by giving those who create, buy, and operate software the necessary information to track supply chain relationships. It increases the transparency into your software components and ensures your products perform securely and as intended. 

The idea of SBOM comes from the bill of materials (BOM) used in traditional manufacturing, which lists the raw materials and other components required to produce an end product. If anomalies are detected in any aspect of the manufacturing process, a BOM makes it easy to locate and fix issues.

Why are SBOMs important?

SBOMs give developers, DevOps teams, security specialists, and others visibility into the code base and sources of your organization’s software and security. This provides visibility into the components and dependencies in your software, which provides a couple of key benefits. 

Firstly, SBOMs help you know what you’re using in your code base. This knowledge is essential for security, because it can help identify which components need to be updated or patched. Without SBOMs, you might not know which components are vulnerable to attack, you don’t know whether versions of components or dependencies have been updated — and therefore what is new, anomalous or what bears a threat to your security. In short, you can’t detect and fix vulnerabilities if you don’t know what’s there in the first place. SBOMs give you that visibility.

Secondly, SBOMs help customers and buyers assess the risk of using, installing, or integrating a product. Increasingly, purchasing organizations, particularly in the public sector, demand that vendors provide SBOMs. This increases the robustness of software security and minimizes the possibility that purchasers are unknowingly breaching any software usage licenses, which could expose them to legal and financial issues. 

SBOM users can determine whether their software is vulnerable to previously disclosed security vulnerabilities. By using SBOMs, developers can identify which components or dependencies could be vulnerable to attacks during development and deployment.

The SBOM also improves efficiency by combining open source and third-party software and helps you see if you are meeting compliance standards and following software usage policies. Using SBOMs to share infrastructure and data could save firms time and money by facilitating more collaboration between departments, and by identifying weak portions early in the software development life cycle (SDLC).

What are some key SBOM benefits?

Let’s talk about some main benefits of creating and auditing a software bill of materials. 

1. Reduces Supply Chain Risks

The software supply chain comprises each non-organic component that goes into the production of a piece of software. It includes pre-built libraries, open source packages, and other third-party resources used to expedite development and improve software quality.

Malicious actors usually implant dangerous code in third-party packages. And when an unsuspecting user installs the infected package, their system gets compromised, leading to a supply chain attack. 

A major advantage of a software bill of materials is that it increases transparency into the various supply chain components. This enhanced visibility lets software producers, purchasers, and operators better identify and address vulnerabilities.

2. Increases Consumer Confidence

An SBOM is just like a list of ingredients on a food packet; consumers usually consult the labels before making a purchase decision. Similarly, software buyers can consult an SBOM to perform vulnerability analysis and determine the suitability of the product. 

Consumer confidence is particularly important in today’s software industry where attackers like targeting open source components to infiltrate the software supply chain. With the massive use of open source codebases in software development projects — from 36% in 2015 to 90% in 2022 — they offer a lucrative opportunity for attackers to inject vulnerabilities and compromise the supply chain. 

Creating an SBOM is a proactive approach to understanding the supply chain and ensuring its various components, including open source codebases, are safeguarded from attacks. This increases the buyers’ confidence in consuming the software.

Additionally, an SBOM can be pivotal when an organization is conducting due diligence for merger and acquisition purposes. An SBOM can simplify the auditing process, provide transparency into an organization’s technical proficiency, and build trust with prospects. 

3. Supports Regulatory Compliance

The recent escalation of supply chain attacks, such as the widely publicized SolarWinds attack in late 2020, has ignited a regulatory response from the government. In May 2021, the Biden administration issued an executive order that aimed to improve the US’s cybersecurity defenses. 

The order sets out new security requirements for any software sold to the Federal Government. One such strict requirement is that vendors should include an SBOM to maintain greater transparency into their software and prevent supply chain attacks. 

Given the buying power of the Federal Government, the rest of the software development industry is likely to follow suit and require SBOMs for all critical software. 

Traditional methods of generating SBOMs

The traditional methods of creating a software bill of materials come with several challenges that complicate effective SBOM management. They often introduce several risks and issues that increase the possibility of getting attacked. 

For example, some organizations generate and manage SBOMs manually using spreadsheets or emails. Such methods often lead to several challenges, including the following:

• Managing SBOMs traditionally leads to scaling challenges, especially when an organization gets more supply chain partners, introduces new products, or experiences growth. 
• Using a spreadsheet-based SBOM complicates the tracking of the hierarchical relationships between different software parts. Worse still, if an SBOM document is modified and shared with multiple people, it complicates identifying the latest revised file.
• Looking for information in a spreadsheet bill of material is tedious and slow, especially if two or more products have some components in common. Even if your organization has a spreadsheet-formula guru, digging into SBOMs does not amount to productive work.

Additionally, some organizations use traditional tools to create and manage SBOMs. That’s another way of doing SBOM incorrectly, and it often leads to several problems, including the following:

• Many tools are not suited for managing SBOMs. For example, they disclose vulnerabilities without giving a clear path of addressing them, they cover only a specific set of programming languages or package managers that leads to incomplete SBOMs, and produce high false-positive rates that misdiagnose libraries and dependencies. Such incompetency exposes organizations to greater risks. 
• Many tools cannot generate SBOMs automatically in a machine-readable format. They cannot also scale to meet emerging software development needs. Such issues often slow down the release process and hurt the organization’s bottom line. 

What’s in an SBOM?

The basis of an SBOM is an inventory of the source components and dependencies in a piece of software or application, including items like dynamic link libraries (DLLs), that applications use to operate, middleware, and programming frameworks on which an application operates.

An SBOM should also provide information about where each component comes from. And. As components and pieces of code are often dependent on others, an SBOM should include a dependency tree so users can see what the core components of an application are.

In July 2021, the United States National Telecommunications and Information Administration (NTIA) issued guidance on what should be the minimum elements in an SBOM. This guidance highlighted three essential things: 

1. Data fields. The fundamental information about each component, such as: supplier details, component name, which version of the component, license information, relationship with dependencies, who authored the SBOM data and the timestamp of when SBOM data was generated. When these elements are broken down into their constituent parts, they can be identified as:
   • Open source licenses. Which components are open source? What type of license do they allow use and reproduction — copyleft or permissive? What terms and conditions (T&Cs) of use should you be aware of when using them, and what T&Cs should subsequent users of your software and applications understand?
   • Compliance. You SBOM should identify whether your current components are being used and reproduced in line with their license terms and conditions.
   • Dependencies. A comprehensive list of all the dependencies attached to every component of a piece of software or an application. Important for compliance purposes and to ensure awareness of potentially problematic or vulnerable dependencies and version updates.
   • Open source components. As open source components are almost ubiquitous in modern software and applications, they are a popular attack vector. As such, it is important that SBOMs can identify them so that it’s clear when they are anomalous or are compromised in some way.
   • Open source versions. Updates happen frequently. Many improve the robustness and operational capabilities of software. Some do the opposite and can compromise the code. SBOMs should identify and indicate whenever a new version of code, a component or a dependency has been introduced, and whether it is fit for use by being secure and compliant with usage policies.
   • Open source vulnerabilities. Where vulnerabilities exist, an SBOM should identify them. The impact of vulnerabilities can vary from none to considerable, depending on the context in which an open source item is used and its interaction with other components and dependencies. Therefore, it’s important for developers and users to know what’s there so they can make an informed judgment on whether to use or avoid it.
   • Automatically update components. Modern software development processes can be so complex that manually updating components and dependencies within an SBOM is inadvisable. So, the NTIA recommends a minimum level of automation for SBOM generation and data transfer.
   • Remediation. Ideally, remediation of vulnerabilities, preferably automatic, would be included to ease and expedite the reinforcement of components and dependencies identified in an SBOM.
2. Automated support. Automated detection and identification of components, dependencies, and vulnerabilities dramatically reduce the burden on DevOps and security teams to keep on top of version generation. Furthermore, automation makes it easier for other systems to understand and make use of SBOM data across the software ecosystem. This requires standardization of data formats for SBOMs, including the main formats, SPDX and Cyclone DX, and Software Identification (SWID) tags.
3. Practices and processes. The right processes must be in place in an SBOM to help enable the ongoing collection of data, plus a definition for how each SBOM is generated and accessed. This involves defining the operation of SBOM requests, generation and use, including frequency, depth, known unknowns, distribution and delivery, access control and accommodation of mistakes.

Best practices for generating and auditing SBOMs

Generating and auditing SBOMs require a modern approach that can help you surmount the challenges of mitigating supply chain risks. 

Here are some best practices for managing software bill of materials:

• Use a tool that supports automation. The Biden executive order requires software inventories to be automatically generated in a machine-readable format. If you use a tool that does not support full automation, you will not meet the requirements. You can also create loopholes for attackers to harm your supply chain.
• Use a tool that supports continuous remediation. You need a tool that continuously discovers and addresses supply chain risks. It should assist you in avoiding harmful components at the sourcing stage and continuously alert you when any anomaly is detected during development or production. It should also be capable of identifying risks in downstream components in case an upstream component is infected. 
• Use a tool that covers all aspects of an SBOM. You need a comprehensive tool that provides an up-to-date and accurate inventory of your supply chain components. An end-to-end tool will cover all the technology stacks and programming languages used in your organization. Otherwise, you may generate SBOMs that do not paint the correct picture of your software inventories.
• Use a tool that makes your life easy. You need a versatile tool that will point out how to address the identified risks, scale comfortably across your software ecosystem, and produce low false-positive rates. With a good tool, you’ll not need to stop and research how to fix a vulnerability or get insufficient SBOM reports, which can affect the quality of the released software.

How Mend SBOM can help

Mend SBOM is a modern, remediation-centric tool that can help you implement SBOMs and ward off supply chain attacks. It focuses on the open source components of your supply chain and provides deep inspection that allows you to identify vulnerabilities in your applications.

With Mend SBOM, you can swiftly and easily produce a software bill of materials that reveals all open source libraries, tracks and documents direct and transitive dependencies, and automatically updates whenever a change is detected in any component. If it discovers a vulnerability, the tool recommends a safe remediation path that ensures no breakages to the build. 

It’s the tool you need to automatically generate accurate and comprehensive SBOMs and take your application security to the next level. 

FAQs

Why should you use a Software Bill of Materials?

An SBOM should be used as part of any comprehensive software and application security strategy, as you seek to safeguard your code. It should also be used as part of any response to RFPs to demonstrate robust compliance and security. In increasing cases and contexts, potential purchasers make it a prerequisite for vendors to supply an SBOM. Typical use cases for SBOMS are:

• Vulnerability remediation. SBOMs enable you to check for and identify vulnerabilities in your applications and software. When notified about a vulnerability, you can use the SBOM to find all instances of the affected software and patch the problem.
• Regulatory compliance. Governmental, public sector organizations and heavily regulated industries like healthcare and finance may require vendors to demonstrate that they deliver secure products. Often they require an SBOM as a part of the purchasing process.
• Merger and acquisition due diligence. An SBOM helps demonstrate that a potential acquisition is sound both in terms of its capabilities and its compliance.

Who needs an SBOM?

Any organization that uses or develops, produces, purchases, or operates software and applications will benefit from an SBOM.

Is SBOM mandatory?

Increasingly, yes. Based on the guidelines of the White House Executive Order (EO) 14028, U.S. agencies will be required to obtain from their software producers SBOMs and documented processes to validate code integrity. Other governmental and legislative bodies are following suit internationally in efforts to secure the software supply chain, also industries handling sensitive data, like healthcare and finance, and any companies conducting M&A activity, or those trading as public companies.

What is the difference between an SBOM and CBOM?

An SBOM focuses on all of the software components (including open source components) in the codebase, as well as components, dependencies versions, patch status, and licenses. A Cybersecurity Bill of Materials (CBOM) also includes a hardware bill of materials together with an SBOM.

Learn how SBOMs can go beyond compliance

Read the report