Why Does My SBOM Show So Many Dependencies I Never Added? 🤔

When you looked at your SBOM of your project for the first time and ever thought:

Wait… why are there so many components here? I didn’t add half of these.”

Your eyes went to the components section — and suddenly there are names you don’t even recognize and looks like that you never imported these component, or never installed them directly. But the interesting thing here is:

Yet, they’re all listed as part of your software.

Confusing, right? But here’s actually a very clear reason for this.

Your software has dependencies which you have imported in your code and further you use it’s function for some functionalities. But here is the catch: these dependencies rely on further dependencies too. In an SBOM, each and every dependencies are described in detailed with much more information under components section.

At first glance, it looks like your SBOM is exaggerating — as if it’s throwing random component into your project. But what’s really happening is this: your project depends on some dependencies(libraries) directly, and those dependencies further depend on others.

That’s where the concept of direct vs transitive dependencies comes in.

Direct Dependencies (The Ones You Actually Added)

These are the components that you explicitly declared in your project.

For example, in a Go project, if your go.mod(sbomqs) says:

Here, fang is a direct dependency(i.e 1st level dependency) of sbomqs, you choose it and you pulled it in and you need it in your code at different places as per the requirement.

Here is how you use fang library in your code:

Along with fang, there are many direct dependencies of sbomqs, that are pulled directly for their use inside the project directly.

Transitive Dependencies (The Ones You Didn’t Know You Got)

Now here’s the catch: fang doesn’t work alone. It relies on other libraries like colorprofile, lipgloss, and cobra. These are not something you added directly — they came bundled in because fang needed them.

From your project’s perspective, these are transitive dependencies(i.e. 2nd, 3rd, or beyond level dependency). They’re still part of your software, and that’s why they show up in the SBOM.

So, when you see a SBOM with lot’s of components you never added by yourself, it’s usually the transitive dependencies.

A Simple Example with sbomqs

Let’s take the sbomqs project, which directly depends on fang. Let’s see these dependencies from SBOM of sbomqs project:

The main software sbomqs(golang/github.com/interlynk-io/sbomqs) directly depends on lots of dependencies which are shown below, out of them one is fang(golang/github.com/charmbracelet/fang@0.3.0).

Now, the fang too have it’s direct dependencies, out of which one is colorprofile(golang/github.com/charmbracelet/colorprofile@0.3.1). , w.r.t to fang, “colorprofile” is a 1st level dependencies, whereas w.r.t sbomqs, “colorprofile” is a 2nd level dependency.

Similarly, colorprofile has also it’s direct dependencies and out of which one is ansi(golang/github.com/charmbracelet/x/ansi@0.9.3). So, w.r.t to colorprofile, “ansi” is 1st level dependencies, whereas, w.r.t to fang it’s a 2nd level dependency and for sbomqs it’s a 3rd level dependency.

So, that’s how the chain of dependencies flows.

The “1st level” of dependency is known as “direct dependencies”, and beyond that, i.e 2nd, 3rd, 4th,…. nth level dependencies are all known as “transitive dependencies”.

Here’s the dependency tree visualization chain for sbomqs:

• fang is a direct(1st level) dependency of sbomqs.

• colorprofile is a direct(1st level) dependency for fang whereas transitive(2nd level) dependency for sbomqs.

• ansi is a direct(1st level) dependency for colorprofile, whereas transitive for fang and sbomqs with 2nd and 3rd level dependency respectively.

But, why these Transitive dependencies matters ?

You might be thinking:

Okay, cool. But why should I care?

Here’s why:

• Security – A vulnerability in a transitive dependency can still affect your software, even if you didn’t install it directly.

• Licensing – Every component, direct or transitive, carries its own license obligations.

• Maintenance – Updates or bugs in deep transitive dependencies can break your software unexpectedly.

In short: what you don’t see (transitives) can hurt you just as much as what you do see (directs).

Wrapping It Up

Remember that moment when you first opened your SBOM and thought: “Wait… I never added half of these components.”

Now you know the answer — those unfamiliar names are your transitive dependencies. They’re the ripple effect of the libraries you chose, each one pulling in what they need to work.

Far from being noise, this is your SBOM being honest. It’s showing you the complete map of your software supply chain — not just the packages you picked (direct dependencies), but also the hidden ones that tagged along (transitives).

So the next time your SBOM looks bloated, don’t think of it as extra baggage. Think of it as transparency. It’s the SBOM doing exactly what it’s supposed to: laying bare everything that makes your software tick.

✨ Direct dependencies are your choices. Transitives are their consequences. SBOMs show you both.