By Kayly Lange June 12, 2023
Vendors have long used bills of materials to detail the pieces that make up their supply chain products. Software bill of materials (SBOM) is a similar but traditionally less critical development in IT. However, that is quickly changing: companies are concerned about the security of their purchases, especially as applications become more expensive and sophisticated.
The application became more widely known in May 2021 when the Biden administration emphasized SBOMs in an executive order as a way organizations can boost their cybersecurity. Because of the order, the U.S. government now requires all their software suppliers to provide SBOMs for their products.
As it becomes more common and mandated for federal contracts, it's wise for companies to move towards using SBOMs to keep track of components. They’re quickly becoming an essential requirement for many businesses and industries.
What is a Software Bill of Materials?
The software bill of materials (SBOM) lists all component parts and software dependencies used in application development and delivery. Similar to a bill of materials (BOM) for supply chain and manufacturing, it tracks most software packages' extensive third-party components.
Since the federal government mandated SBOMs for all software they use, they created a document in coordination with the National Telecommunications and Information Administration (NTIA) outlining the minimum elements that must be included. NTIA’s minimum components are split into three categories: data fields, automation support and practices & processes.
Data fields
SBOMs need to include all the vital data about software components. This includes names of the component, supplier, software version, and any other identifiers. Also, it needs to detail any relationships between dependencies. This enables companies to accurately identify and manage all software components across the software supply chain.
(Read our full explainer on supply chain attacks & detect them with Splunk.)
Automation support
The information in the SBOM is typically used both by multiple department within an organization and by multiple organizations.
To ensure the documentation is easily used and shared, SBOMs must be machine-readable and capable of automatic generation. This allows organizations to track all the data in the SBOM continuously. NTIA recognizes three delivery formats for compliance:
- Software Package Data Exchange (SPDX) is the primary format for an SBOM inventory list and includes software components, licenses, security references and copyrights.
- OWASP CycloneDX uses a lightweight SBOM standard to build a complete list of first- and third-party software components. It documents components such as applications, libraries, containers, files, firmware, operating systems and frameworks.
- The Standard for software identification (SWID) is an XML file created by the International Electrotechnical Commission (IEC) and International Organization for Standardization (ISO). The file contains a list of software components, as well as their patch statuses, installation bundles and licenses.
Practices and processes
The last element relates to the mechanics of the SBOM. Practices and Processes are the operational details that must be included in any contract that asks for them. The key requirements for the Practices and Processes section include:
Frequency. This should include how often your organization generates new SBOMs. NTIA recommends developing new SBOMs whenever you update a software component or release a new version. Also, you are expected to create a new SBOM if you find an error or learn a new detail about any component of your software that was not included in your initial documentation.
Depth. Your SBOM must include all top-level components and transitive dependencies to comply with NTIA standards. If you cannot include all transitive dependencies in your SBOM, the document must provide instructions on where your customer can find them. Also, you are required to specify why you cannot provide a complete dependency graph, such as because your component has no further dependencies.
Distribution. SBOMs need to be delivered quickly and easy to use. This requirement doesn’t specify how quickly SBOMs should be delivered, but they must be turned in quickly. Also, your SBOM needs to have access permission in place when delivered. Lastly, the requirement states that SBOMs can be either:
- Distributed with each product instance.
- Made available in an easily accessible manner, such as a website.
Access of Control. If you have to limit access to your SBOM to specific customers or users, it should specify access control terms. You need to offer allowances for customers that want to integrate SBOM data into their security tools.
Accommodation of Mistakes. While SBOMs improve software assurance and reduce software supply chain risk, they’re not perfect. Customers must be tolerant of occasional errors or unintentional omissions, while organizations must be diligent in fixing errors.
Benefits of using a Software Bill of Materials
As high-profile cyberattacks continue to grow, SBOMs are essential in helping organizations identify components and assess whether they need an update or patch. Knowing which components may be vulnerable is almost impossible.
All the features of a compliant SBOM work to provide enhanced cybersecurity. As modern attacks become more disruptive and expensive, organizations maintain integrity by using an SBOM to verify that all components and files it contains are the same ones that were intended.
With an SBOM, companies can find and eliminate vulnerabilities before production. Also, organizations with access to an SBOM can provide proactive vulnerability patching with deeper transparency.
Another benefit of SBOM is that they save time and money for software engineers. With the list of versions and components in one convenient place, they save time and deliver secure software. Developers can reduce code bloat by finding a suitable component, leading to a more streamlined codebase.
SBOMs also help improve licensing compliance by providing detailed information about the licenses associated with each software component and dependency. Organizations can then monitor the legal obligations of the components they use. It offers critical transparency and organization to manage software licenses, helping companies to better:
- Understand their legal obligation.
- Mitigate risks.
- Demonstrate compliance with licensing requirements.
Watch Ryan Kovar and Mick Baccio of the SURGe Security Research Team, explain the importance of SBOMs for software supply chain security:
Best Practices for creating & managing SBOMs
Some of the best ways that you can create a compliant and effective SBO include:
Perform regular updates
After creating an SBOM, it’s your responsibility to ensure it remains updated as components change. Bug fixes, code updates, and new features must be tracked across teams and in real-time to ensure your SBOM doesn’t become outdated.
Confirm data integrity
Audit everything in your SBOM to ensure the integrity of the information, including version numbers and licenses.
Flag potential issues
Your SBOM should outline the current state of your application and how your customers can properly secure it. Issues you could discuss include:
- Copyleft licenses
- Known vulnerabilities
- Limitations or bugs in software components
Identify SBOM documents
Your software can have several SBOM documents, so it’s critical that you identify each of them.
For example, you may issue an updated SBOM to correct an error or publicize a new component. Clearly list the latest version so your customers have the most complete, accurate, and up-to-date information about your software.
Leverage the Software Bill of Materials for the Digital Age
SBOMs are critical for modern organizations and offer multiple benefits for compliance, security, and monitoring each license agreement's components. Providing your customers with valuable component information will help them fix any potential cybersecurity issues before incurring damage.
What is Splunk?
This posting does not necessarily represent Splunk's position, strategies or opinion.