License compliance in CI/CD: what to set up first, second and third

Set up license compliance in CI in order: build an inventory, normalize names to SPDX identifiers, write a policy per delivery mode, run it in report-only mode for two weeks, then start blocking. Blocking first, before you know what is already in your tree, only teaches developers to bypass the check.

Teams usually start by buying or installing a checker, switching on "fail the build on GPL," and watching forty pipelines go red. This guide puts the steps in the order that avoids that.

What do you need before you automate anything?

A shared vocabulary. The SPDX License List gives each common license a standard short identifier, such as MIT or Apache-2.0, and defines expression operators. SPDX expressions let a package say MIT OR Apache-2.0 (you pick one), AND (both apply) or WITH (a license plus a named exception). If your tool does not parse expressions, a dual-licensed package can look like a violation when it is not.

Step 1: what is the inventory?

You cannot check licenses you have not listed. Generate an inventory from each repository, including transitive packages. The Safeguard CLI is one way to do it on your own machine:

safeguard scan --dir . --output ./output

The CLI docs say the results include a license.json file alongside the vulnerability output. They also state there is no CLI command yet for license reports or policy evaluation, so for now the file is your raw material, and the policy lives in the platform.

Step 2: how do you normalize names?

Map whatever the registry says to SPDX identifiers. Expect messy data: missing fields, free-text names, and files that disagree. Safeguard's license documentation describes reconciling package metadata, license files and headers, and raising a discrepancy when they disagree. Whatever tool you use, route "unknown" to a human queue, not to a pass.

Step 3: what are your delivery modes?

The same license means different things depending on how you ship. Write down which of these you have: hosted service, on-premises install, mobile app, shipped library or SDK, internal tool. AGPL and similar network licenses matter most for hosted software. Strong copyleft matters most when you distribute. Safeguard's docs show a policy that allows a license for a server binary but denies it for an SDK, which is the idea in practice. Have counsel review the rules, because this guide is not legal advice.

Step 4: what does the first policy say?

Keep it short and in three buckets.

1. Allowed: permissive licenses you have reviewed.
2. Needs review: weak copyleft, unknown, custom.
3. Blocked: licenses your counsel has ruled out for a given delivery mode.

Start with the buckets matched to your real inventory, so day one has few surprises.

Step 5: how do you roll it out in CI?

Run the policy in report mode first. In Safeguard, a policy has an action: Block fails the gate, Warn passes it with a warning, and Notify passes it and sends a message. Start every license policy as Warn for two weeks. Read the warnings, fix the policy, and only then switch the clear violations to Block.

When you do, the docs describe a CI command that waits for the scan and fails the job if the gate fails:

safeguard ci scan --wait --fail-on-gate GATE_NAME

The docs say policy outcomes must be turned on for your workspace, and that the plain scan command exits 0 whatever it finds, so gating is done by the platform, not by the scan exit code.

Step 6: how do you handle exceptions?

Every real project hits one. Require a named approver, a reason and an expiry date, and re-check at expiry. Without expiry dates, exceptions become permanent policy by accident.

Step 7: what do you ship alongside the build?

Keep a third-party notices file and the license texts for shipped artifacts. Safeguard's documentation says attribution generation is not available as a CLI command yet, so produce it from your inventory with whatever script or tool you already have.

What are the limits?

Automated detection can be wrong, especially for files with mixed licenses, vendored code and binaries. A tool reports what it can read, and the legal conclusion is yours to make. Dual licensing, license exceptions and non-English law all change the answer.

What to do

1. Generate an inventory for every repository you ship.
2. Convert license names to SPDX identifiers and flag unknowns.
3. List your delivery modes and mark what each license means for them.
4. Write the three-bucket policy and have counsel review it.
5. Run it as Warn for two weeks, then move clear violations to Block.
6. Add exceptions with approvers and expiry dates.
7. Generate third-party notices for every release.

Quick check

Sources

• SPDX License List
• SPDX license expressions
• Safeguard CLI usage
• Safeguard license compliance
• Safeguard policy outcomes and actions

Last reviewed: 18 October 2026.