What is a Software Bill of Materials?
Just like you’d find all the ingredients on a package of food, a Software Bill of Materials is a list of all the components contained in a software product. Vendors typically create these bills to describe what the components are. In addition, a Software Bill of Materials also includes information about these components’ dependencies and their hierarchical relationships.
Software Bill of Materials (SBOMs) are comprehensive and contain details on every third-party component with version and license information and commit or version control information for any custom code deployed through code management tools.
Software Bill of Materials may include open source or proprietary software and can be made widely available or have their access restricted. SBOMs should also include baseline attributes with the ability to uniquely identify individual components in a standard data format, like the example below.
Conceptual SBOM tree with upstream relationship assertions (Image Credit: NTIA)
A software development team is ideally positioned to be the creator and maintainer of the Software Bill of Materials for its software because modern engineering practice dictates that engineering teams maintain and understand the modules used in their code.
Software Bill of Materials considerations
After an SBOM is developed, it needs to be maintained and updated whenever a change is made to any application component. This includes code updates, vulnerability patches, new features, and any other modifications. These changes can happen at any time by any number of teams, and they need to be tracked in real-time for the SBOM to be effective.
Information integrity is key so everything included in an SBOM should be auditable, including all version numbers and licenses. They need to come from a reputable source and be verifiable by a third party.
When an SBOM is reviewed, it should provide a clear picture of an application’s current state as well as insight into what’s required to secure it properly. In addition to all of the files and components that exist, the SBOM should also show what’s in use, along with any issues that require immediate attention. Issues range from licenses being misused to critical vulnerabilities that require immediate attention. It’s not enough to just compile this information; improving cybersecurity is another important goal.
All SBOM documents should be identified because there could be more than one version of the SBOM document for the same version of a software. For example, a newer version of the SBOM may be created to correct erroneous information in an older version of the SBOM document. The latest version is assumed to have the most accurate and complete information about the software.
Software Bill of Materials example
GitHub offers an example of CydoneDX Software Bill of Materials documents created from various open source projects.
Software Bill of Materials myths vs. facts
One myth about a SBOM is that it’s a roadmap to an attacker. What is true is that attackers can utilize the information contained in an SBOM. However, SBOMs seek to level the playing field by providing additional enterprise-scale transparency — and the benefits outweigh the concerns.
Another myth is that an SBOM alone doesn’t provide any useful or actionable information. However, there are a number of use cases that illustrate its usefulness, including the ability to reduce unplanned, unscheduled work by offering better visibility into the broader code base. An SBOM also enables an organization to know and comply with the license obligations of the components used.
A third myth is that an SBOM needs to be made public. This is not the case. Creating an SBOM is separate from sharing it with people who can use this data for constructive purposes.
Software Bill of Materials Executive Order
The Executive Order on Improving the Nation’s Cybersecurity directs the Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), to publish the minimum elements for a Software Bill of Materials (SBOM).
The Executive Order on Improving the Nation’s Cybersecurity also makes it clear that making an SBOM publicly available is a choice, not a requirement.
Software Bill of Materials tools
If something isn’t included in an SBOM it should not be running in production, and any discrepancies should send up a red flag that an application is compromised. The SBOM should be linked to an automated process or tool for verifying the origin of every component and alert the appropriate teams if an unauthorized file or change is detected.
Some tools generate a bill of materials for open source software but not for custom-developed code; others may disregard the underlying application infrastructure entirely.
There are software analysis tools available to scan the software to identify the included components. Software composition analysis (SCA) and binary composition analysis tools have several advantages. The biggest is that they can audit software without any input from an engineering team (or from a supplier in the case of a consumer). Many tools will generate SBOMs in standard formats and automatically feed configuration and asset databases.
Finally, many tools cross-reference a variety of security databases to correlate known vulnerabilities with components.
There are also significant disadvantages. All the tools rely on proprietary databases and code fingerprints that may be incomplete or outdated. That means they may not properly identify every included component. A limitation of source code tools is that software source code files may not be available.
Another disadvantage is that SCA may produce false positives by identifying software components or dependencies that were not included or used in the development of the software. The biggest disadvantage may be that the SBOM program will not be supported as a part of development so it might not have definitive information.
Software Bill of Materials – NIST
NIST has developed a set of guidelines for technologists to adhere to so that security is baked into every step of the Software Development Life Cycle (SDLC). Regardless of the SDLC used, the guidelines will reduce the number of vulnerabilities in released software, they will mitigate the potential impact of exploited, undetected or unaddressed vulnerabilities, and to address the root cause of these vulnerabilities to prevent future recurrences.
Software Bill of Materials – FDA
The FDA has issued recommendations for premarket submissions for medical devices regarding design, labeling, and documentation to help ensure they are sufficiently resilient to cyberattacks.
Software Bill of Materials final thoughts
Ideally, every software manufacturer would produce SBOM for their software components. However, the SBOM concepts and information are still evolving and SBOMs are not available for many software components, nor is tooling always available to open source projects so that they can provide these bills. In case of a missing SBOM for upstream software, it is incumbent upon the downstream or end-product manufacturer to create SBOM content based on available information of the upstream software components. This may lead to incomplete information in the final version of an SBOM.
SBOMs that can be shared without friction between teams and companies are a core software management best practice for critical industries and digital infrastructure.
Further, while today’s SBOMs are not dynamic because they are static documents and do not automatically incorporate updates, the SBOMs of the future will be dynamic. They will eventually become a requirement, especially in organizations that create and update software products regularly.
Future SBOMs will also be integrated into a product’s security lifecycle and be produced automatically at predefined stages. They will also be interoperable, which will lead to greater adoption.
