Security and platform teams evaluating Socket.dev often ask a version of the same question before they connect it to a single repository: does this tool store, upload, or otherwise retain our proprietary source code once it's installed? It's a fair question, and not a paranoid one — any tool that plugs into your SCM, CI pipeline, or package manager sits close enough to your codebase that the answer matters for SOC 2 audits, customer security questionnaires, and basic engineering hygiene.
The honest answer requires separating two different things that get conflated in supply chain security marketing: analyzing the open-source packages your project depends on, and accessing the private code your own engineers write. Socket.dev's core engine is built around the first — deep inspection of public package registry contents like npm and PyPI. Its GitHub App integration, however, does request repository-level permissions to power pull request checks and dependency-diff comments. Below, we walk through what that distinction actually means in practice, and how Safeguard's architecture approaches the same problem differently.
What Does "Storing Source Code" Actually Mean for a Supply Chain Tool?
Not all code access is equal, and vendors rarely explain the distinction clearly. There are at least three separate categories worth separating when you evaluate any dependency security tool:
- Manifest and lockfile access — reading
package.json,package-lock.json,requirements.txt,go.mod, or similar files to build a dependency tree. This is metadata about what you depend on, not your application logic. - Public package source analysis — downloading and statically or dynamically analyzing the code of the open-source packages themselves, which are already public on npm, PyPI, crates.io, or similar registries.
- Private repository source access — reading the actual application code your engineers wrote, typically granted through a GitHub App, GitLab integration, or CI token with
contents: readscope.
A tool can legitimately need the first two without ever touching the third. Whether it needs the third depends entirely on how deep its PR-level integration goes — for example, whether it diffs your actual application files or only the manifest/lockfile changes in a pull request.
How Does Socket.dev Access Your Repositories?
Socket.dev's primary analysis target is the open-source package itself, not your proprietary code — this is the basis of its "deep package inspection" approach to catching things like suspicious install scripts, obfuscated payloads, or unexpected network calls in a dependency before it lands in your build. That analysis runs against publicly available package source pulled from registries, which is materially different from analyzing your own codebase.
Where it gets less clear-cut is the GitHub App integration used for pull request scanning and dependency-diff alerts. Like most PR-gating security tools, this integration is installed with GitHub App permissions, which by default can include read access to repository contents in order to inspect diffs and comment on pull requests. The specific scopes requested, and how narrowly Socket limits what it reads and retains from that access, are documented in Socket's own installation flow and privacy materials — that's the place to look for authoritative, up-to-date answers, since GitHub App permission scopes and data-handling terms can change between releases. We'd encourage any team evaluating Socket.dev to pull the exact permission list shown at install time and Socket's current privacy policy rather than relying on secondhand summaries, including this one.
Where Does Safeguard Draw the Line on Code Access?
Safeguard was built around a narrower default: our dependency and SBOM analysis is designed to operate on manifest files, lockfiles, and build metadata first, and we scope any deeper repository access explicitly and separately rather than bundling it into a single broad permission grant. Concretely:
- Manifest-first scanning. Our default integration path ingests dependency manifests and SBOMs (CycloneDX/SPDX) to identify vulnerable and malicious packages without requiring read access to your application source.
- Deployment flexibility. Safeguard supports self-hosted and VPC-isolated deployment models in addition to SaaS, so teams with strict data residency or code-exposure requirements can keep scanning inside their own network boundary rather than sending anything to a third-party cloud.
- Tenant isolation. In our multi-tenant SaaS offering, customer data is logically isolated per tenant, with access controls and audit logging built around SOC 2-aligned change management practices.
This isn't a claim that manifest-first analysis catches everything a full source-code scan would — deeper SAST and secrets-detection capabilities do require broader read access when a customer opts into them. The point is that the access is opt-in and scoped, not a default requirement to use the product.
Public Package Analysis vs. Private Codebase Scanning: Why the Difference Matters
If your primary concern is "will a vendor upload my proprietary source code to their servers," the question you actually need answered is narrower than "does this tool touch code at all." Almost every supply chain security tool touches code in some form — that's how it finds vulnerable and malicious dependencies. The real question is whose code, and under what permission scope.
Socket.dev's core value is in analyzing public, already-open-source package contents, which carries essentially no confidentiality exposure for your organization since that code is public regardless of Socket's involvement. Its GitHub App's repository permissions are the part worth scrutinizing directly against your own compliance requirements, because that's where private code could theoretically be read, even if only transiently for diff generation.
Safeguard's default posture keeps the two concerns separated at the architecture level: dependency and SBOM analysis doesn't require repository content access at all, and any feature that does need broader access — such as SAST — is a distinct, explicitly granted capability rather than a blanket permission bundled into onboarding.
Data Retention and Compliance: What to Ask Any Vendor
Rather than taking any vendor's marketing claims at face value (including ours), here's a short checklist worth running against Socket.dev, Safeguard, or any other supply chain security tool before you connect it to production repositories:
- What exact GitHub/GitLab App permissions does the integration request, and can they be scoped down? Check the install screen, not just the marketing page.
- Is there a self-hosted or VPC deployment option, or is SaaS the only path? This determines whether code ever leaves your network boundary at all.
- What does the vendor's privacy policy say about retention of any code, diffs, or manifests it processes, and for how long?
- Does the vendor have a current SOC 2 Type II report, and will they share it under NDA? A report you can actually read is worth more than a badge on a website.
- Is analysis limited to public package content, or does it require reading your private application code by default?
Any credible vendor in this space should be able to answer all five directly, in writing, without hedging.
How Safeguard Helps
Safeguard is built for teams that need supply chain visibility — SBOM generation, dependency vulnerability scanning, and malicious package detection — without treating broad source code access as a precondition for basic protection. Our manifest-first ingestion model means most customers get meaningful risk coverage using dependency metadata alone, and we support self-hosted or VPC-isolated deployments for organizations where code residency is a hard requirement rather than a preference.
When customers do need deeper analysis — SAST, secrets detection, or custom policy enforcement across a monorepo — those capabilities are opt-in, scoped to what they cover, and documented as part of our SOC 2-aligned compliance program rather than bundled invisibly into a general onboarding flow. If you're comparing tools for a security questionnaire or vendor risk assessment, we'd rather you ask us the same five questions above and hold us to the same standard we're suggesting you apply to everyone else, including Socket.dev.
If your team is navigating a vendor security review and wants a straight answer about what Safeguard reads, stores, and retains, our team can walk through the exact architecture and share our SOC 2 report directly.