Every AppSec vendor's homepage carries the same trio of badges — SOC 2, sometimes ISO 27001, sometimes a GDPR checkmark — sitting quietly in the footer. For a buyer running procurement on a compressed timeline, those badges function as a shortcut: "compliant" becomes shorthand for "safe to onboard." But a SOC 2 badge is not a single, comparable fact. It can represent a Type I report issued once, a Type II report covering a year of continuous operation, an audit scoped narrowly to a marketing site, or one scoped to the exact production systems that will touch your source code and dependency graph. If you're evaluating Safeguard against Endor Labs — or any two vendors that both claim SOC 2 compliance — the badge itself tells you almost nothing. What matters is what's underneath it. Here's what to actually verify, and where we draw the line on what we will and won't assert.
What Does "SOC 2 Compliant" Actually Mean for an AppSec Vendor?
SOC 2 isn't a certification in the ISO sense — there's no pass/fail seal issued by a standards body. It's an attestation report, written by an independent CPA firm, that evaluates a company's controls against some subset of five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Every vendor elects which criteria to include. A vendor can be fully truthful when it says "SOC 2 compliant" while having scoped the report to security only, leaving confidentiality and processing integrity — arguably the two categories that matter most for a tool that ingests your source code, SBOMs, or CI credentials — out of the audit entirely.
For a software supply chain security vendor specifically, the report's coverage of confidentiality controls (how source code, manifests, and secrets are handled once uploaded) is at least as important as the security criteria most buyers default to checking. Before you compare two vendors on "who has SOC 2," ask each one which Trust Services Categories their report actually covers. That single question filters out a surprising number of apples-to-oranges comparisons.
Type I or Type II — Which Report Are You Actually Being Shown?
A Type I report assesses whether controls are suitably designed at a single point in time. A Type II report assesses whether those controls actually operated effectively over an observation window, typically six to twelve months. For a vendor that will sit inside your build pipeline with read access to dependency manifests or source code, Type II is the more meaningful signal — it demonstrates sustained operation, not a policy document written the week before the audit.
Endor Labs has stated on its own blog that it completed a SOC 2 Type II audit; the company also operates a public trust center (trust.endorlabs.com) built on Drata where prospective customers can request access to compliance artifacts. That's a legitimate, checkable data point, and it's worth confirming directly with them rather than taking a marketing page at face value — ask for the observation window, whether the opinion letter noted any exceptions, and whether the report has been renewed on schedule since. A lapsed or unrenewed Type II report from two audit cycles ago is a different risk posture than a current one, even though both vendors would technically list "SOC 2 Type II" on a slide.
The same standard applies to Safeguard, and we'd rather you hold us to it than take our word for it: ask for the current report, the audit window, and the auditor's opinion, and read it yourself before treating "SOC 2" as a checked box.
Does the Audit Scope Cover the Whole Product, or Just Part of It?
This is the question buyers skip most often, and it's the one that causes the most surprises later. Security vendors — especially fast-growing ones — routinely add product lines, acquire smaller tools, or ship new agents and CLI components faster than their compliance boundary expands to cover them. A SOC 2 report scoped to "the web application" doesn't automatically tell you anything about the reachability engine, the CI/CD integration, the CLI binary that runs in your build agents, or an MCP/agent surface that has its own network and credential footprint.
Concretely: ask which systems, environments, and data flows are inside the report's boundary, not just which product name is on the cover page. Ask whether newly shipped features or acquired components have been folded into the existing audit period or are still pending their first cycle. This applies equally whether you're scoping Endor Labs' reachability analysis and CI integrations or Safeguard's scanning pipeline, SCM integrations, and CLI/MCP surface. On our side, we can tell you plainly how our own systems are organized: tenant and organization isolation is enforced end-to-end across data access paths, with dedicated headers carried through every service boundary, and access to scan results and export paths is gated rather than open by default. Ask us — or any vendor — to walk the audit boundary against the actual architecture diagram, not just the report title.
How Transparent Is the Vendor About Subprocessors and Data Residency?
A supply chain security tool has to see something to analyze it — source code, dependency manifests, build artifacts, or at minimum package metadata. How much it sees, where that data lives once uploaded, and who else (cloud providers, LLM providers, analytics vendors) touches it in transit is one of the most concrete, non-fabricated questions you can ask any vendor in this category. It's also one procurement teams routinely forget to ask until legal flags it during contract review.
Request the current subprocessor list, ask whether data residency options exist for regulated environments, and — specific to this category — ask whether the tool requires uploading full source code or can operate primarily off manifests, lockfiles, and metadata. That distinction changes your own data-flow diagram and potentially your own audit boundary the moment you turn the tool on. This is a fair question to put to Endor Labs directly, and a fair one to put to us. We'd rather you ask it up front than discover the answer during your own next audit cycle.
Does the Vendor Practice What It Sells?
Any company selling software supply chain security should be willing to show its own supply chain hygiene: does it publish or make available an SBOM for its own product, does it disclose a vulnerability handling and patching process, and does it treat its own dependency risk with the same rigor it's asking you to apply to yours? This is checkable without guesswork — it's either published, available on request, or it isn't. It's also a reasonable tie-breaker when two vendors otherwise look comparable on paper.
We hold ourselves to this standard at Safeguard: our own build and release pipeline runs through the same categories of scanning, tenant-isolated access control, and change-evidence capture (commit author, reviewer approval, tests run, rollback plan) that our product is built to give you visibility into for your own codebase. If a vendor won't answer basic questions about its own dependency posture, that's worth weighing before you hand it read access to yours.
How Safeguard Helps
The point of this comparison isn't to win an argument about who has the shinier badge — it's to give you a repeatable checklist so the SOC 2 conversation stops being decorative and starts being useful. Where Safeguard tries to be different is in making that verification easier rather than something you have to extract:
- SBOM generation as a first-class output, not an afterthought — so your own compliance and procurement teams have a current, exportable inventory to hand to auditors or downstream customers without a separate tooling project.
- Tenant and organization isolation enforced across every service boundary, with dedicated headers and access gating carried through scan, export, and query paths — the kind of architectural detail your security team can actually verify in a technical review, not just take on faith from a slide.
- Change and access evidence captured as a byproduct of normal operation — commit authorship, review approval, deployment metadata, and rollback plans are part of how we ship, which is the same evidence trail your own SOC 2 auditor will eventually ask you to produce for any vendor you've onboarded.
- Reachability and exposure context alongside raw CVE and dependency data, so your AppSec team isn't triaging by severity score alone — which matters for the same reason audit scope matters: a control (or a vulnerability) that looks identical on paper can carry very different real-world risk depending on what's actually reachable in your environment.
- A direct answer when you ask. If you want our current SOC 2 report, our audit boundary, our subprocessor list, or our own dependency posture, ask your Safeguard contact — we'd rather you verify it than accept it.
Whichever vendor you choose, the checklist is the same: confirm which Trust Services Criteria are actually in scope, get the Type II report and read the opinion letter yourself, map the audit boundary against the real architecture, ask about subprocessors and data residency, and see whether the vendor applies its own product to its own supply chain. A vendor that welcomes those questions is telling you something important before you've even opened the contract.