A checklist for vetting an open-source library before you add it

Adding an open-source package takes one command. Removing it later, after it is woven through your codebase, can take weeks. Yet the decision to adopt a library is often made in a few seconds, based on a star count and a quick look at the README.

This checklist gives developers, founders and small teams a repeatable way to vet an open-source library or tool before depending on it. It uses free, public resources that we checked on 7 October 2026: OpenSSF Scorecard, the OSV vulnerability database, deps.dev, endoflife.date, choosealicense.com and the audit commands built into npm and Composer. Most checks take a minute each, and the whole review fits into half an hour for a significant dependency.

The aim is not to find a perfect package. It is to know what you are taking on, so the risk is a deliberate choice rather than a surprise.

The checklist at a glance

1. Confirm you need a dependency at all

Every dependency is code you did not write but must keep updating. Before adding one, check whether the platform already covers the need. Node.js 24, for example, ships a global fetch, util.parseArgs() for command-line options and a built-in test runner, so packages that once filled those gaps are often unnecessary. PHP and frameworks such as Laravel include features that small packages duplicate.

If the feature is small and stable, a few lines of your own code may be cheaper over five years than a dependency.

2. Check the licence

A repository without a licence is not open source in any legal sense: by default, nobody else has permission to use, copy or modify it. choosealicense.com, curated by GitHub, explains the common licences in plain language. It describes the MIT License as short and permissive, allowing closed-source redistribution, and the GNU GPLv3 as allowing almost anything except distributing closed-source versions. It also has a page explaining what happens when a project has no licence.

Look for an SPDX identifier (for example MIT, Apache-2.0 or GPL-3.0-only) in package.json or composer.json, and compare it with the SPDX licence list if it is unfamiliar. If you distribute software to customers, or the package uses a copyleft licence, ask whoever handles legal matters for your company before adopting it. This guide is not legal advice.

3. Check maintenance and activity

Open the repository and look at:

• the date of the latest release and the latest commit on the default branch;
• whether issues and pull requests receive responses, especially security reports;
• how many people have merged changes recently (a single maintainer is not automatically a problem, but it is a risk to note);
• whether the README or repository says the project is deprecated or archived.

"Not updated recently" does not always mean "abandoned": some small, finished libraries rarely need changes. What matters is whether someone responds when a real problem appears. For Composer packages, composer audit also reports packages that their authors have marked as abandoned.

4. Look for known vulnerabilities

OSV.dev describes itself as a distributed vulnerability database for open source. It aggregates advisories from many ecosystems, including npm, Packagist, PyPI, crates.io and Linux distributions, and offers a free API. You can query a specific package version before you install it:

curl -s -d '{"package":{"name":"lodash","ecosystem":"npm"},"version":"4.17.15"}' \
  https://api.osv.dev/v1/query

When we ran this on 7 October 2026, the response listed advisories for that old lodash version, including a regular expression denial of service issue fixed in 4.17.21. An empty JSON object means OSV has no known advisories for that version.

Once a package is installed, use your package manager's audit command:

# npm: fails with a non-zero exit code if vulnerabilities are found;
# --audit-level sets the minimum severity that fails the command
npm audit --audit-level=high

# Composer: checks advisories via Packagist and reports abandoned packages
composer audit --locked

The npm documentation says npm audit exits with a non-zero code when it finds vulnerabilities, and recommends --audit-level in CI to set the minimum severity that causes a failure. Composer's documentation says composer audit checks advisories using the Packagist.org API by default, detects abandoned packages and packages flagged as malware, and that --locked audits the lock file regardless of what is in the vendor directory.

5. Review security practices with OpenSSF Scorecard

OpenSSF Scorecard, from the Open Source Security Foundation, runs automated checks against a repository and gives each check a score out of 10, combined into an aggregate score. Its checks cover areas such as whether the project is maintained, whether changes are code-reviewed, whether it has a security policy, whether dependencies are pinned, whether CI workflows use dangerous patterns, whether releases are signed and whether it uses a dependency update tool such as Dependabot or Renovate.

Scorecard results for many popular repositories are available through a public API, with no installation needed:

curl -s https://api.securityscorecards.dev/projects/github.com/expressjs/express \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d["date"], d["score"]); [print(c["score"], c["name"]) for c in d["checks"]]'

Read the individual checks rather than only the aggregate. A low score on "Signed-Releases" matters less to most small teams than a low score on "Code-Review", "Maintained" or "Dangerous-Workflow". If a repository has no published result, you can run the Scorecard command-line tool yourself with a GitHub personal access token, as described on the Scorecard site.

6. Measure the dependency footprint

A package with three lines of useful code can pull in dozens of transitive dependencies, each with its own maintainers and risks. deps.dev, the Open Source Insights service from Google, shows a package's versions, dependencies, licences and advisories across the package systems its API documentation lists: npm, PyPI, Maven, Go, Cargo, NuGet and RubyGems. Packagist is not on that list, so PHP developers should rely on composer show --tree and Packagist itself for this step. The API is public:

curl -s https://api.deps.dev/v3/systems/npm/packages/express

That response lists published versions, with flags showing which version is the default and which are deprecated. Locally, npm ls --all or composer show --tree shows the full tree after a trial install in a throwaway branch.

7. Check runtime and framework support

A library that only supports an old runtime can hold back your upgrades. Compare the package's stated requirements (engines in package.json, require.php in composer.json) with the support schedule of your platform. endoflife.date tracks these dates for hundreds of products and has an API:

curl -s https://endoflife.date/api/v1/products/nodejs/

Confirm important dates on the official pages. On 7 October 2026, PHP's supported versions page listed 8.2 to 8.5 as supported, with security support for 8.2 ending on 31 December 2026, and the Node.js releases page listed 24 and 22 as LTS lines and 26 as Current.

8. Plan your exit before you enter

Assume that one day you will need to replace the package. You make that easier by:

• wrapping it behind a small interface or service class of your own, so only one file imports it;
• pinning versions with a lock file and reviewing upgrades through pull requests (Dependabot or Renovate can open them for you);
• writing a short note in your repository explaining why you chose it and which alternatives you considered.

That note takes five minutes and saves the next developer from repeating the whole review.

A one-page record for each dependency

For significant dependencies, record the outcome in a pull request description or an architecture decision record:

## Dependency review: <package> <version>
- Purpose: what it replaces or provides
- Licence: SPDX id, compatible with our distribution? yes/no
- Maintenance: last release date, response to issues
- Vulnerabilities: OSV / npm audit / composer audit result
- Scorecard: aggregate score and any weak checks that matter to us
- Footprint: number of transitive dependencies
- Runtime support: minimum PHP / Node.js version
- Exit plan: where it is wrapped, alternatives considered
- Reviewed by / date

Summary

Vetting a dependency does not need paid tools. In about half an hour, choosealicense.com and the SPDX list settle the licence question, OSV.dev and your package manager's audit command reveal known vulnerabilities, OpenSSF Scorecard summarises security practices, deps.dev shows the footprint, and endoflife.date keeps runtime support in view. Record what you found, wrap the package behind your own interface, and let automated update tools keep it current.