A brand new open source project is not unsafe by default, but you cannot judge it by track record because it has none. Adopt it only for low-blast-radius uses, pin exact versions, read the code yourself, set a trial period, and write an exit plan before it reaches production.
Why new projects are hard to score
Most trust signals build over time: release history, advisory handling, a stable contributor base. OpenSSF Scorecard's Maintained check, for instance, only applies to projects at least 90 days old. Before that mark, a major signal is simply missing, so a low or empty result is expected rather than alarming.
New projects also attract a particular kind of risk. Attackers publish lookalike or fresh packages hoping someone installs them, which is why registry names and sources need a second glance. See what a typosquatting campaign looks like.
What you can check on day one
| Check | How |
|---|---|
| Who is behind it | Maintainer's history, other projects, organization link |
| Source and registry match | Registry metadata points to the same repository |
| Build method | CI build with provenance, where available |
| License | A license is declared |
| Install behavior | Install scripts, network calls, new dependencies |
| Name safety | Not a near copy of a popular package |
| Code size | Small enough to read yourself |
The npm docs say a verified provenance attestation shows where a package was built, not that its code is safe, so use it to confirm the link to source, then read that source.
A staged adoption plan
- Prototype in a sandbox with no credentials in the environment.
- Read the entire source if it is small. If it is too large to read, that tells you something about fit.
- Pin the exact version and verify the lockfile.
- Limit scope. Use it behind an interface in your code so replacement is cheap.
- Set a review date, for example 90 days out, and rerun the checks.
- Add it to monitoring so new advisories reach you.
When to wait
Wait, or look for something older, if the package will run in your build pipeline, handle credentials or sensitive data, or parse untrusted input at scale. In those cases a missing track record is a cost you do not need to take on.
If you still want it, consider vendoring the code so you control updates. Our adoption record template helps keep the decision visible.
Questions to ask yourself
Is the problem this package solves hard enough to justify the risk? Many small utilities can be written in an afternoon, and owning twenty lines of your own code is safer than trusting a stranger's brand new package. If the functionality is complex, such as cryptography or parsing, prefer a mature, widely reviewed option and accept a bit of extra weight. Finally, ask whether the project's stated goals match your needs. A young project often changes its API quickly, and that churn is a cost even when everything is secure.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Do stars and downloads show a new project is safe?
No. Both can be inflated or simply reflect hype. Check who is behind it and what it does at install and run time.
Should I ban new projects?
A blanket ban blocks useful tools. A tiered approach is more practical: strict for risky uses, relaxed for small isolated ones.
Sources
Last reviewed: 19 October 2026.
