Before judging a package's quality, ask whether you need it. The OpenSSF evaluation guide puts necessity first: check whether the dependency can be avoided by using components you already have. Use the standard library or existing code when they cover the need, and add a package when the problem is hard to get right.
Why avoidance is a security tool
The safest dependency is the one you never add. Every package brings code you did not write, maintainers you do not control, and a stream of advisories to follow. Skipping one removes all of that.
But avoidance has a cost too. Writing your own code means you own its bugs. For some problems, that is far riskier than a well reviewed library.
A decision guide
Ask these in order:
- Does something already in the project do this? Check existing dependencies and the language's standard library first.
- How big is the need? A few lines of straightforward code is cheaper to own than a package.
- Is the problem security sensitive or easy to get subtly wrong? Cryptography, parsing untrusted formats, authentication and date handling in tricky zones belong here. Prefer a reviewed library.
- How much does the package bring with it? See how many indirect dependencies it adds.
- Is the package maintained? If not, the cost of ownership shifts to you anyway.
Where each answer points
| Situation | Usual choice |
|---|---|
| Few lines of plain logic | Write it, with tests |
| Standard library covers it | Use the standard library |
| Hard, security sensitive problem | Use a reviewed, maintained library |
| Large library, tiny use | Look for a smaller option or extract what you need |
| Package unmaintained | Replace, fork, or own the code deliberately |
Counterweights
Writing your own is not free. You take on testing, review and future fixes, and a one off implementation is read by fewer eyes than a library used widely. Do not write your own cryptography or your own parser for a complex format because a dependency felt heavy.
Copying code from a package into your repository does not make the risk vanish either. It removes the update signal, so you will not hear about fixes unless you track the source.
Make it a team habit
Add one question to your pull request template: "Why do we need this package?" and one line for the answer. Reviewers then discuss the decision before the merge, not after an incident. Over time you will see fewer small convenience packages and more deliberate choices.
Also review existing dependencies now and then. If a package is used in one place for one function, ask whether it still earns its place.
Try it yourself
Open the demo and look at how reachability analysis shows which parts of a dependency your code actually calls. A package used lightly is a candidate for this question.
Click through it at your own pace, or open it full screen.
Quick check
Should I write my own cryptography to avoid a dependency?
No. Security sensitive code is easy to get subtly wrong. Use a reviewed, maintained library.
Does copying a package's code into my repo remove the risk?
No. You lose the update signal, so you will not learn about upstream fixes unless you track them.
Safeguard's reachability analysis shows which parts of your dependencies your code can actually reach, which helps you spot packages you barely use. Try the free scan.
Sources
Last reviewed: 19 October 2026.
