Yes. Write one open source policy with a license section and a security section, and run one review per package. The same dependency raises both questions, and two separate processes mean two queues, two answers and developers who skip both.
Why combine them
A reviewer looking at a new package needs to know its license, its advisory history, who maintains it and where it will run. That is one set of facts. If legal and security each review in isolation, the team waits twice and may get conflicting answers.
A single record also helps later. When a customer or auditor asks how you manage open source, one policy and one list of decisions is easier to show than two.
Structure of the policy
| Section | Contents |
|---|---|
| Scope | What counts as open source, which products and environments are covered |
| Roles | Who approves, who owns packages, who handles exceptions |
| Intake | How new packages are requested and tiered |
| License rules | Allowed, review needed and not allowed groups, with conditions for shipped software |
| Security rules | Response times by severity, rules for unmaintained packages, minimum conditions for approval |
| Exceptions | Request, approver, reason, expiry date |
| Records | What is stored, where and for how long |
Keep it short. A long policy is not read, and an unread policy cannot be enforced.
Where the two rule sets interact
- A package with an acceptable license but no active maintainer may need a risk acceptance, not just a pass.
- A permissive license does not make a vulnerable version acceptable.
- A fix may arrive only in a version under a different license. A license change during an upgrade should trigger review, not slip through.
- Packages that ship to customers carry stricter license duties than internal tools, and may also carry stricter vulnerability timelines.
Plan for those interactions in the policy text. Say which team decides when the two rule sets disagree, and give the decision a time limit.
Enforcement
Put the checks where developers already are: the pull request. A gate can read the lockfile, compare each added or changed dependency to the license and security rules, and report a clear reason. Start in report only mode, fix noisy rules, then enforce for the highest risk findings.
Try it yourself
Click through it at your own pace, or open it full screen. See how a single gate can report on more than one kind of rule.
Quick check
Who should sign off on the combined policy?
Legal for the license section, security for the security section, and an engineering lead for feasibility. One executive owner should be named for the whole.
Is a single review slower?
Usually it is faster, since reviewers see the same facts at once. Automate the low risk path so people only see unusual cases.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
