Telecom maps its open source blast radius.

Situation

The company was a regional telecom carrier running several hundred services across network operations, billing, and customer facing portals. Like most carriers of its size, it had built heavily on open source, including infrastructure automation tools and a database layer adopted years earlier under permissive and open source licenses. Engineering was decentralized across many teams, each making its own technology choices, and no single inventory described what the estate as a whole depended on.

The exposure that triggered the work

The relicensing wave landed on several tools the carrier used. As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1, which restricts competitive production use. As of March 2024, Redis moved to the Redis Source Available License and the Server Side Public License. Source available is not open source, and neither license is approved by the Open Source Initiative. The board read about the changes in the trade press and asked a direct question: how much of our network and our revenue systems depends on these tools, and what does the change cost us. No one could answer, because no one held a map. The decentralized structure that had served delivery well had left the company without a single view of its own exposure.

Approach

We began with inventory across every team. Software composition analysis ran against each service to produce a software bill of materials that reached the transitive layers, where most of the exposure turned out to hide. We then flagged the components whose terms had changed, checking current project state rather than trusting the declared license in each manifest. With the affected components identified, we traced the dependency tree outward from each one to every service and product it touched.

The map was wider than the teams expected. A handful of relicensed components fanned out into a large share of the estate through transitive paths no one had charted. We then classified each touch point by use: internal only, customer facing, or part of a revenue system where the new terms could apply. Finally we sized the material nodes, estimating the cost of exposure if the risk landed and the cost to cure it, and ranked them so the work would follow the money rather than the alphabet.

Outcome

The finished blast radius map reduced a worry about hundreds of services to a ranked list of fewer than twenty material nodes, each with a use classification, a sized exposure, and a recommended path. Most touch points were internal and carried little risk under the new terms. The concentration of real exposure sat in a small number of revenue systems, where the carrier chose a mix of migration to open forks and a scoped commercial conversation, sequenced over the following two quarters. Just as important, the inventory built for the mapping became a standing asset. The estate now carries a current software bill of materials that flags any future license change at the next refresh, which closed the visibility gap that had left the board question unanswerable in the first place.

Lessons for buyers

Three lessons carry to other buyers. First, decentralization is efficient for delivery and dangerous for exposure, because it spreads risk across teams without a single place to see it. A central map is the cure. Second, the transitive layer is where the real reach lives, so a map that stops at direct dependencies offers false comfort. Third, the value of ranking is in what it removes, not just what it surfaces. By cutting hundreds of services down to a short, sized list, the carrier could act decisively rather than drown in an undifferentiated inventory.

Mapping a blast radius at this scale is the work of our open source license risk assessment service. For the wider frame, read our pillar on open source license risk and the method behind it in how to map your open source blast radius.