May 4 2022 | 5 min read
Executive | May 4 2022 | 5 min read
The U.S. Executive Order on Improving the Nation’s Cybersecurity requires a Software Bill of Materials (SBOM) for any software sold to the U.S. federal government. This level of visibility into the software supply chain will be increasingly required by non-governmental entities as well. However, this is not only a US matter. While SBOMs and their specific requirements are in their infancy, organizations in every country that seek to provide transparency to their customers can go beyond the basics by understanding their code base and add layers of context to create a more accurate and complete SBOM.
Read on to learn not only SBOM requirements and standards, but how to go beyond them in order to provide significant additional risk transparency to your customers.
In the US, the National Telecommunications and Information Administration (NTIA) in the United States Department of Commerce has established SBOM criteria. Minimum requirements fall across three areas:
According to the NTIA, there are seven necessary fields for an SBOM, which represent the very minimum of what is required. “The goal of these fields is to enable sufficient identification of these components to track them across the software supply chain and map them to other beneficial sources of data, such as vulnerability databases or license databases.”
|Supplier Name||The name of an entity that creates, defines, and identifies components.|
|Component Name||Designation assigned to a unit of software defined by the original supplier.|
|Version of the Component||Identifier used by the supplier to specify a change in software from a previously identified version.|
|Other Unique Identifiers Dependency||Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases.|
|Relationship||Characterizing the relationship that an upstream component X is included in software Y.|
|Author of SBOM Data||The name of the entity that creates the SBOM data for this component.|
|Timestamp||Record of the date and time of the SBOM data assembly.|
A SBOM might be a requirement by the US government, but it also has several benefits for an enterprise in every country. For any organization that focuses on NIST framework requirements, it can ensure compliance with specific safeguards that protect data integrity and stop exploits on unknown vulnerabilities.
Most developers use several dependencies from third-party libraries to include common functionality. Imagine if your organization included a vulnerable library to internal software. Adding vulnerable code might not be intentional, but it can leave the organization vulnerable to critical exploits. These libraries could add vulnerabilities such as cross-site-scripting, SQL injection, HTML/DOM injection, CSV injection, and potentially remote code execution on a critical server, so they can do incredible damage to your internal or public-facing applications.
By having a comprehensive SBOM, you can track each product to their developer and track any updates and patches. It also lets you identify any libraries with abandoned repositories so that you can work to find an alternative solution. A detailed SBOM makes it more convenient to track relevant issues reported on vulnerability databases so that any third-party libraries can be patched quickly, reducing the window of opportunity for attackers on your own applications.
A few general ways SBOM benefits your own supply chain defense and software development life cycle:
To provide true risk visibility to you and your customers, ensure that your SBOM extends across all application components, sensitive data, open source software, and infrastructure components, because these days everything is code!
Up until recently, getting a comprehensive view into an application’s BOM required combining multiple BOMs from separate tools to build out the full picture. However, Apiiro is one of very few vendors that now supports the CycloneDX standard and can provide a complete view of software and its components.
Why is this important? Consider the benefits of a comprehensive SBOM for areas such as software supply chain defense, mergers & acquisitions or compliance. In addition to a comprehensive SBOM, consider the growing organizational needs for a SaaS bill of material (SaaSBOM). This includes information such as on which cloud service provider infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS) your software runs. It also means building an API inventory, which is likely the next step in expanding the minimal SBOM requirements. All this Information helps to specify software cloud dependencies and allows for much improved supply chain visibility.
With Apiiro, your organization can gain full visibility to what makes up your software including cloud components. Book a demo to find out how it works and keep in mind that the drive for standardization by NIST and their publication of the Secure Software Development Framework means that a business need for an all-encompassing and precise SBOM globally is a matter of when, and not, if.