Your SBOM lists many packages because every package you add brings its own packages, and those bring more. You chose a few of them (direct dependencies). The rest arrived automatically (transitive dependencies). A long list is normal. The skill is knowing which entries deserve your time.
TL;DR
- Direct dependencies are the packages you chose. Transitive dependencies are the packages those packages need.
- Current CISA guidance says an SBOM should include transitive dependencies and sets no minimum depth.
- A long list is a sign of a complete inventory, not a sign of a mess.
- Use the dependency relationships in the SBOM to find where each package came from, then use reachability to decide what to fix first.
Definition. A transitive dependency is a package your software needs only because another package you use needs it. You never asked for it by name, but it ships with your software anyway.
What is a direct dependency, and what is a transitive one?
Picture a sandwich shop. You order a club sandwich. The sandwich needs bread, turkey, cheese and mayonnaise. Those are the things you ordered, in a sense. The mayonnaise needs eggs and oil. You did not order eggs, but they are in your lunch.
Software works the same way.
- Direct dependency: a package you named in your project, such as a library for handling dates.
- Transitive dependency: a package that your date library needs, and the packages those need, and so on down the chain.
The NTIA framing document, written by industry and government stakeholders, describes the same idea with a "multi-level" bill of materials, like the ones used for physical goods. An upstream component, often called a dependency, is included in a downstream component. A component can have its own upstream components, which can have their own.
That is why a project with a dozen packages you picked can end up with hundreds in total.
Does an SBOM have to list the transitive ones?
Under current guidance, yes. The 2026 Minimum Elements for a Software Bill of Materials, published by CISA with agencies from many countries, says an SBOM "should include information for all components that make up the target software, including transitive dependencies. There is no minimum depth."
The reason is practical. The same document says a person who reads an SBOM should be able to conclude that a new vulnerability does not affect them if the SBOM does not list the affected component. That only works if the list is complete. If transitive packages were left out, "not listed" would not mean "not present."
CISA's SBOM FAQ is more relaxed. It says the minimum viable model for a machine readable SBOM was one layer deep, with the goal of recursing up the supply chain. It also notes that for most uses, more complete SBOMs give greater value. The 2026 guidance goes further than that one layer starting point.
Why do the same package names appear more than once?
You may also see one package listed twice with different versions. The 2026 guidance covers this. It says that if there are multiple instances of a component with differences in metadata, each instance should be listed separately with the right dependency relationship.
This happens when two of your dependencies need different versions of the same helper. Both versions get installed, so both are in the software, and both belong in the inventory.
This also affects counting. "How many packages do I have?" has two honest answers: how many unique names, and how many instances. Pick one and say which when you report it.
How do I read the dependency tree?
An SBOM records relationships, not just a flat list. The 2026 guidance calls this the Component Dependency Relationship. It says the data "specifies the relationship between the target component and one of its subcomponents and supports the capability to build a dependency graph."
Here are the steps to trace an unfamiliar package back to its source.
- Find the package in the SBOM. Search by name or by its package identifier.
- Look at what depends on it. The relationship data shows which component includes it.
- Walk up the chain. Repeat until you reach a package that you chose yourself.
- Write down the direct dependency at the top. That is the one you can upgrade, replace or remove.
- Check whether a newer version of that direct dependency drops or updates the problem package. Often one upgrade fixes several deep entries.
This is also how you handle a security alert about something you have never heard of. You do not fix the deep package directly most of the time. You update the direct dependency that brought it in.
Worked example: a small app
The numbers here are invented to show how the math works. They are not from a real project.
| Layer | What it is | Invented count |
|---|---|---|
| Direct | Packages the team added on purpose | 14 |
| Transitive, level 1 | Needed by the direct ones | 62 |
| Transitive, level 2 | Needed by level 1 | 118 |
| Transitive, level 3 and deeper | Everything further down | 96 |
| Total in the SBOM | 290 |
Only 14 of 290 entries (about 5 percent) are packages someone on the team picked. The other 276 arrived on their own.
Now say a scanner reports a problem in a level 3 package. Walking up the tree shows it comes in through one direct dependency, a charting library. The team checks the charting library's release notes, finds a newer version that no longer uses the affected package, and upgrades once. One change clears the alert.
Without the tree, the team would have searched for the deep package by hand, found nothing to upgrade, and stalled.
How do I stop a long list from becoming a long to do list?
A complete list creates many alerts. Most of them will not matter for your software. CISA's paper on SBOM types makes a related point. A source based SBOM can show components that never run or that are compiled out of the finished product.
Two habits help.
- Check reachability. Ask whether your code actually calls the risky part of a package. A package can be present and never used in a dangerous way.
- Share the answer. If a customer's scanner flags something that does not apply, a VEX statement lets you say so in a standard way. VEX stands for Vulnerability Exploitability eXchange. The OpenVEX specification lists statuses such as not affected, affected, fixed and under investigation, and a "not affected" status must come with a reason.
For more on this, see how to build a VEX document for consumers and the missing context that makes SBOMs actionable.
Try it yourself
In the demo below, watch how a large number of findings shrinks once the tool checks which ones your code can actually reach. Pay attention to the difference between "present" and "reachable."
Click through it at your own pace, or open it full screen.
How can Safeguard help?
Safeguard's SBOM and dependency scanning builds the full inventory, direct and transitive, and exports SBOMs in SPDX and CycloneDX. Reachability analysis marks which vulnerable packages your code can actually reach, so you start with the entries that matter. When a fix is available, autonomous remediation can open a fix pull request for you to review. It is off by default, and every category starts on Manual.
You can try a free scan at gold.safeguard.sh/scan. The Safeguard CLI and IDE extensions put the same scanning inside your normal workflow, and the CLI can also write code when a fix needs a change.
Quick check
Is it bad if my SBOM has hundreds of packages?
No. Modern software is built from many reusable parts, and each part has its own parts. A long list means the inventory is complete. What matters is knowing which entries you can act on.
Do I fix a vulnerable transitive package directly?
Usually you update the direct dependency that brought it in. Trace the package up the dependency tree to the top, then check for a newer version of that direct package.
Why is the same package listed twice?
Two of your dependencies may need different versions of it. Both versions are in your software, so current guidance says each instance should be listed separately.
Sources
- CISA and partners, 2026 Minimum Elements for a Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- NTIA, Framing Software Component Transparency, Second Edition: https://www.ntia.gov/page/software-bill-materials
- CISA, SBOM FAQ: https://www.cisa.gov/resources-tools/resources/sbom-faq
- CISA, Types of Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom
- OpenVEX Specification: https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md
Last reviewed: 19 October 2026.
