SBOMs: Securing Software Supply Chains Learn what role SBOM’s play in secure software development, the Cybersecurity Executive Order, and enhancing software supply chain security

Software supply chain risk management & compliance with the Executive Order on Cybersecurity

Why you need a SBOM

Because what you can’t see can hurt you

Software applications are a complex hierarchy of thousands of components from many different sources. How can you trust that those components don’t contain critical vulnerabilities or indicators of supply chain compromise that put your applications - and your business - at risk? The first step is obtaining a comprehensive, accurate, and current Software Bill of Materials.

Why you need a SBOM

To Comply with the Executive Order on Cybersecurity

The Cybersecurity Executive Order signed in May 2021 called on National Institute of Standards and Technology (NIST) to develop new guidelines for vendors selling software to federal agencies to improve the security and integrity of the software supply chain. Among those guidelines are that comprehensive and current SBOMs are made available for “all classes of software” used by the federal government, including purchased, open source and internally developed software.

What Is an SBOM? A List of Ingredients

A Software Bill of Materials is a listing of all components and dependencies in an application. While SBOMs are not a new invention, their use has been limited to date. Even today, the process for assembling SBOMs is often manual and their audience has historically been internal development teams, not external customers and auditors looking to secure their software supply chains. This change means that modern SBOMs must be comprehensive, accurate, and cover the entire dependency hierarchy to deliver value.

See Components Others Miss

See Components Others Miss

SBOMs must uncover all components, regardless of source, type or whether it is embedded, compressed or encoded. Component lists generated by automated build systems are rarely comprehensive enough to be useful SBOMs, since there are ways to add components to code, containers, installers or commercial libraries without declaring them on build or package manifests.

Dig Deeper Into Dependencies

Dig Deeper Into Dependencies

Your software relies on components (internally developed, open source, proprietary), which rely on components, which rely on still more components. To be effective, SBOMs need to capture this entire hierarchy - the trunk and every branch and leaf. Without dependency depth, your response to newly reported software supply chain vulnerabilities will be incomplete and needlessly time consuming.

Verify Component Accuracy

Verify Component Accuracy

Each component in the software you use should be what the SBOM says it is. Verification checks are needed to ensure no misleading or missing information about the software publisher, product, or its version is overlooked, which could complicate future vulnerability matching.

Learn what it takes to generate comprehensive SBOMs

Third-party code comes with some baggage

Third-party code comes with some baggage

Read Blog

Once You Have an SBOM, What’s Next?

Connect it to actionable information

A list of what’s in your software is great, but wouldn’t it be even better to have it connected with information that you can do something with?
Automated binary analysis of each component, as it’s found and listed in your SBOM, can deliver more value to your development, operations, and compliance teams.