The U.S. government’s push for mandatory SBOMs (software bill of materials) to provide software transparency in the face of supply chain attacks has sent cybersecurity buyers and sellers scrambling to understand the ramifications and prepare for downstream side-effects.
Since U.S. president Joe Biden signed the now-infamous cybersecurity executive order in May this year, there have been countless virtual workshops and live panel discussions focused on understanding the basics of SBOMs and how they would help address software supply chain attacks.
At its core, an SBOM is meant to be a definitive record of the supply chain relationships between components used when building a software product. It is a machine-readable document that lists all components in a product, including all open source software, much like the mandatory ingredient list seen on food packaging.
The National Telecommunications and Information Administration (NTIA) has been busy issuing technical documentation, corralling industry feedback, and proposing the use of existing formats for the creation, distribution and enforcement of SBOMs.
This flurry of activity has sent cybersecurity buyers and sellers scrambling to understand the downstream ramifications but, for Sounil Yu, a security veteran with leadership stints at Bank of America, YL Ventures and now JupiterOne, the energy around SBOMs is long overdue.
“I’ve been an advocate for SBOMs for a while. When I was at Bank of America, I was in various [industry financial services] advocating for SBOMs to provide transparency about the software we were buying and using,” Yu said in a recent interview.
Yu pushed the envelope at his new company, JupiterOne, an early-stage startup that sells cybersecurity products. One his first tasks as JupiterOne CISO was to go public with an SBOM as part of the company’s trust and transparency documentation.
“That was actually the first question I asked the team. Do we have an SBOM? At the time I knew that the SBOM requirement would come out in the executive order so I wanted to be a little bit prepared to know whether or not we could produce an ingredient list of everything in our product,” Yu explained.
Yu viewed the company’s ability to generate an SBOM as a sign of maturity and he wanted to use the document to provide a baseline level of transparency for buyers and, even more importantly, remediate licensing risks and security vulnerabilities during the development process.
While the SBOM is a new acronym on the agenda list for modern CISO meetings, Yu expects activity around software ingredients list to take center stage as a critical part of the open source governance process.
He sees SBOMs not as something futuristic, but more as “completion of the past” where the collection and maintenance of a very thorough inventory of our software assets suddenly becomes realistic.
“Unfortunately we don’t really have that today, at least not at the level of granularity that helps us understand whether or not we’re exposed to a particular vulnerability [in a third-party] component. When we discover, again, that OpenSS or some open-source package might be vulnerable, we really don’t know our exposure because we don’t have an inventory.”
“This [SBOMs] can help bring a level of completeness to the inventory process,” he said, arguing that security vendors will find multiple side-benefits around software licenses, patching open-source components and dependencies, and maintaining a modern technology stack.
The JupiterOne security chief urged his CISO peers and entrepreneurs to actively participate in the industry dialog around supply chain security issues and stay current with new standards and formats that will emerge from ongoing consultations.
Robert M. Lee, co-founder and chief executive at industrial cybersecurity vendor Dragos, agrees that SBOMs could provide major benefits to both buyers and sellers but cautioned that it will be “extraordinarily hard to operationalize” once SBOMs identify weaknesses deep in the chain.
During a recent fireside chat at SecurityWeek’s APAC ICS Cyber Security Conference, Lee said he expects SBOMs to help provide visibility to security risk exposure from software but due to the nature of threats in ICS environments, he doesn’t expect it to move the needle on vulnerability management programs.
Lee also sees value for SBOMs in the procurement process where an outdated library or software component would be flagged early in the purchasing process. He also expects the SBOM mandate to help clean up software licensing processes among both buyers and sellers.
The U.S. Commerce Department’s NTIA has been out front advocating for SBOMs with a wide range of new documentation including:
• SBOM at a glance – an introduction to the practice of SBOM, supporting literature, and the pivotal role SBOMs play in providing much-needed transparency for the software supply chain.
• A detailed FAQ document that outlines information, benefits, and commonly asked questions.
• A two-page overview provides high-level information on SBOM’s background and eco-wide solution, the NTIA process, and an example of an SBOM.
• A series of SBOM Explainer Videos on YouTube.
Separately, the open-source Linux Foundation has released a batch of new industry research, training, and tools aimed at accelerating the use of a Software Bill of Materials (SBOM) in secure software development. These include documentation on SPDX, a standard for SBOM requirements and data sharing.
The Linux Foundation also published a new SBOM survey highlighting the current state of industry practices to establish benchmarks and best practices; a new SBOM training course on Generating a Software Bill of Materials to accelerate adoption; and SBOM tools to enable software development teams to create SBOMs for their applications
The free online training course on Generating a Software Bill of Materials (LFC192) promises foundational knowledge about the options and the tools available for generating SBOMs and how to use them to improve the ability to respond to cybersecurity needs.
The open-source group also released SPDX SBOM generator, a command-line tool used to generate SBOM information, including components, licenses, copyrights, and security references of applications. The tool uses the SPDX v2.2 specification and aligns with the current known minimum elements from NTIA.
