Scan licenses at three points: on every pull request that changes dependencies, on a schedule across all repositories, and at release when you build notices. Each catches something the others miss, and together they cost little compared with finding a problem after you ship.
What each trigger catches
| Trigger | Catches | Action |
|---|---|---|
| Pull request | A new or upgraded dependency with a disallowed license | Block or ask for review before merge |
| Scheduled scan (nightly or weekly) | A dependency whose license metadata changed, or a rule that changed | Open a ticket, notify the owner |
| Release build | Gaps in the notices file, unresolved unknowns | Fail the release |
| Event driven | A relicensing announcement on a package you use | Targeted check |
Licenses can change between versions. A package you approved may adopt a different license in a later release. See what to do when a dependency changes license. A scan only on pull requests never sees the change if nobody bumps the version, and a scan only at release sees it too late.
Setting a cadence
- Start with the pull request check, since it prevents new debt.
- Add a weekly portfolio scan. Move to nightly if you ship daily.
- Make the release job fail on unknown licenses and missing notice text.
- Send results to the owner of the repository, not a shared inbox.
- Review scan failures weekly so tickets do not go stale.
Keep the signal clean
Too many alerts teach people to ignore them. Tier your rules so only denied licenses block, unknowns go to review, and allowed licenses stay silent. See allow, review, deny tiers.
A word on policy changes
When legal changes the policy, rescan the whole portfolio the same day. The code did not change, but the answer might.
Try it yourself
Click through it at your own pace, or open it full screen.
See how monitoring picks up change over time and think about which of your checks should run on a schedule.
If you only have time for one improvement, add the scheduled portfolio scan. It is the check that notices change you did not cause. Pair it with an owner for each repository and a short service level for resolving findings, so results turn into decisions and not into a growing list.
Teams with many repositories can stagger scheduled scans across the week to spread load and keep results readable. Whatever the schedule, publish it, so engineers know when to expect new findings and who is looking at them. A scan nobody reads adds cost without lowering risk.
Safeguard offers dependency scanning with policies and gates, plus a free scan to start from.
Quick check
Is a pull request check enough?
No. It misses changes that arrive without a code change, such as a new advisory or policy edit.
Should unknown licenses block a release?
Usually yes at release time, after they have had time to be resolved earlier in the cycle.
Last reviewed: 19 October 2026.
