Even though Software Bills of Materials (SBOMs) have been around for about 10 years, they have recently gained a lot of buzz in the software industry. This blog explores why everyone is suddenly so interested in SBOMs, what an SBOM is, and why you should adopt this technology.
This is the first blog in a two-part series. The second blog in this series – Making Sense of SBOMs: The Minimum Requirements – provides an in-depth look at the minimum requirements for SBOMs for organizations wishing to do business with the US federal government.
Why Are SBOMs in the News?
In May 2021, The White House released an Executive Order on Improving the Nation’s Cybersecurity. Executive order 14028 was largely a response to the SolarWinds software supply chain attack that targeted several US federal agencies. In the executive order, the US federal government stated, “The prevention, detection, assessment, and remediation of cyber incidents is a top priority and essential to national and economic security.” The government called for a partnership between the public and private sectors to increase transparency across the software supply chain in an effort to prevent similar attacks.
One of the key outcomes of Executive Order 14028 is the mandate that software companies wishing to sell to the US federal government must deliver a Software Bill of Materials (SBOM) for each product. When the US federal government makes a mandate such as this, it tends to have a trickle down effect until it becomes the de facto industry standard. This is because anyone selling to the government needs to provide an SBOM. Likewise, anyone selling to a company selling to the government must provide an SBOM. And again, anyone selling to a company selling to a company that sells to the US federal government must have an SBOM. You get the idea. Suddenly everyone must have an SBOM.
As a result of this mandate, the market has seen renewed interest in SBOMs. Unfortunately, standards and best practices around SBOM creation and ingestion are still developing as organizations struggle with the best way to use this technology for the highest impact.
What Is an SBOM?
An SBOM is a formal record containing the details and supply chain relationships of the various components used in building a software application. This includes all open source and third-party dependencies, including direct and transitive dependencies. In addition, SBOMs detail information about each component such as its name, version number, vendor, license type, and supply chain relationship. An SBOM is typically used by organizations to manage and track the components that make up their software applications, with the goal of improving software security and compliance.
In the past, software development teams often worked in isolation, resulting in limited visibility into the components used in their application. With the rise of open source software, the complexity of software systems has increased. This increased complexity makes it difficult for organizations to keep track of all the components used in their codebases. An SBOM provides a single source of truth for all components that comprise an application, making it easier for organizations to manage and track these components.
SBOMs Are Like a List of Ingredients for Your Software
One of the most common analogies you hear is that SBOMs are like a list of ingredients for your software. Much like your favorite lemon ginger scone mix provides a list of everything it contains so you can make an assessment of whether it’s safe to consume, an SBOM provides a list of everything in a software application so you can make an assessment of whether it’s secure. Let’s dive a little deeper into this analogy.
Figure 1 shows that our lemon ginger scones are made up of atomic parts (ingredients that you can’t break down further) and compound parts (ingredients that are made from a combination of two or more other ingredients). King Arthur Baking assembles these parts and compound parts into a product – our delightful lemon ginger scones – and then distributes it to various grocery stores where the scones are then sold to the ultimate consumer, the grocery store customer.
Figure 1. SBOMs Are Like a List of Ingredients for Software
Though the above image outlines the basics of the supply chain relationship of our lemon ginger scones, it still doesn’t provide full transparency. The grocery store is highly concerned about the health of its customers, including possible food allergies. In fact, the Food and Drug Administration (FDA), a US federal agency, mandates that the top nine major food allergens be specifically identified on nutrition labels. This requires greater transparency into all the components that make up our delicious lemon ginger scones.
Figure 2 further breaks down all compound parts into their atomic parts. Based on this new, more detailed information, we now understand that lemon drops contain milk as one of its ingredients. This means that a customer with a severe milk allergy is able to make a better assessment of whether the scones are safe for their consumption. (Hint: they are not!) The upside of this greater transparency is that the customer was able to make a risk assessment that prevented them from going into anaphylactic shock, which not only protected the consumer, but also the grocery store and King Arthur Baking. It’s a win-win-win for everyone.
Figure 2. SBOMs Help Identify Risk in the Supply Chain
What Lemon Ginger Scones Teach Us About Software Supply Chain Security
So what do lemon ginger scones have to do with software? Like the traditional supply chain used to create our tangy scones, software suppliers inherit all the upstream parts of their open source and third party components. Understanding what’s in these upstream parts in very fine detail is essential to building a secure application. For example, an SBOM should list all direct open source dependencies plus related transitive dependencies, including the relationships between the two. An SBOM that details all the dependencies and transitive dependencies that make up an application increases transparency. When a vulnerability is disclosed, the SBOM helps you quickly understand whether you are impacted and at risk.
Open source dependencies make up 80-90% of modern codebases. Developers spend less time writing code and more time assembling open source and third-party components. Because of this, the ability to understand what’s in your code is more important than ever before. SBOMs give you that visibility.
SBOMs are a comprehensive list of all the components that make up your software product. They provide you with a centralized and organized overview of your software supply chain, helping to identify and manage risks, comply with regulations and standards, and optimize software development and deployment processes.
Why Should You Use SBOMs?
You should adopt the use of SBOMs as a best practice for your business for a number of reasons. SBOMs help you better produce, choose, and operate software. They provide for greater transparency into both the solutions you produce and the solutions you use. The following are some of the main use cases for SBOMs:
- Selling to the US Federal Government. First and foremost, if you want to sell to the US federal government – or sell to a company that sells to the US federal government – you must provide an SBOM as part of that transaction. The US federal government believes that requiring an SBOM will lead to greater transparency and help curb the current rash of software supply chain attacks.
- Open Source and Third-Party Security. An SBOM can be used to monitor software for known security vulnerabilities. By keeping track of all the components and dependencies used in your application, you can identify any vulnerabilities and take steps to address them. When new exploits like Log4J are disclosed, an SBOM allows you to quickly identify whether the vulnerability is in your codebase and needs to be remediated.
- License Compliance. Open source is free as in “free speech” not free as in “free beer.” As such, open source components each operate under an open source license, which may or may not limit your ability to create and sell derivative work. SBOMs help identify which open source licenses are in your codebase. This data can be used to determine whether your licenses are compliant with your internal policies and help protect your intellectual property. SBOMs can also help you remain compliant with license obligations of all components used.
- M&A Due Diligence. SBOMs are often used as part of the merger and acquisition due diligence process to provide visibility into the software and solutions that are being purchased. Using an SBOM gives insight into the security of the solution and can help protect intellectual property by identifying any restrictive open source licenses.
- Open Source Component Management. One of the best practices to secure your software is to keep your dependencies up to date. Furthermore, with time, every component reaches the end of its useful life. SBOMs help you proactively identify components that have reached their end of life and need to be cycled out as well as help you find alternative solutions.
- Compliance and Reporting Mandates. SBOMs can help organizations better support compliance and reporting requirements by providing a highly detailed asset inventory. SBOMs can be used to help monitor for security risks of deployed systems and to follow up on security alerts to demonstrate vigilance.
- Export/Import Controls. SBOM data can be used to build allowlists or denylists of open source and third-party components that are approved or disapproved within your organization.
Learn More About SBOMs
Though SBOMs have a wide range of use cases, they will be most helpful once they gain universal adoption. Currently, SBOM standards and requirements are still developing. Achieving full participation will take some time due to the large number of tools and standards that are now just emerging.
For a deep dive on the baseline requirements for SBOMs as defined by the US federal government, please read the second blog in this two-part series, “Making Sense of SBOMs: The Minimum Requirements.”
About Cycode
Want to learn more about how Cycode provides visibility, security, and integrity across all phases of the SDLC? Schedule a demo today!
