Contact Us

Free Code & Cloud Application Risk Assessment

Cookies Notice

This site uses cookies to deliver services and to analyze traffic.

Learn more
Ok, Got it

Go back

May 4 2022 | 5 min read

Go beyond OSS dependencies with your SBOM

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.

An SBOM provides those who produce, purchase, and operate software with information that enhances their understanding of the supply chain, which enables multiple benefits, most notably the potential to track known and newly emerged vulnerabilities and risks. SBOM will not solve all software security problems, but will form a foundational data layer on which further security tools, practices, and assurances can be built.

SBOM Requirements

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:

  • Data Fields: Baseline information about each component.
  • Automation Support: Support for machine-readable formats to facilitate scaling.
  • Practices and Processes: Defines the creation and use of SBOMs.

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.”

Data Field

Description
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.

SBOM Formats

SPDX, SWID and CycloneDX are the three officially recognized SBOM standards. Each of the standards had different original use cases and current utilization:

  • Software Package Data Exchange (SPDX) – is community-driven and was first released in 2011. While it was originally developed to improve license compliance, its original use case for open source license management has since expanded to include software supply-chain visibility and security.
  • Software Identification (SWID) Tagging – with a first version published in 2009, SWID is a way to tag software with metadata that describes it. The standard is defined by the International Organization for Standardization (ISO) and makes up the ISO/IEC 19770-2:2015. While SWID contains the minimum seven elements required for SBOM, it does not offer the in-depth information provided by the other two formats.
  • CycloneDX – the latest of the three formats, CycloneDX was released in 2017 by OWASP.  The standard has multiple use cases including inventory, identification of known vulnerabilities, integrity verification and much more. The standard extends beyond the local machine dependencies to include runtime service dependencies and it provides rich data beyond the seven minimum requirements of SBOM.

The Future of Supply Chain Defense

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:

  • Track licensing for each library to ensure that your organization is compliant.
  • Provides an audit of every external component so that any vulnerabilities in third-party software is remediated with patches and updates.
  • Automate security patching for third-party libraries
  • Preserve your data integrity and brand reputation by avoiding exploits and downtime
  • Improve visibility into your software components so that you can track possible incompatibilities, colloquially termed “dependency hell” when multiple versions have conflicts

Beyond the Basics

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.