Dependency selection

Do this

1. Ask whether you need it

   Check whether the standard library, your framework or a package you already use does the job. The OpenSSF Concise Guide for Evaluating Open Source Software starts here, and warns that every new dependency is a potential support problem or supply chain attack. Look at what the package pulls in too, and at whether development-only packages end up in production.

2. Confirm it is the package you meant

   Check the exact name on the registry, look for a more popular look-alike that would signal typosquatting, and confirm the project it claims to come from. Take extra care with names an AI assistant suggested: a USENIX Security 2025 study of 576,000 generated code samples found that models suggest packages that do not exist, and an attacker can register such a name.

3. Check maintenance and security practices

   Look for commits and a release in the last 12 months, more than one maintainer, instructions for reporting vulnerabilities, and no long-known unfixed vulnerabilities in the version you will use. Read the individual OpenSSF Scorecard checks on deps.dev, such as Code-Review, Maintained and Dangerous-Workflow, rather than the total. OSV dependency lookup checks exact versions against OSV.

4. Check who publishes it and what runs at install

   List the publishers, for example with npm view <package> maintainers, and check whether the version has provenance that links it to a source commit, as deps.dev shows for npm packages. Read any preinstall, install or postinstall script before allowing it: npm 12 blocks dependency install scripts by default until you approve them, and pnpm runs only builds listed in allowBuilds.

5. Pin it in a committed lockfile

   Commit the lockfile with the manifest and install from it in CI. npm ci exits with an error if package.json and the lockfile disagree and never rewrites the lockfile; pip's hash-checking mode requires every requirement pinned with == and a hash for every dependency. Review the lockfile diff in the pull request, because that is where unexpected transitive packages show up.

6. Install only from the registry you intend

   Give each internal package name one source: an npm scope mapped to your registry (@acme:registry=...), a single pip index that proxies PyPI instead of --extra-index-url, a uv index marked explicit = true, or NuGet packageSourceMapping. Otherwise a public package with the same name and a higher version can win. OWASP ASVS 5.0 V15.2.4 (level 3) requires this.

7. Record the decision and an owner

   Write the intake in the pull request: why this package, the exact version, what you checked, any gap you accepted and who owns its updates. Route manifest and lockfile changes to a code owner, and reopen the decision when maintainers or publishers change, a release loses provenance its predecessors had, or a new major version adds native code or network access.

Common mistakes

• Choosing by stars, downloads or one score. A Scorecard total combines unrelated checks; Scorecard itself says a low score is not proof of risk, so read the checks that matter for how you will use the package.
• Treating the repository link on the registry page as proof of origin. It is often unverified metadata; only provenance binds a published version to a source commit.
• Reaching internal packages with pip's --extra-index-url. pip searches every index together and installs the highest version, so a public look-alike with a higher version number wins.
• Installing an AI-suggested package without checking that it exists and is the one you meant, which is exactly the name an attacker may have registered.
• Approving a package once and never looking again. A new maintainer or owner can turn trusted code hostile, as in Case study: event-stream and ua-parser-js, two npm package takeovers and Case study: the polyfill.io CDN takeover (2024).

What each signal tells you, and what it does not

No single signal decides intake. Collect several, record them in the pull request, and weigh them against how the package will be used: a parser for untrusted uploads deserves more scrutiny than a development formatter.

Tools and guides

• Tool: OSV dependency lookup
• Tool: SBOM checker
• Practice: Dependency patching
• Review dependency health without treating a score as a guarantee

  Combine security practices, maintenance, licensing and product exposure into a recorded adoption or replacement decision.

• Stop dependency confusion and typosquatting at install time

  Pin every internal package name to its real source, verify installed bytes against a lockfile, and delay or gate install scripts so a public look-alike cannot replace a private dependency.

• Adopt the OpenSSF S2C2F as a consumer: the eight practices, the four maturity levels and a staged plan with evidence

  Assess how your organization takes in open source against the Secure Supply Chain Consumption Framework's 25 requirements, then reach each maturity level in turn with evidence an assessor can check.

• Case study: the Shai-Hulud npm worm (2025-2026)

  How a self-replicating npm worm turned stolen tokens into hundreds of infected packages in 2025, how its 2026 successors hijacked release pipelines and trusted publishing, what npm and GitHub changed in response, and the publishing, install and response practices that stop it.

Standards

NIST SSDF 1.1

PW.4 Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality

OWASP SAMM 2

Secure BuildSecure Architecture

Sources

1. OpenSSF: Concise Guide for Evaluating Open Source Software
2. OpenSSF Scorecard: checks documentation
3. OWASP Top 10:2025 A03 Software Supply Chain Failures
4. OWASP ASVS 5.0.0: V15 Secure Coding and Architecture (V15.2.4). Version 5.0.0.
5. CISA: Widespread supply chain compromise impacting npm ecosystem. 23 September 2025.
6. Spracklen et al.: We have a package for you! Package hallucinations by code-generating LLMs (USENIX Security 2025)
7. npm docs: npm ci. npm v12.
8. npm docs: npm install-scripts. npm v12.
9. pnpm docs: build settings (allowBuilds, strictDepBuilds)
10. pip docs: secure installs (hash-checking mode)
11. pip docs: pip install (index options and dependency confusion warning)
12. uv docs: package indexes (first-index strategy, explicit indexes)
13. npm docs: scope (associating a scope with a registry). npm v12.
14. NuGet docs: Package Source Mapping
15. deps.dev API v3 (provenance, attestations, Scorecard and advisories)
16. OWASP SAMM: Secure Build (Software Dependencies stream)
17. NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.