Why SBOMs are key to securing the software supply chain [Q&A]

Attacks on the software supply chain have become more common in recent years. Part of the key to tackling them lies in understanding what components are in your software and where they originate.

This is why the software bill of materials (SBOM) has become a vital tool for organizations seeking to secure their software. We spoke to Alex Rybak, senior director, product management at Revenera to learn more about SBOMs and what advantages they offer.

BN: Why are SBOMs gaining so much traction among software suppliers?

AR: Software creation involves much more than what an individual developer or software engineering team brings to an application. An application relies on multiple developers and partners, pulling in parts and systems from inside and outside an organization. Most (80 percent) of the components aren't proprietary. By consuming third-party components, including open source software (OSS), a software supplier assumes the risks (including potential vulnerabilities and compliance issues) associated with that code.

The best way to track and manage those risks: a complete inventory of what’s in your application. That's where the software bill of materials (SBOM) is so crucially important. It tracks components, identifying their origin and where they exist within the application.

We're at an inflection point. The Biden administration's Executive Order on Improving the Nation’s Cybersecurity and existing regulations and recommended best practices from various industry groups (including PCI, FDA, NTIA, and CISA) are motivating software suppliers to focus on creating a formally structured and machine-readable listing of all software components, OSS, and third-party commercial software found within their applications -- regardless of where they originated, inside or outside the organization. More and more suppliers now use SBOMs -- and expect their supply chain partners, upstream and downstream, to do the same.

BN: How do SBOMs help manage and mitigate supply chain cybersecurity risks?

AR: What's in our code? That's a fundamental question that all software suppliers must be able to answer, as all code carries an element of risk that must be mitigated. If you don't know what's in your code, you can't manage that risk.

Generating a complete and accurate SBOM puts organizations on the fast track to managing the next Log4j-type incident, putting the organization in a much better position to respond to and mitigate damage. An SBOM provides a detailed inventory that helps manage the associated risks. It identifies the components in your software; the provenance of those components; each component’s license information; your software's security vulnerability state and that of the devices where it runs; the parts that require assessment and remediation, along with process status; and the other compliance artifacts, in addition to SBOMs, that you need to deliver to partners and customers.

BN: What is needed to make an SBOM comprehensive and actionable?

AR: As the software supply chain matures and becomes more complex, the level of detail in an SBOM also grows more complex. For this information to provide a complete view of all applications and be applicable, it should: ingest data from a wide range of data sources, both inside and outside of your organization; unify all SBOMs into single view in the cloud; provide full open source and third-party component visibility to all parties that rely on the information. The SBOM must be maintained regularly in order to be current and accurate; a continuous, automated software composition analysis (SCA) process is necessary.

BN: What are the top challenges to creating and maintaining accurate SBOMs?

AR: Generally speaking, organizations are good at scanning their applications. They can rely on various tools to create an SBOM of the code they've written and contributed to; these proprietary components might represent about 20 percent of the code in the final application.

Having an accurate view of all the other code in the final product is where things get tricky. For this, a unified view is required of the data ingested both internal and external sources (partners, vendors, and suppliers). Additionally, SBOMs can be in varied formats. When a supplier receives an SBOM from an upstream partner, for example, the multiple formats may not align, making it increasingly difficult to gain a single comprehensive view. When a security event takes place, not having a full view of what's in the software application can delay and reduce the efficiency of mitigation work.

BN: What role can the cloud play in aggregating data from multiple sources?

AR: Cloud inventory management, such as Revenera SBOM Insights, expands the transparency into an organization’s products. This is possible because cloud-based SBOMs can ingest data (in SPDX and CycloneDX formats) from multiple sources, both internal and external. This cloud-based approach provides a unified, actionable view of components, security vulnerabilities, and open source license compliance issues, not solely in your code, but in all software components coming from outside of your organization.

Centralized, cloud-based SBOM management, as part of a comprehensive SCA program, allows your organization to do far more than identify the ingredients used in your software. It facilitates ongoing policy management, risk management initiatives, and license compliance programs. This information equips you for resource management, identifying how to align your staff resources for development and/or risk remediation.

BN: Which stakeholders benefit from the use of SBOMs?

AR: SBOMs are valuable for multiple organizations and departments, these include:

• Security: Clearly security teams benefit, as SCA and SBOMs provide enhanced visibility into security risks and vulnerability exposures. When an issue’s discovered, an SBOM provides efficient alerts and impact analysis, facilitating rapid remediation.
• Developers: By relying on an SBOM as part of a secure software development framework, development teams can detect vulnerabilities during software development and throughout the software's lifecycle. This 'shift left' moves license compliance and security considerations earlier in the development process, supporting a cost-effective approach to today’s rapidly changing software development environment.
• Legal teams: All third-party code, including OSS, requires that users comply with associated licenses. An SBOM tracks the licenses associated with each component, supporting compliance. When a product is shipped downstream, the distributing company is responsible for risks in the product, even if the vulnerability in the application came from an upstream source; a reliable SBOM provides clarity into potential risks. Not only is compliance important for legal protections, SBOMs help legal teams as they work through mergers and acquisitions, demonstrating to all parties involved that the software used in a company’s products is safe and that risk to the company is being managed appropriately.
• Supply chain partners: Responsible software development and management calls for protecting yourself and all who use your products. A well-managed SBOM generates an accurate inventory of compliance artifacts that can be shared with downstream supply chain partners, offering assurance that you're handling and tracking your software components effectively. This helps keep your supply chain partners safe and can help strengthen your reputation with them.

Image credit: Chan2545/depositphotos.com