Use an allow list if you want unknown licenses to stop a build, and a deny list if you want a short list of banned licenses and can tolerate surprises. Most teams that care about legal exposure choose an allow list, then handle exceptions by hand.
The two approaches
An allow list names the licenses you accept, usually as SPDX identifiers. Anything not on the list fails. A deny list names licenses you refuse. Anything not on the list passes.
| Question | Allow list | Deny list |
|---|---|---|
| What happens to a new, unusual license? | Fails until reviewed | Passes silently |
| Setup effort | Higher at first | Low |
| Maintenance | Add licenses as you approve them | Add licenses as you meet bad ones |
| Risk | Noisy early on | Misses what you did not think of |
A detail that catches teams out
The GitHub dependency review action documents these behaviours. Allow and deny options cannot be used together, and supplying both raises an error. The deny option is marked deprecated and may be removed in the next major release. And if a dependency's license cannot be detected, the action reports it but does not fail.
That last point defeats a naive allow list. An unknown license is exactly what you wanted to catch, yet it passes. Close the gap with a second check that fails on blank or unresolved license fields, or at least lists them for a person to review.
The action also takes license data from ClearlyDefined, and licenses marked OTHER are converted to a LicenseRef string, so your list must use that converted string. License checks are not available on GitHub Enterprise Server.
Steps for a workable license gate
- Inventory current licenses across repositories.
- Group them: clearly fine, needs review, not acceptable.
- Build the allow list from the first group.
- Route the second group to a named reviewer with a time limit.
- Treat "unknown" as its own category with an owner.
- Record each approval with a reason and a review date.
Scope the gate to what ships
A license that applies on distribution matters less in a build tool that never leaves your CI runner. Decide whether dev dependencies are in scope, and write that down. Legal questions about specific licenses belong with counsel, not with a scanner.
Try it yourself
Open the dependency inventory demo and look at how each component carries a license alongside its version. Spot which ones a strict allow list would flag.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning records license data per component, and its policies can gate on it. The free scan at gold.safeguard.sh/scan shows what your repository contains today.
Quick check
Can I use both lists together?
Not in the action described above, which raises an error if both are set. Pick one model.
Should an unknown license fail the build?
For most teams, a person should look at it before release. Whether it blocks the merge or opens a review task is your call.
Sources
Last reviewed: 19 October 2026.
