Another Step on the Security Journey: A Constellation of SBOMs
Comparing two SBOMs is useful, but as your portfolio grows, you need to take a holistic approach.
Michael Lieberman
March 18, 2025
.jpg)
Nobody goes from zero to fully-mature software supply chain security in one giant leap. You take smaller steps along the way. After all, security is a journey, not a destination. In the previous post, you saw how the Whiskey Tasting Foundation went from one software bill of materials (SBOM) to several. They struggled to analyze the differences, so now they turn to a new tool.
Beyond simple SBOM comparison
The previous post covered some use cases for comparing SBOMs between releases. Just like in debugging an application, the first step to understanding is knowing what changed. Did a new version introduce new dependencies? Did dependency versions change? Which vulnerabilities were introduced? Which were remediated? Do any of the dependencies have a different license?
These are all very important questions to be able to answer, but if your view is focused on versions of a single application, you’re going to miss out on important insights. As the Whiskey Tasting Foundation began creating a backend and mobile applications, they realized they had questions about the entire ecosystem.
When a new vulnerability is announced, the Foundation wants to quickly know which application(s) are affected. Do each of the affected applications have to be fixed individually because they all directly depend on the vulnerable library? If they’re lucky, the vulnerability gets pulled in by a shared internal library so they only have to fix it one place. But knowing this makes the response faster and easier. Not to mention that it helps ensure applications stay fixed. An alarming number of applications are still vulnerable to log4shell years after that vulnerability was announced.
Once the vulnerabilities are managed, there are other things to know about the supply chain. What are the most widely-used dependencies? Which upstream projects have a weak security posture? Which are in need of more contributors? Knowing the answers to these questions gives the Whiskey Tasting Foundation guidance on where to invest their resources into upstream work. They can proactively work to shore up their supply chain to prevent future vulnerabilities.
As you saw in previous posts, SBOMs are the foundational piece for securing the software supply chain. There are a few problems, though. First, not all SBOMs contain the same richness of information that they’re supposed to have. Second, even the best SBOMs don’t include all of the information the Whiskey Tasting Foundation needs. Finally, there are multiple SBOM formats. How can the Foundation enrich and manage all of their SBOMs holistically?
Enter GUAC
GUAC (Graph for Understanding Artifact Composition) is an open source project created by Kusari, Google, and Purdue University. Now an OpenSSF incubating project, GUAC provides a flexible and extensible tool for enriching and querying supply chain data. GUAC collectors pull in information from public and private sources to provide information about dependencies, licenses, vulnerabilities, build environments, and more.
The Whiskey Tasting Foundation creates SBOMs as part of their build pipeline which GUAC automatically ingests. This gives developers immediate access to information about the supply chain, allowing them to discover and fix issues quickly.
With GUAC’s powerful querying tools, the Foundation can ask questions of the supply chain for their entire application portfolio. This holistic view means they can work efficiently instead of trying to manage each application in a vacuum. As the Whiskey Tasting Foundation matures, they begin to think that running their own GUAC instance doesn’t quite give them what they need. Tune in to the final post to see what they do next.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Want to learn more?