If there’s a poster child for the increased focus and attention on the security of software supply chains, it is the SBOM, or software bill of materials. SBOMs are a critical component for operationalizing software supply chain security. Practically, SBOMs act like a list of ingredients for the software that makes up applications: calling out otherwise invisible dependencies on proprietary, open source and licensed, commercial libraries.
So what is there to complain about? A lot, as it turns out. Skeptics point out that requiring production of an SBOM by software vendors might amount to a burdensome compliance requirement with little practical pay off for organizations. If software vendors already struggle with application security and secure development practices, why should they be trusted to produce accurate SBOMs?
Also, SBOM skeptics argue that they will be of little practical value until the companies reviewing them can act on the information they contain to limit cyber risk. Skeptics and critics also point to the vast transformation in application delivery: With cloud-based deployment and continuous integration/continuous delivery (CI/CD) development ascendent, meaning that the makeup of production applications may be changing on a daily — if not hourly — basis, frustrating SBOM creation and maintenance.
[ Learn more about SBOMs | See the ConversingLabs interview with Josh Corman ]
SBOMs and the journey from security through obscurity
Those arguments miss the bigger value that SBOMs bring, which is transparency into the software supply chains, according to Josh Corman, the founder of I Am The Cavalry and a Vice President of Cyber Safety Strategy at Claroty. Speaking at the recent RSA Conference in San Francisco, Corman made the argument that SBOMs are critical to realizing a better and more secure future: Just the latest step in a long journey to dispel the myth of “security through obscurity.”
That journey includes the embrace of once- controversial but now commonplace practices like full disclosure and tracking of software vulnerabilities for the purposes of patching and remediation, and the development of taxonomies of threats and attacks like the MITRE ATT&CK Framework.
“We tend to believe on almost every other topic that transparency to defenders enables informed risk decisions."
—Josh Corman
So why the pushback on implementing SBOMs? In his RSAC talk, Corman argues that the “noise” of SBOM skepticism, including mis- and disinformation about how SBOMs work and will be implemented, is motivated by fear among legacy software and services providers. Transparency is great, unless you have something to hide.
And there are lots of legacy software and services providers with stuff to hide, Corman says:
“The pushback doesn’t come from modern CI/CD pipeline people. It comes from the legacy people who have a lot of technical debt, security debt and sins they don’t want revealed."
Active opacity: The software supply chain status quo
“Active opacity” is the term that Corman uses to describe the effort to blunt the push for SBOMs and greater software supply chain security. It includes efforts by software producers to maintain a status quo in which responsibility and liability for insecure software is passed down to customers and society more broadly, with few if any negative consequences for the producers themselves.
There is, to state the obvious, no “Lemon Law” for software. There needs to be, especially as software now runs the critical infrastructure that keeps the lights on (literally), runs our healthcare environments, navigates our vehicles, and more. That increases the likelihood of cyber-physical consequences of software failures.
In this ConversingLabs Cafe edition, filmed on the sidelines of the RSA Conference in San Francisco, I sat down and talked with Josh about the problem of SBOM skepticism and what he sees as the three (actually four) main forces trying to frustrate greater software supply chain transparency efforts.
See the ConversingLabs Cafe interview with Josh Corman:
