Interview with Walter Haydock, Founder and CEO of software supply chain evaluation platform vendor, StackAware.com.
When building his supply chain evaluation platform, Walter Haydock realized he needed to solve the SBOM (software bill of materials) consumption problem so that businesses using them could make sense of both vendor and open source SBOM reports to improve organizational risk. In this interview, he discusses how development organizations should plan for buyers to consume, share, and reuse their SBOM output.
Q: SBOMs are now being automatically generated by software analysis tools in the development workflow. How are SBOMs being processed and consumed by software buyers?
At this stage, producing SBOMs is pretty much a solved problem. For example, if you look at the OWASP CycloneDX tool center, there are more than 160 available options. These include both open source and proprietary tools.
Pro Tip: Read up on SBOM generation, and how GrammaTech’s CodeSentry can produce SBOMs from binary.
Unfortunately, SBOM consumption is a completely different story. There are very few organizations that are actively consuming and using them for risk analysis purposes, with the most well-known one being New York Presbyterian Hospital.
Other groups using SBOMs do so in a very manual manner, such as by storing the raw XML or JSON file in a Google Drive folder or with their governance, risk, and compliance (GRC) tools. And at best they are comparing components in the SBOM to publicly available lists of those with known vulnerabilities in them. This creates a lot of noise and makes it difficult to use SBOMs to manage risk effectively.
To really make SBOMs a useful tool for understanding organizational risk, consumers will need automated systems and processes that evaluate the real-world likelihood and impact of exploiting a vulnerability in the underlying software. This will give operators the data they need to decide whether to mitigate, avoid, transfer, or accept the resulting risk.
Q: Critical software that runs infrastructure and autonomous vehicles will be the most important area to focus on in the future. What do we need to tell developers of these types of apps to prepare for and how will their customers consume SBOM information?
Essentially every modern system operates as part of an intricate digital supply chain. From autonomous vehicles to military aircraft, software is increasingly powering safety-critical systems. So, in these cases, developers need to carefully review the components and the services these programs run on, such as cloud providers. SBOMs can help organizations to understand these and other digital dependencies.
Pro Tip: Learn how continuous application analysis helps with software-driven embedded product development.
Using structured formats such as the Vulnerability Exploitability eXchange (VEX), which is already a component of the CycloneDX SBOM standard, developers can communicate with downstream consumers of their products about the risk posed or not posed by known vulnerabilities in the software supply chain. By providing these reports as part of their own SBOMs to their customers, developers can help customers operate their software with greater confidence and make more effective risk management decisions. Eventually, I can see organizations using SBOMs to continuously update their maps of their software supply chains that can help to drive decisions in the most cost-effective and secure manner possible.
Q: How can developers consume SBOM information from the public repositories they pull code from?
When using open-source code, SBOMs are most useful in understanding the first-, second-, and third-level—and even deeper—dependencies of the library in question. While this information is generally already available, the key will be to develop systems and tools to evaluate it efficiently from a cybersecurity risk management perspective.
Even better would be if these open-source code repositories provided their own VEX reports identifying which vulnerabilities have been triaged and found not to be exploitable. Because open-source teams are generally working for free on hobby projects, this will probably take a long time to become reality. I think it makes sense to offer resources, expertise, and even money to project maintainers to enhance the security of the code they write. Google has taken some promising first steps, by incentivizing security researchers to find bugs in the open source software that Google maintains, for example.
Q: How does StackAware help with this SBOM consumption confusion?
Using a marketplace model, the product allows software publishers to continuously update SBOMs, choose who to share them with, provide real-time VEX reports, and even build custom vulnerability disclosure pages with the click of a button. By leveraging both open source or commercial software composition analysis and vulnerability prioritization tools, StackAware allows organizations to evaluate the risk posed by each identified security issue in a quantitative manner. Combining this with an asset inventory and business impact analysis even allows the tool to provide the financial risk of each individual vulnerability.
