SBOM and dependency mapping for open source license risk.

Most enterprises cannot answer a simple question with confidence: what open source do we run, and under which license, today. The list that engineering keeps is partial. The list that procurement keeps is older still. Meanwhile the license terms of widely used projects have moved. SBOM and dependency mapping closes that gap. It produces one current map of every component, direct and transitive, with the license state attached to each one, so the exposure created by a relicense is visible rather than assumed.

The risk is not theoretical. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023. Redis moved to a dual model of the Redis Source Available License and the Server Side Public License as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. MongoDB moved to the Server Side Public License in 2018. Each change can reach software already running in your production estate. A bill of materials that does not record the current license cannot tell you whether any of this touches you.

What SBOM and dependency mapping delivers

We resolve the complete dependency tree for the systems in scope, then tag each node with its license as of the date of the scan. Direct dependencies are the easy part. The exposure usually hides in the transitive layer, the components you never chose but inherited through something you did. We trace those paths in full, because a source available license deep in the tree can carry the same commercial restriction as one at the top. The output is a software bill of materials in SPDX and CycloneDX, the two formats your customers and regulators already accept, plus a risk ranked view that puts the relicensed and copyleft components at the top of the list.

A static snapshot ages the day it is produced. We set up the map to refresh, so a future relicense is caught at the next scan rather than years later in an audit. The same artifact that answers a procurement questionnaire becomes the early warning system for the next license change. That is the point of the work: not a document for the shelf, but a living inventory wired into how you ship.

Why the buyer side matters here

We are an independent advisory, buyer side, with no vendor, no reseller arrangement, and paid only by you. That independence shapes the map. A tool vendor has an interest in the components its product flags. We have an interest only in an accurate picture of your exposure, including the parts that are uncomfortable to surface. When the map shows a Business Source License component sitting under a revenue system, you hear it plainly, with the cost to cure attached, not buried.

The mapping work connects to the rest of the program. It feeds the open source license risk assessment, supplies the evidence for a relicensing exposure review, and gives the governance and SBOM function the inventory it needs to enforce policy at intake. For the broader picture of how license risk is mapped and contained, see the open source license risk guide and the remediation and alternatives pillar.

How the engagement runs

We start by scoping the systems that matter, usually the production estate and the build pipelines that feed it. We resolve dependencies from your manifests, lockfiles, and built artifacts, then reconcile what is declared against what actually ships. We attach license state, flag the components that have relicensed since adoption, and rank the findings by where they sit and what they touch. You receive the bill of materials, the risk ranked view, and a short briefing in board language. From there the path is yours: most buyers move into a focused remediation plan or a relicensing exposure review, and the map carries straight into that work.

Source available is not the same as open source, and the Business Source License and the Server Side Public License are not approved by the Open Source Initiative. A map that treats every permissive looking name as safe will miss exactly the components that now carry a commercial restriction. Our mapping reads license state as it stands today, not as it stood when the component was first pulled in.

Where this fits with our case work

Accurate mapping is what makes the harder decisions defensible. In one engagement an acquirer relied on a dependency map to surface hidden Server Side Public License risk in a target before the deal closed. In another, an enterprise used a clean inventory to choose a fork over a license fee and contain the cost. See the acquirer finds hidden SSPL risk case study and browse the full case studies library for how the map turns into a decision.