At CloudNativeSecurityCon 2023 in Seattle, WA, Kiran Kamity, founder and CEO of Deepfactor, led a panel discussion on software supply chain security, the practical side of SBOMs, and VEX.
A Software Bills of Materials (SBOM) is a list of the components that make up an application, including dependencies and relationships during development and delivery. Kamity started the talk by underscoring how some organizations rush to create SBOMs because they have until the beginning of June this year to comply with the US executive order on cybersecurity.
He mentioned that this panel discussion aims to bring together experts on the operational aspects of cybersecurity to answer questions such as how to create SBOMs, how to store them, and what to do with them.
After introducing the speakers, Kamity started the discussion by asking the panel what an SBOM is and why people should care.
Allan Friedman, senior advisor at CISA, referred to SBOMs as a dependency treatment to help us achieve more transparency. He pointed out:
Transparency in the software supply chain is going to be a key part of how we make progress in thinking about software.
He mentioned that the log4j vulnerabilities crisis of December 2021 wouldn’t be a one-off event. SBOMs can help developers build secure software, IT leaders select software, and end-users react faster.
Furthermore, he shared plenty of proprietary and open source tools today that can generate SBOMs, including the two formats SPDX, and CycloneDX.
Friedman ended by referring to the Vulnerability Exploitability eXchange(VEX), which will allow organizations to assess the exploitability level of vulnerabilities to prioritize and focus on those that matter to them.
InfoQ sat with Chris Aniszczyk, CTO of CNCF, at the event and talked about SBOMs.
I love SBOMs. It is funny that we have been excited about SBOMs for a decade at the Linux foundation and now they’re everywhere. We’ve been prototyping with SBOMs for some projects in the CNCF and based on the tool used, it generates a different type of SBOM. Eventually, the tools will converge and generate a similar thing but we are not there yet.
Next, Rose Jude, senior open source engineer at VMWare and maintainer of project Tern, an open source software inspection tool for containers, discussed the storage and distribution of SBOMs. She mentioned that the focus in the community lately had been more on generating SBOMs and less on storing them.
Also, she pointed out that the considerations for SBOMs storage are no different than other cloud native artifacts including lifecycle management, caching, versioning, and access control. However, SBOMs’ association with artifacts is a unique thing.
She ended by underscoring that if you’re a software vendor, sharing your software SBOMs with your customers is a way to establish trust and help them understand their exposure and risk.
Kamity wrapped up the session by asking Andrew Martin, CEO of ControlPlane, how can teams start using SBOMs and what the payoff is.
Martin pointed out that because there's no standard way to distribute SBOMs today, end-users should ask for or pull SBOMs from their software vendors and scan package manifests using a container vulnerability tool to assess CVEs. He pointed out that it’s a complex problem and further automation is needed.
Kamity recommended the Graph for Understanding Artifact Composition (GUAC) developed by Google to understand better how to consume, use, and make sense of SBOMs since it covers the proactive, preventative, and reactive aspects.
The breakout session recording is available on the CNCF YouTube channel.