Start with what your source host and package manager already provide, add a dedicated product when evidence and coverage start to cost more engineer time than the product would, and build custom tooling only for gaps nothing else covers. Decide by the questions customers ask, not by tool lists.
Three approaches
| Approach | What it looks like | Strengths | Costs | |---|---|---| | Use built in features | Lockfiles, branch protection, platform dependency alerts, update bots | Nearly no setup, no new vendor | Uneven coverage, evidence scattered | | Assemble open source tools | Scanners and SBOM generators wired into CI | Control, no license fee | Your time to configure, tune and maintain | | Adopt a dedicated product | One place for inventory, scanning, policies and evidence | Faster evidence, less glue code | A vendor to assess and a bill to approve |
Decide by questions, not features
Write down the five questions customers keep asking: what do you run, what is vulnerable, how fast do you fix, who can change production, who else touches data. For each, ask which approach gives you an answer you can attach as evidence in an afternoon.
If the built in features answer all five, stop there. If you answer by stitching exports together every time, you have found the point where a dedicated product might save time.
Hidden costs to count
- Tuning. Open source scanners need configuration and false positive handling, and that work repeats as projects change.
- Evidence. Collecting and dating exports by hand takes more time than most teams expect.
- Coverage. A tool that scans three repositories well and misses forty others gives false comfort.
- Ownership. Every tool you run needs an owner for upgrades and alerts.
- Vendor risk. Any new product holds some access to your code or data. Assess it as you would any vendor.
Questions to ask any provider
Keep these neutral and test them in a trial: Which languages and package managers does it cover? What does it send out of your environment? How does it show whether a flaw is reachable? Can you export results with dates? What permissions does it need on your source host? What happens to your data if you leave?
A staged path
- Month one: turn on the free platform features, commit lockfiles, protect the main branch.
- Month two: add dependency scanning on every pull request and keep dated reports.
- Month three: review how long evidence collection takes. If it dominates, trial a dedicated product against your five questions.
- Later: build small internal scripts only where a gap remains, and document them so they survive turnover.
What not to do
Do not buy a platform before you know what you run. Do not build a scanner. Do not adopt a tool that needs more ongoing care than you have people for.
Safeguard is one option for the dedicated product stage, with dependency scanning, SBOM inventory, reachability analysis, policies and gates and compliance and evidence automation. You can test it on your own project with the free scan at https://gold.safeguard.sh/scan before deciding anything.
Quick check
Is free tooling enough for a first customer review?
Often yes, if it answers the questions asked and you can produce dated evidence.
When does buying start to make sense?
When collecting evidence and tuning tools costs more engineering time than a product would.
Should we trial more than one product?
If you trial, test each against the same five customer questions on the same repository.
Last reviewed: 19 October 2026.
