A robust SBOM provides visibility into software and embedded devices, supports license compliance and security initiatives, and allows software suppliers to comply with industry regulations and best practices. This helps provide transparency into the composition and associated legal and security risks for your applications and allows your customers to be more informed about the inputs into their software supply chain.
The 2021 Executive Order on Improving the Nation’s Cybersecurity—which mandated that any software supplier selling to the federal government must provide an SBOM, corresponding security reports, and an attestation to the trustworthiness of the data—drove an industry-wide focus on the creation and maintenance of SBOMs. A September 2022 memo from the Office of Management and Budget included deadlines for collecting attestations (assurances of best practices): June 11, 2023, for critical software and September 14, 2023, for all software. Capping these benchmarks, the National Cybersecurity Strategy, announced by the Biden administration on March 2, 2023, directs software providers to be more responsible and potentially liable for the software they create. The strategy promotes SBOMs to “further incentivize the adoption of secure software development practices.”
Creating and managing an SBOM can be a straightforward process, even in today’s increasingly complex computing environments. Here are five tips for moving forward.
1 Start now.
If you haven’t created an SBOM yet, that’s ok. But delaying isn’t. If you’ve started, now’s the time to refine your process for your entire portfolio and work toward increased automation and continuous refinement.
Set up your SBOM management to be part of a proactive, ongoing software composition analysis (SCA) program.Creating an SBOM for each product should be part of a comprehensive approach to managing all open source software (OSS), third-party, and commercial components; the associated licenses; and addressing security vulnerabilities.
Don’t try to boil the ocean. Adopt a phased approach and improve over time. Start by reviewing all top-level components used in your applications. Then move on to direct dependencies and then on to transitive dependencies. Finally, look at embedded items, such as statically compiled code and/or code fragments. The level of detail required in your SBOM will be driven by your customers and the industries you serve.
Educate your teams about your initiatives. Curricula at many top computer science programs don’t include best practices for open-source usage; companies must take on the responsibility of educating their teams on these topics. An Open Source Program Office (OSPO) can help operationalize your strategy, delivering policies around open source adoption, use, support, and software development.
2 Identify your role in the software supply chain.
Issues related to license and/or security compliance can impact the entire software supply chain. Your organization must know its role in order to mitigate any issues—incoming from your upstream suppliers or that you may transmit downstream (to your direct customers or to your customers’ customers).
Understanding your place within the supply chain will help you identify what compliance artifacts your partners will require of you and the level of detail that must be included in your SBOMs. Don’t forget about third-party and commercial elements in your applications. Ingestion of third-party SBOMs to cover those items may be necessary, as you likely do not have control over those codebases and may have to rely on an upstream vendor’s SBOMs for that information. The right technology can track all the components in your software, regardless of where in the supply chain they originated—inside and outside of your organization.
3 Know the minimum elements of an SBOM.
The National Telecommunications and Information Administration (NTIA) defined the minimum elements for an SBOM. Being familiar with and meeting these requirements helps your organization focus on the essential elements as you create SBOMs for each product.
The NTIA’s minimums address three overlapping areas:
-
- Data fields for the tracked components, including (but not limited to) the component name, version, supplier/provenance, timestamp, and other unique identifiers.
- Automation support, such as machine readability, allows SBOMs to scale within the software ecosystem.
- Practices and processes for generating and using SBOMs, such as access control, frequency of updates, and handling of mistakes.
While license and copyright data is not part of the minimum SBOM fields, it is important data to help assess the legal risk of your application for your customers, so pick tooling that includes this in your generated SBOMs.
4 Select an SBOM format.
Currently, there isn’t a single, industry-wide format for inventorying open-source components in an SBOM. Two leading SBOM formats, recognized by the NIST Cybersecurity Framework, facilitate the sharing of information within the software supply chain. Evaluate which SBOM format will best meet your organizational needs. Consider:
-
-
- Software Package Data Exchange (SPDX), a project of the Linux Foundation, is “an open standard for communicating software bill of material information, including components, licenses, copyrights, and security references.” SPDX is the international open standard for software bills of materials, ISO/IEC 5962:2021. Complementing SPDX is another project of the Linux Foundation, Open Chain – ISO/IEC 5230:2020, “the international standard for open source license compliance.”
- CycloneDX, an OWASP Flagship Project, is a “full-stack bill of materials” standard, with capabilities not only for creating SBOMs, but which can also support a software-as-a-service bill of materials (SaaSBOM), hardware bill of materials (HBOM), operations bill of materials (OBOM), and more.
-
The philosophies of these formats are different, so select the one that best works for you. SPDX is a bottom-up view of all files within your application and the licensing driving the use of those files, along with the packages with which those files are associated. CycloneDX is more of a top-down view of the components within your application. There are several tools to transform from one format to the other, so interoperability should not be a big issue. Talk to your supply chain partners and try to consolidate similar formats and tools.
5 Automate and drive towards a continuous process.
A continuous, automated SCA program that enables your development team to identify and fix vulnerabilities early in the software development life cycle (SDLC) can prevent software development disruption. Automated processes for creating, assessing for compliance against your policies, and securely sharing SBOMs (and associated security reports and attestations) can minimize the time allocated to these initiatives and the potential errors of manual efforts. The results: optimized product innovation and time to market, along with accurate SBOMs to deliver to your supply chain partners.
