Choose a dependency scanning model by answering five questions: what may leave your network, where you need enforcement, how many repositories you have, who will operate it, and what evidence you must produce. The answers narrow six options to one or two before you run a pilot.
The six options in one line each
- SaaS: hosted service, fastest start.
- Self-hosted: you run the service, data stays inside.
- CLI-only: a command you run anywhere, no console.
- IDE-first: feedback while coding, not enforceable.
- CI-first: checks on every pull request, enforceable.
- Hybrid: local scanning with hosted reporting.
These are not exclusive. IDE, CI, and CLI are places a scan runs. SaaS and self-hosted describe who runs the service behind them. Most teams end up with a combination: one service model plus two or three places to run.
Question 1: What may leave the network?
If nothing may leave, remove SaaS. Your choices are self-hosted, CLI with a local database, or hybrid with a local collector that sends nothing sensitive.
Question 2: Where do you need to stop a bad change?
If the answer is "before merge", you need CI. If the answer is "ideally earlier", add the IDE. If the answer is "we just need to know", scheduled scans are enough.
Question 3: How many repositories?
Under ten, a CLI and shared config can work. Past a few dozen, you need central policy and a view across repositories, which points to a console, hosted or self-hosted.
Question 4: Who operates it?
If you have a platform team with capacity, self-hosted is realistic. If not, choose a model where someone else patches and updates it. Operations is the hidden cost of self-hosting.
Question 5: What evidence must you produce?
If customers ask for SBOMs or auditors ask for records of scanning, you need stored history and exports, so the CLI alone is not enough. The NIST Secure Software Development Framework, SP 800-218, is a common reference for the practices these requests point to, and its framing of reviewing and analyzing code and dependencies helps you describe what you do.
Putting the answers together
| Your situation | Likely fit |
|---|---|
| Small team, no constraints | CLI plus CI, add a console later |
| Many repos, no data limits | SaaS, CI-first, IDE for feedback |
| Strict data boundary, platform team | Self-hosted, CI-first |
| Isolated network | Self-hosted or CLI with local database |
| Mixed sensitivity | Hybrid |
Run a one week pilot
Pick two repositories. Measure time to first finding, how many findings someone acted on, how many were noise, and hours spent on setup. Ask each option to show its data flow. Choose on measured results, not demos.
Quick check
Can I use more than one model?
Yes. A common setup is a hosted console with CLI scans in CI and an IDE plugin for early feedback.
What is the most common mistake?
Choosing on feature lists and skipping the data flow and operations questions, which decide whether the tool is still used a year later.
Safeguard covers dependency scanning, SBOM generation, reachability analysis, and policy gates across CLI, IDE, and desktop surfaces. A free scan gives you a real result to compare against your pilot criteria.
Sources
Last reviewed: 19 October 2026.
