Trust & Security

1. Overview

You are about to point a tool at every file in your repository. This page is the complete account of what happens to those files — where they go, how long they exist, who can see them and which controls stand between them and anyone else. It is written by the people who run the system and every statement on it is checked against the code.

What we do with your code

• Fetch it from your git host with the access you granted, analyse it on a server we operate, and delete the working copy when the scan finishes.
• Keep the results: each finding's message, file path and line number, the verdict, the score and the summary.
• On the tiers that include AI review or auto-fix, send the files under review to our AI provider, which retains them for a fixed window and does not train on them.
• Post the verdict back to your git host as a status, comment, branch or pull request.

What we never do

• Store your source code after a scan, in the database, in logs or in error reports.
• Execute your code on our servers — the modules that would need to are refused here and run only in your own CI or on your machine.
• Sell, share or use your code or findings for anything other than scanning it for you, or use them to train models.
• Handle your card details — payment is on pages Stripe hosts.
• Claim a certification we do not hold. There is no SOC 2, ISO 27001 or penetration-test report today; see Compliance and attestations.

2. Infrastructure and hosting

GateTest does not run on Vercel or any other serverless platform. The full list of third parties that touch customer data, with what each receives, is the Sub-processors page.

3. The life of a scan

Every hosted scan follows the same path. Nothing is skipped and nothing is added for particular customers.

• Fetch. The engine downloads an archive of the commit to be scanned from your git host, using the installation token (GitHub) or the token you issued (Gluecron).
• Memoise. The archive is held in memory for at most 120 seconds so that a burst of events for the same commit does not fetch it repeatedly.
• Unpack. The archive is extracted into a temporary workspace on the scanning server, private to that scan.
• Scan. The deterministic modules read the workspace. On AI tiers, the files under review are sent to the AI provider (see AI provider security).
• Delete. The workspace is removed when the scan finishes, whether it passed, failed or errored.
• Report. The verdict is written to the database and posted back to the git host.

What persists

• Findings: message, file path, line number, rule and severity.
• The verdict, the score and the summary for the scan.
• The scan's metadata: repository URL, commit, tier, timing.

Source code does not persist. Not in the database, not in logs, not in error reports, and not in the AI provider beyond its fixed retention window. If you ask us for a copy of your code after a scan, we cannot provide one, because we do not have it.

How long, who can read it, and how to delete it

• Retention. Findings, verdicts and scan metadata are kept until you ask us to delete them — there is no automatic expiry today (tracked under Known limitations).
• Who can read it. Engineering staff, for support and debugging, through the operator console (a single shared credential, held only in server environment configuration, never shipped to the client) or direct database access. There is no per-person access review today; that gap is listed under Known limitations, not hidden.
• How to delete it. E-mail support@gatetest.io and ask us to delete your account, findings, or both. We complete deletion requests within 30 days; the Privacy Policy describes the same right in full.

4. Code we never run on our servers

The hosted engine is a static analyser. It reads your files; it does not execute them. The following modules would have to execute code from the repository being scanned, so the hosted engine refuses them outright — they are unavailable on our infrastructure regardless of tier or configuration:

• mutation — runs your own test suite repeatedly against mutated copies of your code.
• chaos — drives a headless browser against your application and fuzzes its inputs.
• unitTests — executes your unit-test runner and whatever it loads.
• integrationTests — executes your integration-test runner, which typically starts your services.
• e2e — executes your end-to-end test runner and a browser.
• lint — runs your project's linter, which loads plugins from your dependency tree.

These modules run only where your code already runs: in your own CI through the GitHub Action, or on your own machine through the CLI. In both places the code executes under your account, with your credentials and your network, and nothing about the run reaches us except the findings if you choose to upload them.

There is no sandbox. We do not isolate customer code in a container or virtual machine, because we do not execute it. The control is refusal, not containment, and it is enforced in code rather than by policy. This is also why a hosted scan cannot be tricked into running a build script, a post-install hook or a test that happens to be in the repository.

5. Access and permissions

GitHub App

The App requests exactly the scopes the shipped code needs. The table is generated from the same declaration the engine and the Marketplace listing use, and a test fails the build if the code ever calls a GitHub endpoint outside it.

For readers who want to verify rather than trust, these are the endpoints that force each scope:

The App subscribes to 4 webhook events: push, pull_request, workflow_run, issue_comment. No other event reaches us.

The App is published as gatetest-hq; the permission prompt GitHub shows at install time is the list above.

Sign-in

Signing in with GitHub uses the OAuth scopes read:user and user:email — your login and e-mail address only; sign-in never grants repository access.

Gluecron

Gluecron repositories are connected through a push contract: Gluecron sends push events to our endpoint authenticated with a shared secret (bearer token or HMAC signature), and the engine fetches the commit with a token you issue for scanning. We hold no standing credential to your Gluecron account beyond that token.

6. Encryption and secrets

In transit

• TLS on every connection, with HTTP Strict Transport Security set for two years, includeSubDomains and preload.
• A Content-Security-Policy on every response, plus X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, a strict-origin-when-cross-origin referrer policy and a Permissions-Policy that disables camera, microphone and geolocation.

Sessions

Your session cookie is encrypted with AES-256-GCM and authenticated with an HMAC, so it can be neither read nor forged without the server key. It is HttpOnly, SameSite=Lax and Secure, and expires after 30 days. The full cookie inventory is in the Cookie Policy.

At rest

• Git-host integration tokens you connect are encrypted with AES-256-GCM before they are written to the database, using a key that exists only in the server environment.
• The database is encrypted at rest by the managed database provider; every table inherits it.
• Hosted MCP API keys are delivered by e-mail after checkout and stored in the database, where they rely on the provider's encryption at rest; they are not additionally hashed. Treat them as you would any bearer credential.

7. Webhooks and integrity

• Fail-closed verification. Every inbound webhook — Stripe, GitHub and Gluecron — is verified before anything else happens. A missing, malformed or invalid signature or bearer token is rejected, and the comparison is constant-time so timing cannot leak the secret.
• Placeholder detection. Configuration is checked for placeholder secrets. An integration whose secret is still a placeholder is treated as unconfigured, not as trusted.
• Cron secret. Scheduled endpoints require a dedicated secret; nothing on a timer can be triggered anonymously.
• Parameterised SQL. All database access uses parameterised queries.
• SSRF guard. URL scans refuse private, loopback and link-local address ranges, so the scanner cannot be aimed at internal infrastructure.
• Hash-chained audit log. Security-relevant actions are written to an append-only log where each entry commits to the hash of the previous one, so alteration is detectable. It is retained for 7 years.

8. AI provider security

The deterministic scan uses no AI. Every module in the standard suite is rule-based and runs entirely on our server; nothing leaves it. AI is used only on the paths that say so — AI review, auto-fix and the Forensic diagnosis — and only when your tier or request includes them.

• Provider. Anthropic (Anthropic, PBC), via its API under commercial terms — terms.
• What is sent. The complete contents of the files under review or being fixed, their paths and the finding text. Not the whole repository; not files outside the finding.
• Retention. The provider retains API inputs and outputs for 30 days under its standard terms. This is standard retention, not a zero-data-retention arrangement; we say so because customers with strict requirements need to know the difference.
• No training. Inputs are not used to train the provider's models.
• Bring your own key. If you supply your own provider API key, it is used for that request only and is never stored, logged or echoed back. Requests made with your key are billed to you by the provider directly.
• Prompt-injection guard. Repository content is screened for instructions aimed at the model before it is placed in a prompt; a suspicious file is flagged rather than trusted.
• Output screening. Model output is screened for leaked secrets and credentials before it is used in a fix or shown to a user.
• Optional second opinion. On Forensic scans you may opt in to a consensus review by OpenAI, which then receives the same files for those fixes. It is off unless you turn it on.

9. Payments

Payments, subscriptions and the billing portal are handled by Stripe (Stripe, Inc.). Card details are entered on pages Stripe hosts and never pass through, or are stored on, our servers; what we receive is the outcome of the payment and the identifiers needed to link it to your account and scan. PCI DSS obligations for card data are met by Stripe as a certified Level 1 service provider. We make no PCI attestation of our own and do not need one, because card data never touches us.

10. Monitoring and logging

• Error monitoring. Application errors are reported to Sentry (Functional Software, Inc.). Reports include the request URL, request headers and client IP address. Request bodies, source code, prompts, API keys and cookies are scrubbed before sending.
• Session replay. The site records browser session replays for 10% of sessions and 100% of sessions in which an error occurs, so that we can reproduce faults. Replays are scrubbed by the same rules before they leave your browser.
• IP addresses. Your IP address is used in memory on each server for rate limiting and appears in error reports as above. It is not written to a long-term store of its own.
• Audit log. Security-relevant actions are hash-chained and retained for 7 years, as described under Webhooks and integrity.
• Engine telemetry. The CLI and engine send anonymous usage signals — module names and finding counts, never code, paths or finding text. Opt out with the environment variable GATETEST_NO_TELEMETRY=1 or with "telemetry": false in .gatetest.json.

11. Compliance and attestations

We hold no third-party certification today. There is no SOC 2 report, no ISO 27001 certificate and no independent penetration-test report for GateTest. If a vendor questionnaire asks for one, the honest answer is that it does not exist yet. SOC 2 readiness work exists internally; we will publish the report on this page when there is one, and not before.

What we can offer now:

• Support for your obligations under the GDPR, the UK GDPR, the New Zealand Privacy Act 2020 and the CCPA/CPRA, as a processor of the data in your repositories.
• A Data Processing Addendum that applies automatically to every customer, incorporates the EU Standard Contractual Clauses and the UK Addendum for transfers, and sets out our technical and organisational measures in its Annex II. A countersigned copy is available on request.
• A published Sub-processors list, with each provider's entity, location, purpose, the data it receives and its own data-protection terms.
• Written answers to reasonable security questionnaires, and the audit right described in the DPA.
• The Privacy Policy and Cookie Policy, which describe the account, billing and telemetry data we hold as a controller.

12. Found a security issue?

Please tell us. E-mail support@gatetest.io with steps to reproduce, the impact as you understand it, and the affected URL, endpoint or package version. We aim to acknowledge every report within 5 business days, keep you informed as we investigate and fix, and credit you if you would like us to.

Safe harbour

We will not pursue legal action against, or report to law enforcement, security research conducted in good faith that: avoids privacy violations, data destruction and any degradation of the service (including denial-of-service testing); does not access, modify or retain data belonging to other customers; stops and reports immediately on encountering such data; and gives us reasonable time to fix an issue before it is disclosed publicly. If you are unsure whether something is in scope, ask first.

Out of scope

• Findings that require a compromised customer device or credentials.
• Volumetric denial-of-service, rate-limit exhaustion and automated scanning that degrades the service.
• Reports against third-party services we do not operate — our git-host, payment, database and AI providers each run their own programmes.

A machine-readable version of this policy is published at https://gatetest.io/.well-known/security.txt in the RFC 9116 format.

13. False positives

A finding that fires on code it should not have is a defect in the scanner, not a fact about your code. Every one we retract ships with a control-pair test — the exact line that fired it, pinned as a regression test so the same shape cannot fire again without the test failing first.

97 reported · 97 retracted · median 6.2 hours from report to fix, over the 4 reports whose report time is on record (23 rules retracted; a report that retracted several counts once). 2 of those are timed from the first commit that records the issue as filed, which can be later than the filing itself, so the real median may be longer, never shorter. The other 74 we found ourselves, in triage and in scans of our own code, or their report time is not on record — they are dated from the first commit of the fix, so they are counted but left out of the median rather than flattering it. Counted from docs/precision/retractions.json and regenerated at every build from the timestamps on each entry — not typed by hand.

Report one by e-mail to support@gatetest.io with the module, the rule and the line it fired on.

14. Known limitations

A security page that lists only strengths is marketing. These are the gaps we know about and have not yet closed:

• No execution isolation. Customer code is never executed on our servers, but where a future feature required it there is no container or virtual-machine sandbox in place today. The refusal list above is the control.
• Rate limits are per server instance. Limits are held in memory on each instance rather than in a shared store, so they apply per instance and reset on deploy.
• No self-serve deletion or export. Deleting your account and findings, or exporting them, is done by e-mailing us; there is no button yet. We complete requests within 30 days.
• Findings are retained until you ask. Scan findings are kept until a deletion request; there is no automatic expiry. Source code is never retained regardless.
• No third-party certification. No SOC 2, ISO 27001 or independent penetration test, as stated above.

When one of these changes, this page changes in the same release. If a limitation you care about is not listed, e-mail us and we will either add it or explain why it is not one.