A hybrid dependency scanning model runs the part that touches sensitive inputs inside your own network, and the part that benefits from shared data or central reporting in a hosted service. It suits teams with mixed sensitivity: some repositories can use a service, others cannot.
Definition
In a hybrid setup, a local component such as a CLI, runner, or on-premises collector reads your manifests and lockfiles. It sends either nothing, or a reduced result such as a list of findings or a hash based inventory, to a central console. The console handles policy, history, reporting, and data enrichment.
Compare this with the pure models. In SaaS everything runs in the vendor environment. In self-hosted everything runs in yours. Hybrid sits between them.
What can run where
| Function | Local side | Hosted side |
|---|---|---|
| Reading manifests and lockfiles | Yes | Sometimes |
| Matching against vulnerability data | Local copy or hosted | Hosted |
| Reachability analysis on source | Local, so source stays put | Rarely |
| Policy definition and distribution | Pulled from hosted | Yes |
| Findings history and ownership | No | Yes |
| SBOM storage and export | Optional | Yes |
| Evidence for audits | Collected locally | Aggregated |
The key design choice is which direction data flows. Policy flows down to the local side. Findings flow up. Source code and raw manifests stay where you decide.
Who benefits
- Mixed portfolios. A company with a regulated product and an ordinary web app can scan the first locally and the second as a service.
- Teams with a data boundary but no appetite to build a console. You get central views without hosting them.
- Acquisitions. Newly acquired teams can join central reporting quickly while their code stays where it is until you decide otherwise.
Who does not need one
If every repository can use a service, plain SaaS is simpler. If nothing may leave, self-hosted or offline is simpler. Hybrid adds a moving part, so use it when you have a reason.
Risks to plan for
- Two places to misconfigure. Local components need updating. A pinned old collector can silently scan with stale rules.
- Version drift. Local and hosted sides must agree on policy format. Test upgrades in order.
- Unclear boundaries. Write a one page data flow showing exactly what crosses. Reviewers will ask.
- Partial coverage. Repositories on the local path can be forgotten in central reports. Track coverage as a metric: repos scanned over repos that exist.
How to evaluate
Run two repositories through it: one routine and one sensitive. Check that the sensitive one produces useful central findings without exposing what you marked as off limits. Capture the network traffic and compare it with the vendor's description.
Quick check
Is hybrid just self-hosted with extra steps?
No. Self-hosted means you run the whole service. Hybrid means you run just the local component and use a hosted console for the rest.
Does hybrid reduce vendor lock in?
It can, if local outputs use open formats such as SBOMs. Confirm exports before you buy.
Safeguard offers dependency and SBOM scanning with reachability analysis, a CLI, and IDE plugins; if you have mixed sensitivity repositories, ask for the data flow for each surface and try a free scan on a non sensitive project.
Last reviewed: 19 October 2026.
