Partly. A past advisory is not a bad sign by itself. What matters is how fast fixes shipped, whether they reached the versions people use, whether the same root cause repeats, and how maintainers communicated. A library with zero advisories may simply have had few reviewers.
Two misreadings to avoid
"No advisories means safe." It may mean nobody has looked hard, or that issues were fixed quietly without a published record.
"Many advisories means unsafe." Widely used, actively reviewed projects often have more published advisories because researchers examine them and maintainers disclose properly. A visible, well-handled record can be a good sign.
So the count tells you little. The handling tells you a lot.
What to read in each advisory
| Question | What it shows |
|---|---|
| How long from report to fixed release? | Maintainer responsiveness |
| Which versions are affected and which fixed? | Whether your target version is clean |
| Was the fix backported to older major versions? | Whether you can patch without a big upgrade |
| What was the root cause? | Whether it is a one-off or a pattern |
| Was there a clear advisory and credit? | Disclosure maturity |
| Was the vulnerable code reachable in typical use? | Real exposure versus theoretical |
Open advisory records in OSV and on deps.dev, which includes OSV advisories, and in the project's own security tab. Read the text for the fixed version and the description, rather than relying on a severity score alone.
Patterns that matter
- Repeated root cause. Several advisories in the same area, such as input parsing, suggest a design weakness. That does not rule the library out, but it raises the value of a wrapper and of input validation on your side.
- Slow or missing fixes. An advisory open with no fixed version is a stop sign for anything on a sensitive path.
- Fixes only on the newest major. If you cannot move to it, you cannot be patched.
- Silent fixes. Release notes that mention a security change with no advisory make tracking harder.
Steps
- Search the package on deps.dev and OSV, as described in the five-minute check.
- List advisories for the last few years with dates of report and fix, where given.
- Mark any that affect the version you plan to use.
- Note the repeated areas and handling quality.
- Add a line to your selection checklist.
Severity is not exposure
A high score on a flaw in a feature you never call is a smaller risk than a medium one on a path you do. That is why reachability matters, and why exploitability checks belong alongside advisory reading.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the same advisory can matter very differently depending on how the code is used.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, reachability analysis and zero-day discovery apply this thinking to your own applications. Try the free scan at gold.safeguard.sh/scan.
Quick check
Should I avoid a library with a recent critical advisory?
Not automatically. If the fix was fast and clear and you can use the fixed version, the history may reflect good handling.
Where do I find advisories?
OSV, deps.dev, the repository security tab, and the project's release notes. Cross-check at least two.
Sources
Last reviewed: 19 October 2026.
