Wouldn't practices to secure the supply chain remain vague and prone to human error in the absence of a recognized SBOM standard to rigorously specify what the software contains?
The Dept. of Commerce NTIA (National Telecommunications and Information Administration) started exploring the issue of SBOMs a few years ago, then this work transitions to CISA (still under the leadership of Dr. Allan Friedman) and in parallel a substantial group of people, led by Bob Martin of MITRE, started to develop an OMG standard. The idea is to unify the disparate and incomplete de facto standards (SWID, SPDX, CycloneDX) and create something more complete and robust for which software vendors can develop tools. With a common standard, supported by a variety of tools that adhere to the standard, SBOMs can be created, analyzed, exchanged, combined (e.g., when an integrator buys products A and B and sells a product C that contains them both plus some extra stuff), etc.
I'm not sure that the following page is up to date, but look at https://www.it-cisq.org/software-bill-of-materials/ for more information about the OMG effort (CISQ is also mentioned, and it is a consortium within the OMG "family" of consortia).
One of the scoping issues is whether you include in the SBOM of a product the component of the software you invoke through a cloud service. From a security standpoint (e.g., vulnerability tracking), it seems that you should. But that can get complicated, especially since the cloud provider says "nope, I'm not telling you how my software is built, that's my trade secret."
Another issue, which was frequently raised in the original NTIA workshops about this (circa 2019) is that a software product might in theory inherit a vulnerability from a component, but that vulnerability may not be executable in that context -- i.e., the containing product may never invoke the component in a way that causes the faulty code to be executed. Software vendors are concerned about "false alarms" that might cause customers to blacklist their products due to an alert that it contains such code. (To me, the idea that you get a pass for leaving a dormant vulnerability in your product is a bit dubious, but I also understand the concern about the feasibility of eradicating all such instances).
------------------------------
Claude Baudoin
cébé IT Knowledge Management
Co-Chair, OMG Cloud Working Group
https://www.omg.org/cloud------------------------------
Original Message:
Sent: Nov 13, 2023 08:56:17 AM
From: Michael Roza
Subject: NSA Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption
Hi All,
NSA just pblished Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption
Unmitigated vulnerabilities in the software supply chain pose a significant risk to organizations. This paper builds on the previously released Recommend Practices4 for a software supply chain's development, production, distribution, and management processes, to increase the resiliency of these processes against compromise. This guidance also builds upon and supports the Office of Management and Budget (OMB) memorandum on Enhancing the Security of the Software Supply Chain through Secure Software Development Practices (M-22-18)5.
Because the considerations for securing the software supply chain vary, this follow-on guidance focuses on Software Bill of Material (SBOM) Consumption and open source software (OSS). This information will help continue to foster communication between the different roles and among cybersecurity professionals that may facilitate increased resiliency and security in the software supply chain process.
All organizations are encouraged to proactively manage and mitigate risks as a part of evolving secure software development practices. An organization's role as a developer, supplier or customer of software in the software supply chain lifecycle will continue to determine the shape and scope of this responsibility.
It is recommended that acquisition organizations assign supply chain risk assessments to their buying decisions given the recent high profile software supply chain incidents. Software developers and suppliers should improve their software development processes and reduce the risk of harm to not just employees and shareholders, but also to their users.
------------------------------
Michael Roza CPA, CISA, CIA, CC, MBA, Exec MBA, CSA Research Fe
------------------------------