Security
What ShipGate touches, and where your code actually goes.
Both entry points are hosted
Continuous CI and the free scan at /scan/repo both run on WholeStack infrastructure. There is no agent on your GitHub Actions runners. What differs is how the source arrives: a pull-request check fetches one commit via the GitHub App; the web scan is a repository or folder you submit. Say that in the security review rather than discovering it later.
Code and data handling
Continuous CI
The WholeStack GitHub App mints a short-lived installation token, fetches that single commit into a throwaway directory on WholeStack infrastructure — one commit deep, no history and no other branches — runs the gates there, and deletes the directory when the run ends. A fresh fetch happens per commit. The outcome is posted as the “WholeStack / Readiness Advisory” check. What persists is the run record: verdict, per-gate results, findings with file paths and messages, and the commit SHA.
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 the same 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, GitHub App installation 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