How It Works

Security

What ShipGate touches, and where your code actually goes.

Last updated: August 18, 2026

Know which path you are on

Continuous CI analyses your repository on your own GitHub Actions runners, with a workflow that asks for contents: read and nothing more. The free hosted scan at /scan/repo works the opposite way: you hand us a repository or folder so we can run the gates on it. Both are legitimate; they are not the same trade.

Code and Data Handling

The CI path

The workflow runs in your repository. It requests read access to repository contents, runs the gate suite there, writes a readiness report as a build artifact, and reports the outcome as the “WholeStack / Readiness Advisory” check on the commit. What leaves your environment is the run record — verdict, per-gate results, findings with file paths and messages — not a copy of the repository.

The hosted-scan path

A scan started from the web app needs the source to analyse it, so the repository or folder is transferred and scanned on our infrastructure. Findings, paths, and messages are retained with the scan record so you can come back to the report.

What a verdict is bound to

Every result is bound to the exact revision that produced it. A verdict from an older tree is not evidence about the current one, and ShipGate treats it as stale rather than carrying it forward.

Security Practices

  • In transit: HTTPS everywhere; HTTP is redirected.
  • At rest: application data in managed PostgreSQL; OAuth tokens encrypted before storage.
  • Access: role-based access control on workspace resources; SSO (SAML 2.0 or OIDC) and SCIM 2.0 directory sync on Enterprise; multi-factor available on accounts.
  • Audit: signed NDJSON audit-log export with a manifest and hash chain, so an export can be re-verified rather than merely trusted. Retention is configurable per workspace.

Certifications

ShipGate holds no SOC 2 report and no ISO 27001 certificate, and this site claims neither. If your procurement process needs one, say so at the start of the conversation and we will tell you plainly where that leaves us. What we can provide instead is a written security packet: the data-flow description above in detail, runner permission scopes, retention settings, failure modes including how to remove the check from your merge path, and direct answers to your questionnaire.

The longer version of all of this — controls, service levels, disclosure policy, and the list of what we deliberately do not claim — is on the Security & Trust page.

Sub-processors

ShipGate runs on the same infrastructure as the rest of the platform and shares one sub-processor list, rather than keeping a second copy here that could drift out of agreement with it. See the current list.

Reporting Vulnerabilities

Report vulnerabilities to security@shipgate.dev. We aim to acknowledge within two business days and will not take legal action against researchers who follow responsible disclosure practices. The full policy, including scope and timelines, is on the disclosure page.

Incident Response

If a breach affects user data we will notify affected users and the relevant authorities as required by applicable law, stating what was affected, what we did, and what you should do.

Contact

Security: security@shipgate.dev
Privacy: privacy@shipgate.dev