If there’s anything we have learned from some of the major software supply chain attacks of the past few years such as the SolarWinds and Log4Shell attack, it’s that these sorts of attacks can be quite devastating. But in today’s interconnected digital world, it is becoming increasingly difficult for companies to avoid them.
No one is immune to software supply chain attacks. What makes these even worse is that breaching a single company will potentially expose thousands of companies on their software supply chain to attacks. The implication of this is that it isn’t enough to safeguard your own internal systems; one of the ways your organization can proactively reduce supply chain risks and mitigate against attacks is to adopt a concept known as the Software Bill of Materials (SBOM).
Your organization most likely relies on various external systems to run various aspects of your daily operations. However, you probably have no visibility into the risks that these external systems pose unless the provider discloses it. The SBOM acts as a comprehensive ingredient list that provides insights into what makes up the software components you use. This document has become a key component for managing supply chain attack risks.
What is the function of SBOM in supply chain risk management?
In order to fully understand the potential and reduce risks of the third-party software you use, you need to know its composition. The Software Bill of Materials (SBOM) provides full transparency, thereby giving you better control over the security of your internal systems.
A Software Bill of Materials is a list of the components, services, and third-party dependencies in a piece of software or application. The concept of BOM is not a new one, but only recently it has found application in the software world. The root of this concept can be traced to the manufacturing industry where manufacturers typically use parts from different vendors to build a product. In order to track the product’s history and ease future maintenance, a Bill of Material is produced that details all the components and where each one came from.
SBOMs became popularized more recently after the 2020 Solarwinds attack that affected many US government agencies. In response to this, President Biden issued an executive order which mandated federal agencies to request SBOM from software developers and the vendors they partner with. While it does not prevent a supply chain attack, an accurate SBOM will reveal all the dependencies within a software product. This makes it a valuable cybersecurity tool that ensures transparency and exposes vulnerabilities in the supply chain, thus enabling the reduction of supply chain risks.
Why SBOM is critical for developers who rely on open-source code
Reusing third-party or open-source code is an integral part of the modern software development process. While developers still need to write their own code, they routinely integrate third-party open-source components into their software. Doing this has become quite necessary to keep projects moving at a high pace.
In the past, the only reason organizations and developers that use open-source software wanted to know about its components was to avoid licensing issues. Many open-source software included components with restricted use and distribution, and anyone who wanted to make use of them needed to be aware of these limitations. Now, however, developers are starting to recognize that the risk of using open-source software goes beyond licensing; it could raise security concerns as well. A Bill of Materials is integral to understanding both the licensing and security requirements of open-source software.
For developers, a Software Bill of Materials offers better visibility into the codebase of the open-source software they’re using. This can help save time and effort in a lot of instances. For example, if a new vulnerability is discovered. Without a Bill of Materials, developers will have to review every piece of software to identify the cause of the problem. For complex projects, this is a grueling and time-consuming task. Using an SBOM, the software containing the vulnerability can be identified easily and the required bug fix will be carried out immediately. Other reasons why SBOM is critical in software development:
-
Reduce code bloat—For every open-source code you use, there are probably dozens of slightly different alternatives that perform similar functions. With an SBOM, you can reduce redundancies by creating a standard list of components for your system. Also, since each component you use will have its own unique defects or vulnerabilities, keeping your code streamlined to just what’s needed can make it easier to track and correct vulnerabilities.
-
Comply with the license obligations—We’ve mentioned how licensing is one of the major motivations for trying to know all the components of your software. Getting the SBOM will ensure that you’re complying with all licensing obligations on the components you choose to use.
-
Proactively evaluate and remediate risks—Identifying and remediating newly identified risks can be difficult and time-consuming. However, with a clearly outlined list of components, you can proactively start looking for vulnerabilities and fixing them. This shortens the window to identifying issues and makes the process more efficient.
-
It makes testing and code reviews easier—Before any software is rolled out, it has to be extensively tested and reviewed. This process is easier when the developer has a clear understanding of all the components and sub-components of that software. The SBOM can help cut review time drastically, allowing you to get your code into production faster than you would have done without the document.
Using the SBOM, you can start security testing to detect and avoid harmful components in the early stages while your code is still being written. The document also provides deeper context to third-party codes and their components, reducing the work and time needed to review and even make changes to the code base.
-
Identify end-of-life (EOL) software—This is a fairly common phenomenon with open-source software. Sometimes these components reach the end of their life because the supplier, far up on the supply chain, no longer supports the product. While it still works, unsupported open-source software are major nodes through which vulnerabilities can be exploited. The SBOM makes it possible to monitor EOL software and take proactive steps to replace it when possible.
SBOM use cases and benefits
Getting a Software Bill of Materials (SBOM) is not mandatory for every software you develop. However, preparing it is fast becoming a best practice that every digital product developer needs to look into. The following are a few SBOM use cases where this document would be very valuable.
SBOM Use Cases
Complying with federal requirements
Following the major software supply chain attacks of 2020 and 2021, President Biden issued an executive order that outlines major recommendations for agencies and vendors that supply software solutions for the government. One of the requirements included in the executive order was the proposal to include SBOMs for every software to be used by the federal government. While SBOMs are not compulsory for everyone, all organizations that provide software for the US federal government would need to provide SBOMs that detail all the components they use and any version changes they make.
Reducing risk for software consumers
An SBOM produces full visibility into the third-party components of a software tool. Tracking all the components and sub-components of a software is one of the ways organizations can verify the security and compliance standards of any software solution they intend to use or already use.
Consumers who use software without a Bill of Materials are probably aware that there are open source components in the code they’re getting from a supplier. However, since these ingredients are not known, consumers may not be aware of potential malicious code, unsupported components, and other vulnerabilities in the software.
Quick response to crisis situations
Using an SBOM offers visibility into the software codebase. Ultimately, this makes it easier for developers to respond to crises if they do occur. For instance, without an SBOM, a software engineering team trying to deal with a new vulnerability will have to manually review every piece of software they use to determine the problem. However, if a Bill of Materials is available, it’s easier to narrow down the software that may contain the vulnerability and carry out the required fixes within a very short time. This helps save time in crisis resolution and minimizes the damage that could have happened.
Information asymmetry problems
There’s currently an information asymmetry problem in the software market. By keeping the full information about their app security a secret, software vendors or producers are not being held accountable for the quality of their software. SBOM makes information about a product’s security available to software customers. This forces producers to comply with the best security standards in software development.
Supporting mergers and acquisitions
A Software Bill of Materials is one of the documents that may be required for acquiring a company. Parts of the process of a business acquisition involve due diligence to assess the potential risks of the purchase. SBOMs provide deep insights into the security framework run by the company and the potential risk of the acquisition.
Benefits of SBOMs
One of the most important security practices of the modern organization is accessing software supply chain risks. This involves knowing whether an organization’s software stack includes third-party constituents that may constitute a supply chain risk. These software vulnerabilities are often found in components that depend on other software applications. This is why the Software Bill of Materials is an important component of a product security framework. Below are some of the most important benefits of SBOM.
- Deal with vulnerabilities proactively—The ultimate benefit of an SBOM is to vet the security framework of the software an organization uses, identify vulnerabilities and find ways to eliminate them proactively. Doing this helps organizations reduce supply chain risks.
- Improve the process of managing security crises—Creating an SBOM does not remove system vulnerabilities or prevent software supply chain attacks entirely. However, it reduces supply chain risks and can improve the process of managing crises when they do occur. Having a list of all the dependencies that may serve as the potential point of vulnerability in a software application simplifies the process of managing risks.
- Reduce costs—One of the consequences of handling security risks by leveraging SBOMs is that it reduces cost in the long run. The process of manually parsing code to locate vulnerabilities can be quite costly. The Software Bill of Materials provides visibility to the software underlying libraries. This helps save time and reduce the cost of the security assessment.
Conclusion
In every software organization that’s serious about its reputation, creating a comprehensive SBOM that is continuously updated with data is one of the key ways to forestall the impacts of a software supply chain attack. Since using third-party software is practically inevitable in building software products, having a comprehensive ingredient list of all the components you use will make it significantly easier to narrow down issues and resolve them more effectively. It also makes it easier to comply with software licensing issues and even, in some cases, with government regulations.