Before launch, replace or remove any dependency that is unmaintained, duplicated by another package, impossible to explain, tied to a single anonymous publisher or far larger than the job needs. Keep the ones that are maintained, understood and pinned. Decide package by package, using a short table.
Why prototypes collect weak dependencies
An AI assistant picks whatever solves the immediate error. Over a weekend that can mean three libraries for the same job, a package last updated years ago, and one nobody on the team has heard of. Each is a future patching burden and a possible entry point.
Signals that a package should go
Abandoned. No release or commit activity for a long time, open security issues without response, a maintainer saying the project is archived.
Redundant. Two packages doing the same job, or a package for something the language or framework already does. Fewer packages means a smaller attack surface.
Unexplained. No one can say why it is there. If nobody can justify it, remove it and see what breaks.
Single point of failure. One publisher with no other maintainers and no recovery plan. This is not always bad, but it deserves a second look.
Install-time behaviour. The package runs scripts when installed. npm lets you disable lifecycle scripts with the ignore-scripts setting, which is useful for evaluating an unfamiliar package safely.
Disproportionate. A large library imported for one function.
Using Scorecard as a prompt
OpenSSF Scorecard is an automated tool that runs checks against a project's security practices and gives each a score from 0 to 10. Run it on your top dependencies and read the lowest scores. A low score does not prove a problem, but it tells you which question to ask next.
Keep, swap or remove
| Situation | Decision |
|---|---|
| Needed, maintained, pinned | Keep |
| Needed, but abandoned | Swap for a maintained alternative, or fork and own it |
| Duplicates another package | Remove one |
| Not imported anywhere | Remove |
| Needed, but a tiny function | Replace with a few lines of your own code |
| Unknown purpose | Remove and test |
How to swap safely
- Create a branch and make the change on its own.
- Reinstall from a clean state and run the tests.
- Review the lockfile diff for packages that appeared or vanished.
- Merge only through your normal review.
Do not forget transitive packages
You may not choose them, but you ship them. Review the whole tree with a scanner and use the result to decide which direct dependency to replace when a deep one is the problem.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation show direct and indirect packages together, and reachability analysis helps you tell which vulnerable code your app actually calls. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is an old package always unsafe?
No. A small stable package can be fine for years. Age matters when it comes with unanswered issues, no maintainers or known vulnerabilities.
Should I fork an abandoned package?
Only if you are ready to maintain it. Otherwise a maintained alternative is the lower-effort option.
Sources
Last reviewed: 19 October 2026.
