Run them in parallel from a single request, with separate owners and separate decisions. Security asks whether the package is safe to run. Licence review asks whether you may use and distribute it as planned. Neither approval substitutes for the other, and either can block.
Why one request, two gates
Teams often bolt licence review onto the end of a security review, or the reverse. The result is a package that clears one gate, gets half adopted, then fails the other. Reversal is expensive once code depends on it.
A single intake form avoids that. The developer describes the package, the version, the purpose and how it will be used. Both reviewers read the same request, so the facts match.
What each gate decides
| Question | Security gate | Licence gate |
|---|---|---|
| Core question | Is it safe to run here? | May we use and ship it this way? |
| Typical inputs | Advisories, maintainer activity, install scripts, transitive packages | Declared licence, licence of transitive packages, how it is linked or distributed |
| Typical owner | Application security | Legal or open source programme office |
| Possible outcomes | Approve, approve with conditions, reject | Approve, approve for internal use only, reject |
| Re-review trigger | New advisory, ownership change | Licence change in a new version |
Licence review involves legal judgement. Nothing here is legal advice, so route licence questions to qualified counsel in your organisation.
A two-gate flow
- The developer files one request with package, version, purpose and distribution (internal tool, hosted service, shipped product).
- Automated checks run first: known vulnerabilities, declared licences, and the transitive dependency list.
- Security and licence reviewers work in parallel, each with a target turnaround.
- Each reviewer records a decision, conditions and a date in the ticket.
- The package enters the approved list only when both decisions are approve.
- If one gate says approve with conditions, the conditions become tracked tasks with owners.
Handling disagreement
Sometimes security approves and licence blocks. The ticket should show both decisions and the final outcome, not a quiet withdrawal. Keep the rejection reason, because the same request will come back next year.
When the licence depends on how you use the package, record the use. Approval for an internal tool does not stretch to a product you ship. See our notes on build time or shipped dependency licences for that distinction.
What to keep as evidence
- The original request.
- Both reviewers' decisions with names and dates.
- The scan output used for the security decision.
- The licence report, including transitive packages.
- The approved list entry linking back to the ticket.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how direct and transitive packages are listed together, which is the input both gates need.
Quick check
Does a permissive licence mean the package is secure?
No. Licence and security are independent properties. A package can have a permissive licence and a serious flaw, or the reverse.
Who should own the approved list?
Pick one owner for the list itself, often the platform or application security team, with the licence reviewer owning only licence decisions.
Safeguard produces the dependency inventory and policy checks that feed both reviewers, and you can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
