What is a Software Bill of Materials (SBOM)?

Just like your technical hardware consists of many moving parts, so does your software. The problem is that all the moving parts of your software aren’t as visible. Understanding the building blocks that go into anything that you buy, develop and use for your company is essential when you’re dealing with a potentially harmful element—like malware. That is why a software bill of materials (SBOM) is now part of software supply chain compliance.

What Is an SBOM?

Think of your software bill of materials (SBOM) like the list of ingredients on packaged food — or, in this case, a detailed list of your digital application’s components and how they relate to one another. According to the Cybersecurity & Infrastructure Security Agency (CISA), SBOM is a key building block in software security and software supply chain risk management. Taking steps to improve this security element in government organizations and other companies has never been more important due to the increasing level of cyber attacks.

A mix of proprietary and third-party elements often goes into software. To save time and avoid rewriting code from scratch for each software rollout, developers often use open-source code or borrow from other repositories. Software developers should list it in the SBOM regardless of where they pull code from. Thanks to Executive Order 14028, transparency with each development element is now required when working with federal agencies.

More About Executive Order 14028

The President’s Executive Order (EO) 14028 was issued on May 12, 2021, containing 11 sections that spell out how the government is planning direct action to improve the United States’ cybersecurity. Key elements include:

  • Software vendors must provide a Software Bill of Materials (SBOM) for each product either directly to purchasers or via a public website, marking a significant shift in supply chain transparency requirements that GRC professionals need to monitor and implement.
  • Critical software suppliers must maintain accurate data on code provenance, implement controls on third-party components and perform regular audits – introducing new vendor risk management obligations that GRC teams must integrate into their assessment processes.
  • A new Cyber Safety Review Board will evaluate significant cyber incidents, providing recommendations that GRC professionals should monitor as they may influence future regulatory requirements and industry best practices.

SBOM Components

So, what does an SBOM include? Adhering to the following components ensures quick recognition of targeted parts.

  • Name and version: The name of the software or library should be clearly stated.
  • Source: Developers must state whether the source code is proprietary or taken from a public repository on an open-source base like GitHub.
  • License: The license is a legal agreement that specifies ownership copyright, how to use and distribute the software or individual components and modification limits.
  • Relationships: What is the connection between these components and subcomponents? Software components usually have a hierarchy, especially in large-scale projects.

Types of SBOMs

According to Tech News World, “Selecting the right type or combination of SBOMs to serve your organization’s needs involves more consideration than merely opting for the first SBOM-generating tool available.” You want to be clear about what type of SBOM you need and what elements matter to you in any kind of tool. The best types of software bill of materials to use depends on the stage of the product lifecycle:

  1. Design: Think of this type as speculative, as it focuses on software that is still in the works. Despite limitations at this early stage of development, engineers can use this type of SBOM to review licensing concerns and incompatible elements before the building starts.
  2. Source: Also created in the early development stage, engineers can review source files and dependencies.
  3. Build: Now you have a complete inventory of components that includes source files, dependencies, data and source SBOMs. Engineers will scan everything in the build system.
  4. Analyzed: This type also goes by the name “third-party SBOM” or binary SCA. It earns its name by analyzing the delivered artifacts from third-party tools. Doing so can help find hidden dependencies missed by the creation tools.
  5. Deployed: An inventory of deployed software.
  6. Runtime: There may be a blind spot in deployed SBOMs. Luckily, this type allows developers to examine dynamically loaded components and outer connections during execution.

SBOM Formats

With different types of software and development stages, a unified structure through SBOM standards (SPDX, CycloneDX) is necessary.

CycloneDX provides a lightweight software bill of materials standard backed by the OWASP Foundation. It supports other BOMs such as Software-as-a-Service Bill of Materials (SaaSBOM), Hardware Bill of Materials (HBOM) and Operations Bill of Materials (OBOM). A global community supports this standard and plays a role in its updates. You can easily integrate it with other development tools as it comes in multiple formats like XML and JSON.

The Linux Foundation supports the Software Package Data Exchange (SPDX), which is described as an open standard for streamlining the communication of relevant information between communities and organizations. Its main focus is license compliance and information.

black iphone 5 beside brown framed eyeglasses and black iphone 5 c
Photographer: Dan Nelson | Source: Unsplash

The Importance of SBOMs in GRC

According to the SANS Institute, a cooperative for information security thought leadership, software bills of materials enhance software supply chain security by providing visibility into its composition. As a result, engineers can quickly find and solve potential and existing vulnerabilities. Since the information is sharable, it can help all stakeholders make quick decisions throughout the product lifecycle. It also ensures compliance at all levels, from maintaining licensing agreements to meeting the requirements of Executive Order 14028.

The federal guidelines may have been created due to the increasing risk to national cybersecurity, but other industries also benefit from the upgraded standards, best practices and guidelines that software engineers are expected to follow. For example, the medical industry needs these regulations as technology continues to play a role in managing patient records and medical devices. Identifying cybersecurity risks in medical devices can keep patients’ data and medicine regulation safe.

Benefits of Implementing SBOMs

A cybersecurity attack can happen quickly and create a lasting impact on any organization within a short amount of time. Using SBOMs allows engineers to identify which components must be updated or removed. When you have a large-scale project, having a visible list of every component can make the tracing easier — and faster!

Cybersecurity risk management involves staying compliant to avoid fines for licensing misuse and lawsuits for data leaks. You could also lose money and trust from customers, who may see a potential security issue if they do business with your company.

SBOM Implementation

To be sure your SBOM runs smoothly, you should understand the best practices, steps to follow and the challenges throughout the process.

Here are some steps to create and maintain SBOMs:

  1. Stay updated: Constantly update and maintain your application components. These updates can include adding new features and bug fixes as close as possible in real-time to avoid components becoming outdated and creating a negative chain reaction.
  2. Ensure data integrity: Keep your data safe by auditing every element, such as licenses and version numbers. Only use trusted sources that a third party can verify.
  3. Identify potential issues: Always consider potential problems that could impact your end user. When you find these issues, devise a contingency plan.
  4. Create clear documents: Documentation is important in any technology development process, and SBOM is no different. Your software may have multiple SBOMs, so always specify which version and type of SBOM it is.

Integration With Existing GRC Processes

The best way to integrate SBOM implementation into your GRC process is to use automation. Otherwise, doing so manually will take too long and increase the risk of missing vulnerabilities. Start by evaluating your current processes and then select the tools with the most accessible integration and scanning capability. Keep various teams like security and operations up-to-date on what’s happening to ensure they utilize some form of SBOMs for better workflow.

Challenges and How To Overcome Them

While SBOM implementation may have federal support, there are some challenges, such as a lack of standardization, incomplete or inaccurate data, lack of resources, not fully understanding the data and trying to integrate it into existing workflows. One of the best ways to overcome these challenges is to foster communication and maintain accurate component documentation. Open communication within your company can help narrow down vulnerabilities and streamline workflow concerns.

SBOM Tools and Technologies

You can choose from open-source and general SBOM generation tools for your organization. Some popular ones to consider include:

  • Syft: Generates SBOMs from file systems and container images.
  • Tern: Focuses on collecting license data
  • Retire.js: Scans JavaScript security issues
  • Jake: Generates SBOMs in CycloneDX format while checking Python for vulnerabilities.
  • CycloneDX Generator: Supports several languages such as Java, Python, C/C+ and more.
  • Fossa: Provides end-to-end management of the SBOM process.

Here are some considerations for selecting the right tools for your organization:

  • Accurate information from the tool protects your software from vulnerabilities.
  • Your company may sprout from a small-scale startup to a large corporation. Therefore, it’s ideal to find SBOM software you can scale as you handle more complex products.
  • What is your existing workflow like? Your team should have a tool that provides smooth integration.
  • You want an intuitive interface that improves the user experience for all — even non-developers.
  • All tools may not fit your company budget, so weigh the cost with the features available.

If SBOM compliance requirements seem overwhelming, you have a team of experts to assist you. Schedule a demo to discuss your processes with an Onspring expert by contacting us today.