Answer with a short routine you actually follow before adding a package: check maintainer activity, known vulnerabilities, license, popularity signals and what the package pulls in. Attach one example review. If you only do this for new direct dependencies, say so.
What is behind the question
Reviewers know most of your code is open source. They want to see that adoption is a decision, not an accident. They do not expect you to audit every line. They expect a light, repeatable gate.
The five checks
| Check | What you look at | Where the answer comes from |
|---|---|---|
| Maintenance | Recent releases, open issue response, number of maintainers | The project repository and registry page |
| Known vulnerabilities | Advisories for the package and its dependencies | Your scanner and public advisory databases |
| License | Does it fit your distribution model and customer terms | Package metadata and the license file |
| Provenance | Is it the real package, not a lookalike name | Compare the repository link, publisher and download history |
| Footprint | How many transitive packages it adds and whether it runs install scripts | The lockfile diff |
The OpenSSF Scorecard project describes its tool as assessing open source projects for security risks through a series of automated checks, and says it can be used from the command line to check someone else's repository. Running it is one way to add a repeatable signal to the maintenance and practices check, though a score is a prompt for judgement, not a verdict.
A model answer
"Before adding a new direct dependency, the requesting developer records why it is needed and checks maintenance activity, known advisories, license and the packages it brings in. A second engineer reviews the pull request and the lockfile change. We scan all dependencies on every pull request and review open findings weekly. We do not currently review every transitive dependency by hand."
The last sentence is the honest scope. It prevents a follow up that catches you out.
Make it a habit in the pull request
Add a short template to your pull request form with three lines: why this package, what alternatives you considered, results of the five checks. This builds the evidence trail as a side effect of work you already do.
What to avoid saying
- "We vet all open source." You do not read every transitive package.
- "We only use trusted packages." Define trusted or drop it.
- "We have never had a malicious package." You may not know.
Pair it with ongoing monitoring
Vetting at adoption is a snapshot. Projects get abandoned, maintainers change and new advisories appear. Continuous scanning of the inventory covers what happens after the decision.
For deeper steps, see how to vet a new open source dependency before adding it.
Safeguard's dependency scanning and SBOM inventory give you the ongoing half of this answer, and the free scan at https://gold.safeguard.sh/scan is a quick check of what you already use.
Quick check
Do we need a written policy for this?
A half page is enough: the five checks, who reviews and where decisions are recorded.
Is a high Scorecard result enough to approve a package?
No. Treat it as one signal alongside advisories, license and your own need.
Should we vet transitive dependencies?
Review what a new package adds in the lockfile diff and rely on scanning for the rest.
Sources
Last reviewed: 19 October 2026.
