To research a package in five minutes, look it up on deps.dev for its dependency graph and known advisories, open the linked repository to check recent activity and a security policy, then record the result. Stop at a go, no go or needs review answer. Deeper review comes later for packages that matter.
What deps.dev gives you
deps.dev, also called Open Source Insights, is a service from Google that builds a full dependency graph for each package and tracks how it changes over time. It covers Cargo, Go, Maven, npm, NuGet, PyPI and RubyGems, and project hosts GitHub, GitLab and Bitbucket. It indexes security advisories from OSV. Access is also available over HTTP and gRPC, plus a BigQuery public dataset, if you want to automate.
The OpenSSF guide to evaluating open source software also tells readers to review deps.dev, including the OpenSSF Scorecard score and known vulnerabilities.
The five minute routine
- Minute one: confirm the name. Compare the exact spelling with the project's own documentation. A similarly named package that is more popular can signal typosquatting.
- Minute two: open the package on deps.dev. Note the version, the number of direct and indirect dependencies, and any listed advisories.
- Minute three: follow the link to the repository. Check the date of the last commit and the last release, and whether the repository is archived.
- Minute four: look for a security policy and a way to report vulnerabilities privately. The absence is not fatal, but it tells you how a report would be handled.
- Minute five: decide and write it down.
What to record
| Field | Example entry |
|---|---|
| Package and version | name, 2.4.1 |
| Last release | month and year |
| Open advisories | none, or list |
| Dependency count | direct and indirect |
| Security policy present | yes or no |
| Decision | go, no go, review |
Keeping this in the pull request description makes the choice visible to reviewers later.
When five minutes is not enough
Escalate when the package handles untrusted input, authentication, cryptography or secrets, when it has install scripts, or when it brings in a large number of indirect dependencies. For those, the OpenSSF guide suggests testing in an isolated environment and watching for malicious behavior such as data exfiltration, and checking installation scripts and recent commits.
Be careful with what a quick lookup cannot show. It will not tell you who controls the publishing account or whether a brand new release was tampered with. It also cannot prove the absence of a vulnerability that has not been disclosed yet.
Try it yourself
Open the demo to see a dependency inventory with versions and findings. Think of it as the list you would run this routine against.
Click through it at your own pace, or open it full screen.
Quick check
Which ecosystems does deps.dev cover?
Cargo, Go, Maven, npm, NuGet, PyPI and RubyGems, according to its documentation.
Does a clean deps.dev page mean the package is safe?
No. It shows known advisories and structure. It cannot show undisclosed flaws or a compromised publisher.
Safeguard's SBOM and dependency scanning runs this kind of check across every package in your repositories at once, not one at a time. Try the free scan.
Sources
Last reviewed: 19 October 2026.
