With new and increasing cyber threats abound, 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.​
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 of their SBOMs in one place.
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 can be exploited. As such, it's important that software developers keep security top of mind when creating new applications.
While the rising adoption of SBOMs offer a great step forward for 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 broken 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 in memory-unsafe languages such as C or C++, releasing products that contain 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.
Increased guidance around 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 toward knowing what's in their software, puts them ahead of the game in terms of being able to defend against the ever-evolving threat landscape.