What the NSA Missed in its SBOM Management Recommendations

On December 14th, the NSA released “Recommendations for Software Bill of Materials Management.” It goes into detail about how SBOMs can be leveraged with the right “aggregation and synthesis” tools to make:

• risk management decisions about the software they acquire and deploy
• vulnerability management of the software (on an ongoing basis)
• incident management when new vulnerabilities or other malicious packages are detected
  

The document further outlines the recommendations of SBOM tools that can be used for analysis. We endorse the NSA recommendations, but it's missing a critical first step.

‍

Where to start!?

‍

“The beginning is the most important part of the work.” – Plato

‍

There is still a lot of confusion when it comes to generating SBOMs. Many organizations or corporations are in their infancy on the journey to secure their software supply chain. For this reason, we advocate that starting to produce SBOMs in your CI/CD pipeline is a primary move toward understanding and managing your software supply chain. While SBOMs are still an evolving standard (and by no means perfect), they are a step in the right direction to provide a window into software composition.

‍
Generating an SBOM via scanning tools provides some insight into its composition, but as the NSA guidance suggests, SBOMs should be generated using the source code from the build stage in your pipelines. Utilizing the ecosystem’s build tools to generate SBOMs, we can obtain a much more accurate and complete SBOM. Once this step is completed, we can delve into other advanced topics such as including runtime dependencies and digitally signing the SBOM (via tools like sigstore). But for those organizations just starting on their journey, the creation of an SBOM and feeding that into tools like Graph for Understanding Artifact Composition (GUAC) is a huge step forward in transparency in their software environment.

‍

Steps in the right direction

‍

The NSA publication further highlights recommendations about the value that an SBOM can bring to an organization by combining it with tools like GUAC. GUAC can ingest various SBOM formats, validate the structure of the SBOM per the specification, and aggregate and synthesize the data with vulnerability and other metadata. Through GUAC, users can visualize and analyze the data to gain deeper insight into their software environment. They can proactively respond to incidents or understand the blast radius of a critical vulnerability. Finally, GUAC also provides GraphQL and REST API to integrate with other systems for automated actions/remediation.

While the NSA publication provides best practices and recommendations regarding SBOMs, it’s disappointing that it did not address what most organizations today are struggling with – getting started on the journey. Taking the first step is always the hardest, but once you pass the barrier, other controls such as SLSA or signing become simple.

Are you confused and having a hard time taking the first step? Reach out, and we will help and inspire you on your journey to software transparency.