Evaluate in one week by writing needs first, running the tool on your own real repository, scoring noise, reachability, fix guidance and effort, and deciding against written criteria. Do not rely on a demo with sample data. Your own code is the only test that counts.
Day one: write the needs
List the jobs you need done, and mark which are must have. For a small team they usually include inventory, alerts on new advisories, a pull request check, and some way to cut noise. Add constraints such as the languages you use, where code is hosted and who will operate it.
Day two: set up on a real repository
Use the repository you scored highest for exposure. Note how long setup takes and what permissions it asks for. Ask whether it needs write access to your code, and why. A tool that needs broad access should earn it.
Day three: compare the inventory
Compare the tool's dependency list with your lockfile and with your code host's dependency graph. Are indirect dependencies present? Are versions right? Missing packages mean missing findings. Also check support for each ecosystem and file type you use.
Day four: judge the findings
Take twenty findings and answer these questions.
| Question | Why it matters |
|---|---|
| Is it a real match for a package you use? | False matches cost time |
| Does it show whether your code calls the vulnerable function? | Reachability cuts noise |
| Does it show exploitation evidence? | Orders the queue |
| Does it say what version fixes it? | Saves research |
| Can you record a dismiss reason? | Needed for evidence |
CISA's exploited catalog and FIRST's EPSS are public signals. A tool that surfaces them helps. See CVSS, EPSS and KEV compared.
Day five: test the gate and fix path
Open a test pull request that adds a vulnerable package. Does the tool catch it, and where does it tell you? Then ask what happens when you want to fix. Does it help you reach a safe version, and is any automation under your control and off until you enable it?
Score and decide
Give each criterion a score from one to five and weight the must haves. Write the result. If two options tie, choose the one with less operating effort, since a small team pays for upkeep in attention.
Questions to ask any vendor
- Which ecosystems are supported, listed by name?
- What data does it send out of our environment?
- How are findings deduplicated across repositories?
- What does it cost to leave, including exporting our data?
Never accept a claim you cannot test. Ask for a trial on your repository.
Compare with the free baseline
Always compare against the free baseline, such as the audit command and the dependency review view. If a tool does not beat the baseline on your repository, you do not need it yet. The goal is a better result, not a more complex setup.
Safeguard offers a free scan at https://gold.safeguard.sh/scan, so you can test dependency scanning and reachability analysis on your own code as part of an evaluation.
Quick check
Should we run two tools side by side?
For one week, yes, to compare. After the decision, run one, since two tools double the alerts without doubling the value.
What access should a tool need?
Read access to the repository is usually enough for scanning. Ask why before granting write access.
Sources
- CISA, Known Exploited Vulnerabilities
- FIRST, Exploit Prediction Scoring System
- npm Docs, npm-audit
- GitHub Docs, Dependency review
Last reviewed: 19 October 2026.
