This article is the second in a series about SBOMs, software supply chains, the government and you.
I hope you are still hungry after the first article as more cake is available below!
If you have read the first article in this series that introduces SBOMs SBOMs: First Steps in a New Journey for Developers | Foojay.io then you already know how important they are and will be increasingly going forward.
It is great to have a software bill of materials, but the important part is what you do with it.
The relationship between Software composition analysis (SCA) and SBOMs is more complex than it might appear.
This article explains what an SCA tool is and how and where SBOMs connect.
What is an SCA Tool?
90% of the code in our applications comes from open-source libraries. Tracking where all that comes from, the licenses it uses, and any vulnerabilities it contains is too big of a task to accomplish without automation and tools. Not all SCA tools are created equal.
Some provide only high-level insight into your applications, and some are almost forensic in the level of detail they can discover.
You may be getting a little hungry again so here is some more cake to keep you entertained. By looking at your cake, you can immediately see some of the ingredients used, such as the jam, sponge and icing sugar.
That is what a basic SCA tool will be able to do. It can determine basic ingredients from the top-level, publicly declared dependencies, such as in your Maven build file (pom.xml).
Next-level SCA tools can determine the dependencies of the dependencies, it can detect what are called transitive dependencies. In the cake analogy, these types of SCA tools can tell you(for example), that the sponge part of your cake comprises other ingredients such as egg, flour and water.
The most capable tools would be able to report on unwanted elements such as fungi or harmful bacteria. Again, in software terms, these SCA tools hunt for hidden or obfuscated dependencies.
Back to software
Whatever list is generated by the SCA tool the next step is to check the contents against databases that contain critical information: typically vulnerabilities but also software licenses.
Some SCA providers use public databases, while others have their own researchers actively looking for code weaknesses.
Using the SCA results to provide useful and actionable information – licenses, vulnerabilities, dependency popularity, security posture etc. is a significant part of keeping software supply chains secure.
The better the tool, the better the available information: and the more secure your supply chain can be.
SBOMs and SCA
Quite a few SCA tools can provide an SBOM.
That’s a great step in allowing you to see what the SCA tool can discover. When looking for SCA tools, it might be interesting to compare the SBOM results from various ones to how effective they are at finding dependencies.
Multiple SCA tools can also consume an SBOM and then use their specific databases to search for vulnerabilities etc.
Why SCA-generated SBOMs are not the whole solution
It’s tempting to assume that generating an SBOM after you’ve built the application is all you need to do. There are three similar reasons for not doing so:
Your SCA-generated SBOM is only as good as the SCA tool itself. Vital information could be left out because the SCA tool was not smart enough to detect all the contents
Even the smartest SCA analysis can’t provide everything important. With the cake analogy – the best tools can detect (and infer) the presence of eggs but it can’t tell you where they came from, or what their supply chain looked like.
SBOMs are intended to be chained together. Each one referencing to the SBOM of each of its components. SCA tools can’t infer that from analysing your application. (Though some element of linking is theoretically possible)
We have done an initial dive into SCA tools and explained their relationship with SBOMs.
In future articles, we’ll examine what SCA tools can do in more detail and we’ll look deeper into the makeup of an SBOM and how it’s actually intended to be generated.