To vet a package an AI tool added, confirm it is the real project and not a lookalike, ask whether you need it at all, check who maintains it and how recently, make sure the version is pinned in a lockfile, and see whether it runs install scripts. Five minutes is enough to catch most problems.
Why a quick check matters
AI tools add dependencies to solve the problem in front of them. They do not weigh long-term upkeep, and they can suggest a name that is close to a real package but not the same. Every new package is code from a stranger running with your app's permissions, so it deserves the same look you would give a human colleague's suggestion.
The five-minute routine
Minute 1: Is it the real thing? Open the registry page and compare the name, description and repository link with what you expected. Check that the linked repository exists and matches. A package with a plausible name and an empty or missing repository is a warning sign.
Minute 2: Do you need it? Many additions replace ten lines of code you could write or a feature the standard library already has. Removing a dependency is the cheapest security control there is.
Minute 3: Who maintains it? Look at the last release, open issues, and how many people publish it. OpenSSF Scorecard is an automated tool that runs a set of checks on a project and gives each a score from 0 to 10, which can help you judge a dependency quickly. Treat the scores as a prompt for questions, not a verdict.
Minute 4: Is it pinned? The package should appear in your lockfile with an exact version. In CI, use a clean install command so the build fails if the lockfile and the manifest disagree. npm documents that npm ci exits with an error rather than updating the lock when they do not match.
Minute 5: Does it run code at install time? Some packages run scripts when installed. npm has an ignore-scripts setting that stops them from running, which is useful when you are trying something unfamiliar. Check the package's script entries before you allow them.
What to write down
Keep a short note next to the dependency: why it was added, who approved it, and the date. Six months later that note answers "can we remove this?" in seconds.
| Question | Good sign | Warning sign |
|---|---|---|
| Name matches intent | Repository link works and matches | Near-miss name, no repository |
| Needed | No simple alternative in your stack | Replaces a few lines of code |
| Maintained | Recent releases, several maintainers | Abandoned, single unknown publisher |
| Pinned | Exact version in lockfile | Ranges with no lockfile |
| Install scripts | None, or reviewed | Unexplained scripts |
Automating the repeat work
You will do this check more than once, so automate the rest. Safeguard scans dependencies, builds an SBOM and flags known vulnerabilities, and its policies can block a pull request that adds something you have not approved. Try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and indirect packages are listed together.
Quick check
Does a clean vulnerability report mean the package is safe?
No. A report covers known vulnerabilities only. A new malicious package has no advisory yet, which is why the name and maintainer checks matter.
Should I vet transitive dependencies too?
You cannot hand-check them all. Vet direct ones carefully, and use a scanner and lockfile review for the rest.
Sources
Last reviewed: 19 October 2026.
