Vet Open-Source Software for Supply Chain Risks

You add a package to fix one bug, and eight months later a maintainer you have never met pushes an update that quietly exfiltrates environment variables from every machine that installs it. That is not a hypothetical. It is roughly the plot of the xz-utils backdoor discovered in early 2024, and of the September 2025 npm compromise that poisoned packages with over two billion weekly downloads through a single phishing email to a maintainer.

Open source is not the problem. It powers nearly everything you ship, and the vast majority of it is safer than the closed alternatives because thousands of eyes can read the code. The problem is that most teams install dependencies the way people accept cookie banners: reflexively, without reading, trusting that someone smarter already checked. Sonatype's 2024 State of the Software Supply Chain report counted more than 500,000 malicious packages published to public registries, up 156% year over year. Nobody vetted those. They just got installed.

This guide walks through how to actually vet open source software for supply chain risks in 2026: what signals matter, how to score a dependency in under ten minutes, a worked example with real numbers, and the tools worth paying for. You will not need a security team to follow it.

Key Takeaways

Treat every dependency as a vendor, not a snippet. If you would not hire the maintainer, do not run their code as root.

Package popularity is not safety. The most-downloaded packages are the most attractive targets for takeover attacks.

Pin, lock, and verify. Use lockfiles, checksums, and (where possible) signed provenance so an update cannot silently change what you installed.

Automate the boring 80%. SCA scanners catch known CVEs and typosquats so your humans can focus on the judgment calls.

Have a containment plan before you need one. Know how to freeze installs and roll back within minutes of a disclosure.

What "supply chain risk" actually means for open source

When people say open source software security risks, they usually picture a hacker breaking into your app. The supply chain angle is subtler and often nastier: the attacker never touches your servers. They compromise something upstream that you willingly pull in.

There are five distinct threats worth naming, because you defend against each differently:

Known vulnerabilities (CVEs): A real flaw exists in a version you use. This is the easy case, since scanners flag it and a patch usually exists.
Malicious packages: The code is designed to steal or destroy. Includes typosquats (reqeusts instead of requests) and dependency confusion.
Account or maintainer takeover: A legitimate, trusted package gets hijacked through phished credentials or a bought-out maintainer. This is what hit npm in 2025.
Abandoned dependencies: No malice, just neglect. Nobody patches the eventual vulnerability, and you inherit the risk.
Build and distribution tampering: The source on GitHub looks clean, but the published artifact was modified. The xz backdoor lived only in the release tarball, not the repo.

Notice that three of these five have nothing to do with the code being buggy. That is the shift. In 2026 you are not just auditing quality, you are auditing trust and provenance.

The 10-minute dependency vetting checklist

You cannot deep-audit every package. A mid-size Node project pulls in 1,000+ transitive dependencies. What you can do is triage the ones you add directly and the handful that run with elevated privileges. Here is the checklist I run before adding anything to a production project.

1. Read the metadata before the code

Check the release cadence. A package last updated in 2021 with 40 open issues is a liability. A package updated last week by an active maintainer is healthier.
Look at the maintainer count. One person, one email, no organization behind it means single point of failure. That person can be phished or can walk away.
Compare download count to GitHub stars. A wild mismatch (millions of downloads, 12 stars) can signal a typosquat riding on a popular name.
Scan the version history for anomalies. A sudden major release with a brand-new maintainer publishing at 3 a.m. their local time is worth a pause.

2. Inspect the actual install behavior

Check for install scripts. In npm, look for preinstall, install, and postinstall hooks in package.json. These run code on your machine before you have inspected anything. Most legitimate packages do not need them.
Diff the published tarball against the repo. This catches the xz-style attack. Tools like npm pack plus a source clone let you compare what is actually shipped.
Review permissions and network calls. Does a date-formatting library open a socket? That is a red flag.

3. Verify provenance and integrity

Confirm a lockfile pins exact versions and hashes. package-lock.json, yarn.lock, poetry.lock, and Cargo.lock all record integrity checksums. If the hash changes unexpectedly, so did the code.
Prefer packages with signed provenance. npm's provenance attestations (via Sigstore) tie a published package back to the exact CI build and commit that produced it. In 2026 this is increasingly the baseline for high-trust packages.

Ten minutes per direct dependency is not free, but it is far cheaper than an incident. The same discipline applies when you evaluate commercial code, which is one reason vetted marketplaces exist. When you buy from a curated catalog like the LionScripts product library, someone has already done the metadata and provenance homework before the listing goes live.

A worked example: scoring a real dependency

Say your team needs an image-processing utility and you have narrowed it to two npm candidates. Both do the job. Here is how the ten-minute scan plays out with concrete numbers.

Candidate A has 4.1 million weekly downloads, 3 active maintainers backed by a known company, a release two weeks ago, no install scripts, and npm provenance attestations. GitHub shows 8,400 stars and 22 open issues.

Candidate B has 90,000 weekly downloads, 1 maintainer with a Gmail address, last release 14 months ago, a postinstall script that downloads a binary from a personal domain, and no provenance. GitHub shows 210 stars.

Scoring on a simple 0–2 scale across six criteria:

Criterion	Candidate A	Candidate B
Maintainer resilience (2 = multiple/org)	2	0
Recent activity (2 = <3 months)	2	0
Install script safety (2 = none)	2	0
Provenance / signing (2 = attested)	2	0
Popularity vs stars sanity (2 = aligned)	2	1
Open vuln count (2 = zero known)	2	1
Total (out of 12)	12	2

Candidate B is not necessarily malicious. But a score of 2 out of 12 means you are accepting a single-maintainer package that runs unreviewed code at install time and pulls a binary from a domain you cannot audit. If it saves you two hours of coding, it is not worth the risk. Write your own thin wrapper or pick A.

Set a team threshold. Mine is simple: direct dependencies must score 8 or higher, and anything below 6 needs a written justification. That single rule has killed dozens of casual npm install decisions before they became debt.

Tools that automate the heavy lifting

You will not manually score 1,000 transitive dependencies. This is where software composition analysis (SCA) and related tooling earn their keep. Here is how the common options compare on what actually matters day to day.

Tool	Best for	CVE detection	Malicious pkg detection	Cost
GitHub Dependabot	Repos already on GitHub	Strong	Weak	Free
OWASP Dependency-Check	Self-hosted CI, Java/.NET	Strong	None	Free
Snyk	Multi-language dev teams	Strong	Moderate	Free tier + paid
Socket	npm/PyPI behavioral risk	Moderate	Strong	Free tier + paid
OpenSSF Scorecard	Auditing project health	Indirect	Indirect	Free

My honest take after using all five: no single tool covers everything. Dependabot and Dependency-Check are excellent at known CVEs and cost nothing, but they will happily wave through a brand-new malicious package that has no CVE yet. That is Socket's specialty, since it analyzes behavior (install scripts, network access, filesystem writes) rather than waiting for a disclosure. OpenSSF Scorecard is the one I run when I want to judge whether a project is governed well, since it grades things like branch protection, signed releases, and fuzzing.

A sensible stack for most teams: Dependabot or Dependency-Check for CVEs, Socket for behavioral analysis on npm and PyPI, and Scorecard for periodic health audits of your critical dependencies. Layer them; do not pick one.

If you are also generating code with AI assistants that pull in libraries on your behalf, the vetting problem gets worse, not better. I wrote a companion piece on how to verify AI-generated code before you ship it that pairs well with this checklist, because AI tools frequently suggest plausible-sounding packages that do not actually exist or that squatters have since registered.