BETA
This is a BETA experience. You may opt-out by clicking here

More From Forbes

Edit Story

Why Software Supply Chain Security Is Now Everyone’s Business

Forbes Technology Council

Chief Product Officer at GrammaTech, where he leads product strategy for the company’s application security testing product portfolio.

Software developers’ over-reliance on open-source software often exposes their supply chains to serious threats, such as the recent Log4Shell and other Log4j-related vulnerabilities. The Cybersecurity and Infrastructure Security Agency (CISA) has noted that vulnerabilities are “severe because Java is used extensively across IT and OT platforms, they are easy to exploit, and applying mitigations is resource-intensive.”

The rampant damage inflicted by these types of attacks spurred the White House to issue an executive order (14028) demanding more transparency in the software supply chain of federal agencies. The order, to improve the nation’s cybersecurity, mandates that all federal agencies require a software bill of material (SBOM) from their software suppliers.

However, even software vendors that do not sell to the federal government should expect their customers will demand an SBOM for products they purchase as a risk management tool. Therefore, they should anticipate and add SBOMs as a requirement in their product planning cycles.

What To Look For In An SBOMntil recently, an SBOM was simply an inventory of components—open source, third party, custom code and so on—in a software application. The inventory typically lists the licenses for the components, the versions of the components and their patch status.

Nowadays, many SBOMs resemble software supply chain management systems as they incorporate the processes used to create the inventory. These sophisticated SBOMs enable software vendors to manage code components while delivering granular insights into vulnerabilities, dependencies, licensing and more. They also make it possible to share this information in standardized machine-readable formats.

Software vendors and the organizations that purchase their applications should evaluate SBOMs based on the following capabilities:

Does it provide deep visibility into software supply chain vulnerabilities?

An SBOM should help quickly identify, remove and reduce risks in reused code from open-source and third-party sources. This includes providing data essential for making business decisions on software quality and security—by discovering undocumented vulnerabilities and defects in open-source components and libraries.

Can it satisfy US federal government requirements?

Soon, federal agencies will require all software companies to provide an SBOM before doing business with them. Companies that meet SBOM requirements during the procurement process will likely receive fast-track status.

Will it improve internal and downstream security?

An SBOM should enable companies to quickly and efficiently avoid, detect and remediate security risks before products are shipped—thereby cutting costs during the development and deployment stages.

Implementation TipsWhen deploying an SBOM, consider the following best practices:

Use a standard format.

Two of the most common formats are SPDX and CycloneDx. Using a standard format can streamline actions today and support future requirements. It will also facilitate information sharing with customers and other third parties to improve compliance, security and dependability.

Combine first- and third-party SBOMs.

A first-party SBOM is created by an independent software vendor (ISV) for internal use to track dependencies and risks. While a third-party SBOM is typically used by software users seeking insights into the software running their businesses, ISVs that use third-party code should consider combining both SBOM types.

Use automation.

Software composition analysis (SCA) tools and binary SCA tools can automatically generate an SBOM that identifies open-source and third-party components in use while tracking and managing security risks.

Inspect all code.

Open-source software is a critical risk factor, but no code—commercial, proprietary, third-party or custom—should be overlooked in the pursuit of security. The SBOM should inspect and report on all code, not just open components and libraries.

The increasing prevalence of attacks on software supply chains over the past 18 months and the EO serve as a wake-up call for vendors and organizations that consume their products. An SBOM makes it possible to proactively identify and manage risk across the software supply chain to maintain the quality, security and integrity of finished products.


Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?


Follow me on LinkedInCheck out my website