Before merging a pull request that adds a dependency, ask whether you need it, what it brings with it, whether it has open advisories, and whether it looks maintained. Five questions and ten minutes catch most regrets, and each new package becomes your users' dependency too.
Why this review matters more for libraries
When you add a dependency to an application, you carry the risk. When you add one to a library, you pass it to everyone who installs you. A contributor adding a small helper package may also add its whole tree of transitive dependencies to your users.
The five questions
1. Do we need it? Can the standard library or a few lines of your own code do the job? A dependency used for one function is a candidate to decline politely.
2. What does it bring? Look at the diff of the lockfile. GitHub's dependency review shows dependencies added, removed or updated in a pull request, including indirect dependencies from lockfile changes, with release dates and vulnerability data. It is available for public repositories, and the dependency graph must be enabled.
3. Does it have known advisories? The same dependency review flags added dependencies with known vulnerabilities. By default, the dependency review action fails when it finds vulnerable packages, and you can set a severity threshold with fail-on-severity and license rules with deny-licenses. If your repository requires the check, a failing result blocks the merge.
4. Is it maintained and sensibly run? OpenSSF Scorecard turns this into checks you can read. Among its checks are Maintained, Security-Policy, Code-Review, Branch-Protection, Signed-Releases, Pinned-Dependencies and Vulnerabilities. Run it on the candidate:
scorecard --repo=github.com/owner/repo --show-details
Scorecard scores each check from 0 to 10 and combines them into a weighted aggregate. Treat the score as a prompt for questions, not a verdict. A low score on a tiny, stable package may be fine, and a high one does not rule out a compromise.
5. Does the license fit? Check it against your own license and your users' expectations. This is a compatibility check, not legal advice, so ask a lawyer if the answer is unclear.
Recording the decision
Ask the contributor to put the answers in the pull request description. Over time you will have a record of why each dependency exists. A template line helps:
| Field | Example answer |
|---|---|
| Why needed | Parses a format we do not want to maintain |
| Added transitive packages | Two |
| Known advisories | None at review time |
| Maintenance signal | Releases in the past year, security policy present |
| Alternative considered | Writing a small parser, rejected |
Say no kindly
Declining is fine. A short note such as "we try to keep the dependency count low, could this be done with a helper in our own code?" is enough. If you do decline, point to your contribution policy so the next person knows in advance.
Quick check
Does a good Scorecard result prove a package is safe?
No. It measures practices, not intent or current compromise. Use it alongside advisories and your own review.
Do I need to review transitive packages one by one?
Look at the count and any flagged ones in the lockfile diff. Deep review of each is rarely practical.
Safeguard can enforce policy gates on pull requests, including checks on newly added dependencies. The free scan shows what your project pulls in today.
Sources
- GitHub docs, about dependency review: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review
- OpenSSF Scorecard: https://github.com/ossf/scorecard
Last reviewed: 19 October 2026.
