When "Never Give Us Your Code" Is the Right Answer, Not a Dead End
Security and compliance teams evaluating a scanning vendor eventually reach a question that ends more deals than any pricing objection: where exactly does our source code go, and who or what touches it along the way. For a US financial institution vetting a vendor whose engineering team sits offshore, or a defense contractor bound by data residency requirements, or a healthcare organization with contractual limits on where patient-adjacent systems can send data, the honest answer for most cloud-based scanning tools is that the code has to leave the building. It gets uploaded, analyzed on the vendor's infrastructure, and the results come back. For a meaningful share of regulated buyers, that answer alone disqualifies the vendor before any conversation about detection quality or remediation speed even starts.
This is usually treated as an unsolvable tradeoff: either you get cloud-native scanning with all its convenience, or you protect data residency by staying with something slower and more manual. Safeguard's local runner exists because that tradeoff is not actually necessary.
How the local runner actually works
The local runner is a command-line tool that runs entirely on infrastructure the customer controls. Rather than granting Safeguard direct access to a repository, the customer runs the CLI on their own machine or their own infrastructure. The runner pulls the repository locally, performs the full scan on that machine, and pushes only the results back to Safeguard, encrypted. The source code itself never leaves the customer's environment at any point in that process.
That is a meaningfully different architecture than "we promise to delete your code after scanning" or "we encrypt data in transit and at rest." Those are reasonable safeguards, but they still require the code to physically transit to the vendor's infrastructure and trust the vendor's handling of it once it arrives. The local runner removes that transit entirely. There is no upload step to audit, no vendor-side retention policy to verify, because the vendor's scanning engine runs on the customer's own hardware, inside the customer's own network boundary, and only the analysis output, the findings, crosses back over.
Built to fit how security teams already operate
The local runner is designed to feel familiar to anyone who has used a modern developer CLI tool, operating in a style similar to tools like Claude Code or Codex, so there is not a steep learning curve for teams already comfortable with command-line developer tooling. It runs on macOS, Windows, and Linux, and it supports interactive use for a developer running it directly at a terminal, headless use for scripted or scheduled execution in a pipeline, and agent modes for more automated workflows. For organizations that want to deploy it at scale across a fleet of internal systems rather than machine by machine, a Kubernetes Helm operator supports self-hosted deployment.
None of this requires the customer to build custom infrastructure to make it work. It is a packaged tool that drops into an existing CI pipeline or a developer's local environment the same way any other CLI-based scanner would, with the one structural difference that matters most to a compliance reviewer: the code stays put.
Why this changes the shape of a security review
For teams evaluating scanning tools under strict data residency constraints, the local runner reframes the entire conversation. Instead of a security review that starts by asking whether the vendor can be trusted with an upload of proprietary source code, the review can start with a question that is much easier to answer affirmatively: does the encrypted output leaving our environment contain anything sensitive. Since that output is scan results and findings rather than the code itself, the answer to that question is far easier to defend to an internal audit committee or an external regulator.
This also matters for organizations with a hard requirement that certain systems never transmit source code outside a defined boundary, whether that boundary is a specific data center, a specific country, or a specific classification level. The local runner lets those systems get real, continuous scanning coverage without violating that boundary, because the scanning workload itself runs inside it.
A genuine answer, not a workaround
It is worth being clear that this is not a stripped-down or lesser way to use Safeguard. The scan that runs through the local runner is the same underlying scanning capability the platform runs anywhere else; what changes is where the computation happens and what crosses the network afterward. For a security or compliance team whose primary blocker has been data residency rather than scan quality, that is the distinction that matters.
If data residency has been the reason your team ruled out cloud-based scanning tools before now, it is worth taking a second look. Visit safeguard.sh to see how the local runner lets you get continuous supply-chain scanning without your source code ever leaving your own environment.
