One SBOM is good, more SBOMs are better. Tracking a single piece of software's SBOMs across versions and time can reveal a lot of interesting information and through analysis can be used to understand how your risks change over time. Be able to answer questions like When did you fix that vulnerability? What is the progress of moving off of BSL licensed software?

Similarly by keeping multiple SBOMs for different software, e.g. as part of a large environment or organization you can understand shared risks. Does a vulnerability impact one piece of software or multiple? Are you using the same logging library across your Go applications or are you using multiple different ones?

We will look at how a lot of open source tools from the simple like jq to the more complicated like DuckDB and GUAC can be used to track and analyze SBOMs over time and across environments to answer the questions you have about your software.