Say that new dependencies pass an intake check before merge: maintenance activity, known vulnerabilities, license fit, project security practices and need. State who approves, what is automatic and what is manual, and that the decision is recorded. Offer one sample record as evidence.
What to check at intake
| Check | Question | Typical source |
|---|---|---|
| Need | Can existing code or the standard library do this? | Reviewer judgment |
| Maintenance | Recent releases, active maintainers? | Repository history |
| Vulnerabilities | Known advisories, and were they fixed promptly? | Advisory data, scanner |
| License | Compatible with how we ship? | License scan |
| Project practices | Does the project follow basic security practices? | OpenSSF Scorecard |
| Transitive weight | What else does it pull in? | Dependency tree |
OpenSSF Scorecard runs 18 automated checks across holistic security practices, source risk and build risk, including branch protection, code review, dependency update tools and signed releases, and it is intended for evaluating a project before adopting it. Treat the score as one input. A low score on a tiny, well-reviewed library may matter less than a high score on a sprawling one.
Make it automatic where you can
Block merges that add a package with a critical known vulnerability or a disallowed license. Flag packages with very recent first publication or a name close to an existing popular package for manual look. Leave the rest to a lightweight reviewer check inside the pull request. See open source policy template for a policy template.
Approval rule
A simple rule is enough: any engineer can propose, a code owner approves, and the security team is pulled in only when automated checks fail or the package is in a sensitive area such as authentication or cryptography.
Record the decision
Put the reason in the pull request description or a short register: package, version, reviewer, date, checks passed. That record is your evidence and helps when a package later becomes a problem.
A model answer
"New dependencies require review at pull request time. Automated checks cover known vulnerabilities, license and the package's maintenance and project health signals. A code owner approves each addition, and we escalate to security for sensitive areas. Decisions are recorded in the pull request."
Pitfalls
Claiming a formal approval board when the real process is one engineer checking. Ignoring updates: a package approved once can degrade, so rescan regularly.
Revisit approved packages
Approval is not permanent. Maintainers leave, projects go quiet, and ownership of a package can change hands. Rescan approved dependencies on a schedule, and set a rule for when a package loses support: who decides on a replacement and how soon. Mention this in your answer, because buyers often ask what happens after the first approval.
Quick check
Do we vet transitive dependencies the same way?
Automatically scan them all, and review manually only the notable ones, such as unusually large additions.
Is a high Scorecard result a guarantee?
No. It measures practices, not the absence of flaws.
Safeguard provides dependency scanning, policies and gates that can enforce intake rules, with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
