Securing Your Software Supply Chain With CISA's New SBOM Guidance

November 04, 2024
By Aaron Linskens

4 minute read time

Enhancing Software Security with CISA's Latest SBOM Guidance

With new and increasing cyber threats, navigating global software regulations and staying informed and compliant can seem like an unending task. To help mitigate risks within the software applications organizations use every day, many are increasingly looking to the strategic adoption of software bills of materials (SBOMs) as an effective way to maintain compliance and better secure their software supply chain. An SBOM lists all packages and libraries in an application, including all components' dependencies. This enhanced visibility into what's in a piece of software makes it easier to identify vulnerabilities and license issues, as well as manage risk from open source components.

However, as security vulnerabilities evolve, so too must SBOMs. To that end, the Cybersecurity and Infrastructure Security Agency (CISA) recently unveiled its latest guidance around framing software component transparency. Created by CISA's community-driven Software Bill of Materials (SBOM) Tooling & Implementation Working Group, the new resource further defines SBOM concepts and clarifies SBOM attributes from the previous edition of the guide, "offering descriptions of the minimum expected, recommended practices, and aspirational goal for each attribute."

Key new recommendations in the third edition of "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)" include:

• Expanded baseline attributes: Two new baseline attributes, "license" and "copyright holder," enhance SBOM details and enable better legal compliance tracking​.

• Attribute maturity levels: Maturity levels for various SBOM attributes guide creators on progressing from minimum expected data to aspirational completeness in their SBOMs.

• Undeclared SBOM information: Section 2.3 now includes options for handling undeclared SBOM data, helping users indicate unknown or redacted component details.

• Risk management integration: A focus on risk management within SBOM consumption provides a structured approach for organizations to manage software-related risks.​

Managing SBOMs With Enterprise Tools

Once organizations have created a software bill of materials for every application in their software portfolio, ongoing management and monitoring of the SBOMs is critical. Sonatype SBOM Manager is an enterprise-class SBOM software management solution that enables organizations to:

• Audit SBOMs to simplify risk management and compliance.

• Distribute SBOMs at scale in both CycloneDX and SPDX formats.

• Monitor SBOMs continuously and identify new malware and vulnerabilities.

• Comply with SBOM regulatory requirements.

Using an SBOM software management tool, like Sonatype SBOM Manager, allows companies to create, store, and monitor all their SBOMs in one place.

Guidance on Product Security Bad Practices

According to a report from The Linux Foundation, in partnership with the Laboratory for Innovation Science at Harvard (LISH), "it has been estimated that Free and Open Source Software (FOSS) constitutes 70-90% of any given piece of modern software solutions." As open source code becomes increasingly pervasive, it becomes a primary target for attackers because it's so widely used and exploited. As such, it's important that software developers keep security top of mind when creating new applications.

While the rising adoption of SBOMs offers a great step forward in increasing transparency of existing software and legacy systems, CISA and the FBI also recently released an overview of product security bad practices to help developers avoid exceptionally risky practices from the get-go. Relevant to all software manufacturers, the new guidance is particularly relevant for developers producing software used in service of critical infrastructure or national critical functions (NCFs).

More specifically, the bad practices are divided into three categories to encourage developers to reduce risk throughout every stage of the software development life cycle (SDLC):

• Product properties: The observable, security-related qualities of a software product.

• Security features: The security functionalities that a product supports.

• Organizational processes and policies: The actions taken by a software manufacturer to ensure strong transparency in its approach to security.

The agencies recommend against building memory-unsafe languages such as C or C++, releasing products with default passwords or ones that do not support multi-factor authentication in the baseline version, and failing to publish complete CVEs, including the appropriate CWE field, in a timely manner for all critical or high impact vulnerabilities.

Keeping Security at the Forefront of the Evolving Software Development Life Cycle

Increased guidance on how to both enhance software transparency and implement security best practices will continue to play an important role in effectively managing the software supply chain. Organizations that dedicate resources to knowing what's in their software are ahead of the game in terms of defending against the ever-evolving threat landscape.

Written by Aaron Linskens

Aaron is a technical writer at Sonatype. He works at a crossroads of technical writing, developer advocacy, and information design. He aims to get developers and non-technical collaborators to work better together in solving problems and building software.