License risk in your CI CD and build tooling.

License risk in your CI CD and build tooling is easy to overlook because the pipeline feels like infrastructure rather than software. Teams inventory the application and its dependencies, then treat the machinery that builds and ships that application as fixed plumbing. The build orchestrator, the provisioning tool, the container base image, the plugins that glue them together: all of it runs every day, all of it is open source or was when it was adopted, and almost none of it sits on a license register. When one of those components relicenses, the change lands in the one part of the estate nobody is watching.

That blind spot is the subject here. We walk through how the pipeline accumulates dependencies, why a relicensed build tool can reach further than internal convenience, which named tools are already affected, and how to inventory the pipeline properly. For the full context, the pillar on open source license risk sets out the wider picture.

Why the pipeline is the blind spot

A pipeline grows by accretion. A team adds a provisioning step, wires in a plugin, pins a base image, and bolts on a scanner, each decision sensible on its own day. Years later the pipeline is a dense stack of tools and the people who chose them have moved on. The result is software that the organization depends on completely but tracks barely at all. Because the pipeline rarely ships to customers, it falls outside the inventory built for the product, and because it keeps working it never demands attention. License risk thrives in exactly that kind of quiet, reliable, unwatched layer.

Transitive depth makes it worse. A single build plugin can pull in a tree of libraries, any one of which may have changed terms. The same dynamic that hides license exposure in application dependencies operates in the pipeline, only with even less visibility. We treat that pattern in detail in transitive dependencies and hidden license risk.

How a relicense enters the build chain

The mechanism is the same one that affects application code. A new license usually governs new versions, not the release you already pinned. Pipelines update constantly. Base images get refreshed for security, tools get bumped to fix a build break, plugins follow their own release cadence. Each of those routine updates can carry a new license. The moment your build pulls a newer version released under restricted terms, your use of that tool is bound by them, and no procurement gate ever fired because nobody treats a build dependency as a purchase.

The licenses that matter most are the Business Source License and the Server Side Public License, neither of which is OSI approved open source. The Business Source License restricts production use that competes with the vendor and converts to an open license after a delay, commonly four years. The Server Side Public License attaches a copyleft style condition aimed at parties offering the software as a service. A build tool under either license is not a neutral piece of plumbing. It is a component with terms attached, and those terms can shape how you are allowed to operate.

Which build tools are already affected

The clearest example sits in many pipelines today. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023, and IBM later acquired HashiCorp. Terraform provisions infrastructure, Packer builds images, Vault handles secrets, and all three are common pipeline fixtures. If your build pulls newer releases of any of them, the new terms apply to that use. The community fork OpenTofu exists for teams that need an openly licensed provisioning path, and the broader fork story is told in the OpenTofu and Valkey fork story.

Databases and caches that pipelines spin up for integration tests carry the same question. Redis moved to a Redis Source Available License and Server Side Public License model as of March 2024, with the fork Valkey, and Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021, with the fork OpenSearch. A test harness that pulls a current image of any of these is using software under restricted terms. The point is not that any single use is automatically a violation. It is that the pipeline contains licensed components you have not been tracking, and you cannot reason about exposure you cannot see.

When build tooling reaches the product

A common assumption is that the pipeline is purely internal, so its licenses cannot matter. That holds less often than people think. If a relicensed tool provisions the service you sell, builds the artifact you distribute, or runs inside a product you ship to customers, its terms can reach the way you make money rather than just the way you work. Competitive use conditions and service provider conditions are written precisely to cover those situations. The line between internal convenience and commercial operation is exactly where the Business Source License and the Server Side Public License are designed to bite.

This is why the pipeline belongs inside the blast radius rather than outside it. A relicensed component in a shared build platform reaches every team and every product that platform serves. Tracing that reach is the same discipline as mapping any other exposure, and we set it out in how to map your open source blast radius.

How to bring the pipeline under control

Start by inventorying the pipeline as carefully as you inventory the application. List every tool, plugin, base image, and runner, with the version in use and the current license state of each. Then identify which of those have changed terms and which versions you actually run, because the gap between the latest release and your pinned version is where the answer lives. Where a relicensed tool sits on the critical path, decide between an openly licensed fork, a pinned older version with its security trade, or a negotiated commercial license, and size each option honestly. Most pipelines also keep changing, so the inventory has to be refreshed rather than filed, a discipline we cover in the hidden open source exposure in production.

License risk in your CI CD and build tooling is not exotic. It is ordinary risk hiding in a layer nobody looks at, and the fix is to look. Bring the pipeline into the same map as the rest of your estate and the exposure becomes a tracked, sized, manageable item rather than a surprise an auditor finds first. This article is commercial and licensing risk advisory, not legal advice. For interpretation of a specific license and your compliance position, your own counsel is the right place to turn.