You don’t know what you’re actually shipping

Why your dependencies are a moving target and your SBOM can't keep up.

Most developers can name every direct dependency in their project. But how many can account for the hundreds, sometimes thousands, of indirect dependencies hiding beneath the surface? In his presentation at All Things Open, Viral Chhasatia, an Open Source Engineer in the Open Source Program Office (OSPO) at AWS, shares why the tools you use to track your dependency tree matter just as much as the code you write.

Every software project sits on top of a dependency tree that grows in ways most developers don’t expect. You might select five direct dependencies, but each pulls in its own set, sometimes going six or seven layers deep. Docker containers that start with a base image and 20 installed packages can balloon to over 10,000 packages. That tree is never static either. Your dependencies shift based on when you build, what operating system you’re targeting, and whether you’ve pinned your versions. A Software Bill Of Materials (SBOM) generated three months ago may already be outdated.

Read more: SBOM’S: The essential foundation of open source security

That shifting landscape creates real risk around licensing. A project you selected for its permissive license might quietly pull in a transitive dependency under a restrictive or commercial license. These surprises tend to surface at the worst possible time, and the compliance stakes go up significantly when you move from internal use to distributing your software.

So how do you get visibility? Viral walks through demos across six ecosystems, using pip licenses and CycloneDX for Python, npm license checker for JavaScript, Maven dependency plugins for Java, go licenses for Go, cargo about for Rust, and Sift for Docker images. The common thread is that no single tool gives you the complete picture. Each package manager only sees its own ecosystem, so a containerized project built with multiple languages needs multiple tools. Go license information, for example, won’t surface properly unless you run the tooling inside your container. Viral emphasizes that developers should always review generated attribution notices for completeness rather than trusting any one tool blindly.

Key takeaways

• Your dependency tree is dynamic, shaped by build timing, operating system, and version pinning. Treat SBOMs as snapshots, not permanent records.
• Transitive dependencies carry hidden license risks that can conflict with your company’s policies or distribution requirements. Audit beyond your first order dependencies.
• No single tool covers every ecosystem. Use the right package manager tooling for each language in your stack and review the output for gaps.

The right combination of tools and regular audits keeps your compliance posture solid and your surprises to a minimum. Know that no tool is perfect and build a review habit around the output they give you.

📺 Watch the All Things Open “Extra’s” playlist

More from We Love Open Source

• Is your LLM lying to you?
• Zero trust Kubernetes: Context over credentials
• SBOM’S: The essential foundation of open source security
• How to secure agentic AI with Agent Identity Protocol (AIP)
• Stop opening firewall ports and start using identity