When you evaluate an AppSec or software composition analysis (SCA) tool, the scanning engine and vulnerability database usually get the spotlight. The deployment model — where the scanner actually runs, and where your source code and build artifacts travel to get scanned — gets far less scrutiny, even though it determines your data residency posture, your audit scope, and whether the tool can run in an air-gapped or regulated environment at all. Endor Labs, like most modern SCA vendors, is built and marketed as a cloud-native SaaS platform: you connect your repositories and CI, and analysis runs in the vendor's cloud. Safeguard was built to support that same SaaS convenience while also offering self-hosted and hybrid deployment for teams that can't or won't send code and dependency metadata off-premises. This post compares the two deployment philosophies on concrete, verifiable dimensions — not feature-for-feature marketing claims — so you can pick the model that matches your compliance and infrastructure constraints.
What's the Difference Between Cloud, Self-Hosted, and Hybrid Scanning?
The three deployment models differ in where the scanning workload executes and where results are stored, not necessarily in scan accuracy:
- Pure SaaS: The vendor's cloud ingests your repository contents (or metadata like manifests and lockfiles), runs analysis on vendor infrastructure, and stores findings in the vendor's environment. You interact through a web dashboard and API.
- Self-hosted: The scanning engine, policy evaluation, and results database run inside your own infrastructure — your VPC, your Kubernetes cluster, or an on-prem network. Source code and dependency data never leave your network boundary.
- Hybrid: A middle path where the scanning engine runs in your environment (or air-gapped), while a management/reporting layer can optionally sync summarized, non-sensitive metadata to a cloud console for fleet-wide visibility.
Endor Labs' public documentation and go-to-market positioning describe a cloud-based platform: repositories are connected to their service and analysis happens on their infrastructure. That is a legitimate and common architecture for SCA tools, and it removes infrastructure burden from the customer. Safeguard's platform is built to run in both modes — SaaS for teams that want zero infrastructure overhead, and self-hosted/hybrid for teams whose security or regulatory posture requires code to stay on-premises. This is the first concrete, checkable distinction: ask any vendor for their deployment architecture diagram and data flow documentation before signing, and compare it against what they actually publish.
Where Does Your Source Code Actually Go?
This is the question that matters most for security and legal teams, and it's directly verifiable by reading a vendor's data processing documentation or asking for a data flow diagram.
In a pure SaaS model, some combination of source code, dependency manifests, SBOMs, and build metadata is transmitted to and processed on the vendor's cloud infrastructure — even if the vendor doesn't persist raw source code long-term, it necessarily passes through their environment during analysis. That's a real trust boundary: your data crosses into a third party's infrastructure, subject to their access controls, retention policies, and jurisdiction.
In Safeguard's self-hosted deployment, the scanning engine runs inside the customer's own network. Source code, dependency trees, and build artifacts are analyzed in place; only the findings you choose to export leave the boundary. For organizations with strict IP protection requirements, government contracts, or contractual clauses that prohibit sending source code to third-party clouds, this isn't a preference — it's often a hard requirement that a SaaS-only vendor cannot satisfy without a customer accepting a data flow they may not be permitted to accept.
The practical takeaway: don't take "we don't store your code" at face value from any vendor, including Safeguard. Ask specifically whether code ever transits or is processed on vendor-owned infrastructure, even transiently. That single answer determines whether a tool is compatible with data residency and export-control obligations before you get to any feature comparison.
Can You Meet Air-Gapped or Regulated Environment Requirements?
Some environments — defense contractors, critical infrastructure, financial institutions with strict segmentation rules — cannot connect internal source control or build systems to the public internet at all, regardless of encryption or access controls. This is a binary requirement: a scanner either can run fully disconnected from the internet, or it cannot.
A pure SaaS architecture, by definition, requires network egress from the customer environment to the vendor's cloud in order to submit code or metadata for analysis. If Endor Labs' platform is architected as a cloud service (as its own documentation describes), teams operating in fully air-gapped networks would need to evaluate whether any connectivity path — even periodic, batched, or metadata-only — is possible or acceptable under their security policy.
Safeguard's self-hosted deployment is designed to run without outbound connectivity to Safeguard's infrastructure, with vulnerability database updates deliverable via offline bundle import rather than live API calls. This lets the scanner operate inside a fully segmented network. If your organization has an air-gap requirement written into a compliance framework or contract, this is a dimension worth testing directly in a proof-of-concept rather than taking either vendor's word for it — request a deployment where you physically disconnect the network and confirm the scanner still produces results.
How Does Deployment Model Affect Compliance and Audit Scope?
Compliance frameworks like SOC 2, ISO 27001, and FedRAMP care about where regulated data flows and who has access to it. Deployment model directly changes your audit scope in a way that's easy to underestimate during procurement.
With a SaaS tool, the vendor becomes part of your third-party risk assessment and, depending on the framework, part of your audit boundary. You'll need to review the vendor's own SOC 2 report, ask about their subprocessors, and document the data flow into their environment as part of your own control narrative. This is standard practice and not disqualifying — but it is additional audit surface that didn't exist before you adopted the tool.
With a self-hosted deployment, the scanning infrastructure lives inside your existing audited environment, so it inherits your existing controls (access management, network segmentation, logging) rather than introducing a new third-party data flow to document. This can meaningfully simplify an audit narrative for teams that already have a mature internal control environment, because the auditor's questions about "who else can see this data" have a shorter answer.
Neither model is inherently more or less secure — a well-run SaaS vendor with a current SOC 2 report can be a perfectly defensible choice, and self-hosting shifts operational security burden (patching, uptime, backups) onto your own team. The concrete action item: get the vendor's actual SOC 2 report and subprocessor list, not a sales assertion, before treating either model as "compliant by default."
What About Speed of Setup vs Long-Term Infrastructure Ownership?
This is a real, verifiable tradeoff rather than a marketing point. A SaaS platform can typically be connected to a repository and producing results within minutes, because there's no infrastructure to provision — this is one of the genuine advantages of the cloud model and a reasonable reason to choose it for teams prioritizing time-to-value. A self-hosted deployment requires provisioning compute, managing updates, and taking ownership of uptime and scaling, which is real operational work that a security or platform team has to plan for and staff.
Safeguard's SaaS offering is built to match that same fast-connect experience for teams that want it, while the self-hosted path exists for teams willing to take on that operational ownership in exchange for the control described above. The honest comparison isn't "one model is strictly better" — it's that SaaS optimizes for speed and reduced operational burden, while self-hosted optimizes for data control and audit simplicity. Which one wins depends on which constraint — deployment speed or data boundary control — is non-negotiable for your organization.
How Safeguard Helps
Safeguard was built so that deployment model is a configuration decision, not a vendor-lock-in decision. The same policy engine, vulnerability intelligence, and SBOM generation run whether you connect Safeguard as a SaaS service or deploy it inside your own VPC or air-gapped network — you're not choosing a different product or a reduced feature set depending on where it runs.
Concretely, Safeguard supports:
- SaaS connect-and-scan for teams that want results in minutes without infrastructure provisioning.
- Self-hosted deployment where the scanning engine, database, and policy evaluation run entirely inside customer infrastructure, with no source code transiting Safeguard's cloud.
- Offline vulnerability database updates for air-gapped environments that cannot maintain outbound connectivity to any external service.
- Exportable findings and SBOMs so audit evidence and compliance artifacts stay in formats your existing GRC tooling already consumes, regardless of deployment mode.
If your organization is evaluating SCA and AppSec tooling and deployment architecture is a gating requirement — because of data residency law, a government contract, or an internal policy against sending source code to third-party clouds — ask any vendor, including Safeguard, for their actual data flow diagram and a proof-of-concept in your target environment before deciding. The deployment model determines whether a tool is usable at all in your environment; the scanning quality only matters once that first question is answered.