SBOMs and Transitive Dependencies
Software today is made up of more open source than anything else. When we use open source, it's common to use some sort of package manager to install dependencies. What we don't always think about is how dependencies we install also have dependencies of their own. We call these "dependencies of dependencies", transitive dependencies.
This is hard to understand, so let's use an example. I have an NPM project I've named "project" (very clever), and it has no installed dependencies to start
Let's install the axios package in our project. When we do an "npm list", we see our dependency.
That seems simple enough. Except what we need to run to get the list of all the dependencies is "npm list -a"
Holy cow, where did all that stuff come from!
Those are what we call transitive dependencies. axios needs many NPM packages to work, and some of those packages also need packages. You can see from the tree structure how everything is connected.
What about SBOMs?
So what does this have to do with SBOMs? When conversations happen around SBOMs and dependencies, transitive dependencies like to come up. There are two camps you'll hear about. The first thinks transitive dependencies shouldn't show up in an SBOM, and the second will tell you the job of an SBOM is to show everything.
The idea being if I generate an SBOM for the above project, should we only show the axios package, or should we show axios plus all those other things that were installed?
I'm of the second camp. The job of an SBOM is to show everything.
The devil is in the details though. The example above is simple. It's an NPM project that installs other NPM packages. What happens when you have something more complex. Like a container image based on Debian, that installs a python package using pip, and that python package contains an OpenSSL binary? That's much harder to understand and figure out. Now we have to detect DEB packages, python packages, and binary libraries.
It's likely anyone who doesn't think an SBOM should contain all the transitive dependencies doesn't want to deal with this complexity, or has an SBOM tool that can't traverse the dependency tree.
If you're using an SBOM scanner and it misses something, that's a bug. Be sure to tell whoever writes the scanner about the thing it's missing. Do keep in mind the world of detecting software is very large. It's possible they know, or are working on it, or have other high priorities at the moment. If it's an open source project, you could even submit a patch to detect new things.
What's the point
Now that you know what a transitive dependency is, you can start to look for them. If you're generating SBOMs for your product, do some digging to understand if the scanner really found everything. If you're using SBOMs from a vendor, trust but verify. And if you're using an open source SBOM scanner (and many of them are), give them plenty of patience. Or better yet, get involved!
Tech Lead
2moAnd people shipping software should generate their SBOMs on the release assets, not the source code lock files, because there can be some surprising additions e.g. https://github.com/electron/electron/issues/47468 Unfortunately a lot of tools dont yet allow scanning of packaging formats like MSI, DMG, etc. See https://github.com/anchore/syft/issues/3999
Open Source Engineering, Technology, and Security
2mo“Yes and…” of course the SBOM should contain the transitive dependencies since you want accurate records. But when using the SBOM to check for vulnerabilities, we have to consider cases where you find them in a transitive dependency. That’s where it gets complicated since sometimes you can’t update the direct dependency. Sometimes the vulnerable code is not reachable. But sometimes you have to deal with the need to break the package manager and introduce an untested configuration.
Operationalizing SBOMs throughout the SSDLC
2moI get questions about the ability to detect transitive dependencies all the time. It's one of these questions people feel the need to ask until they hear the answer. If they exist, you get them from the build tool for free.
Hunted Labs - Find and Remove Adversarial Foreign Influence
2moThis question is way less of a handwringing dilemma if you are containerizing your apps, since all of the transitive dependencies get resolved at image build time (it's easier in most cases at this point to report all dependencies than to try to filter the transitives out).
AppSec Tools Builder | Founder, AppThreat
2moWearing the security hat: dependency tree is one of the useless pieces of information for an appsec user. Many adversaries and exploit chains can exploit vulnerabilities regardless of where the libraries are in the filesystem, classpath, nodepath, etc. Plus, most SBOM tools plot the pre-build dependency tree from the lock files, and SCA scanners would present this tree along with vulnerabilities in post-build and deployed images as if the SDLC phases don't matter. Users must be asking for reachability evidence instead of dependency tree and tool vendors must start presenting granular evidence of "when, why, and how" a given library gets loaded, used, reached, etc.