--- title: "Privacy Policy | ShipSafe" description: "How ShipSafe collects, uses, and protects your data." doc_version: 2026-10-05 last_updated: 2026-10-05T02:22:49.060Z canonical: https://ship-safe.co/privacy --- # Privacy Policy | ShipSafe Legal # Privacy Policy Last updated: September 17, 2026 Terms used here are defined in the [glossary](https://ship-safe.co/glossary). ## 1\. Introduction ShipSafe ("we," "us," or "our") operates the ship-safe.co website and related services. ShipSafe is a SaaS security scanner designed for applications built with AI-assisted coding tools such as Cursor, Lovable, Bolt, and v0\. You paste a GitHub repository URL, and ShipSafe scans your code to generate a plain-English security report. This Privacy Policy explains what data we collect, how we use it, and the choices you have. By using ShipSafe, you agree to the practices described in this policy. ## 2\. Information We Collect ### Account Information When you sign up via GitHub OAuth (powered by Clerk), we receive your name, email address, and GitHub profile information. We do not collect or store your GitHub password. During onboarding we also ask, optionally, which country you are in. You can skip it and everything still works. We store it as a two-letter country code and use it for one purpose: naming the rules a finding would fall under where you are — so that a readable user table is described as the kind of thing the GDPR is about if you are in Europe, or Israel's Protection of Privacy Law if you are here. That is framing, not a compliance audit: it does not change which checks we run, and we never state that your app is or is not compliant. ### Repository Data We access the source code of a GitHub repository through the GitHub API for scans you start and for scans you have set up in advance: a scan you submit in the app, from the CLI, or through the MCP server; a scheduled re-scan on a paid plan, at the cadence you set in Settings; and a pull request in a repository where you installed the ShipSafe GitHub App, where we read the files that pull request changed. The working copy of your source code is processed during the scan and **no copy of your repository is kept**. What is retained is the security report and its metadata (repository name, scan timestamp, findings) — and each finding stores a short, secret-redacted excerpt of the flagged code, so that the report can show you what it found. **GitHub OAuth Scope Disclosure:** ShipSafe requests the `repo` OAuth scope from GitHub. This scope grants both read and write access to your repositories, including private repositories. ShipSafe uses read access to fetch source code for scanning. It uses write access for two purposes only, and **only when you ask**: when you send fixes to GitHub from a scan, it creates a new branch, commits the fixes to that branch, and opens a pull request — GitHub’s page for approving a change — from it; and, only once you approve that pull request in ShipSafe (rather than merging it yourself on GitHub), ShipSafe merges that one pull request into your default branch, using the same GitHub access you granted, pinned to the exact change the receipt describes, so the change is attributed to your own account. Nothing is scheduled: no fix is written, sent or merged on its own, and ShipSafe never writes to your default branch except through that one approved merge. It never deletes anything outside the branch it created: a fix branch that ends up empty is removed, and a later run on the same scan, where no earlier fix is still waiting for your approval, moves that branch back to your default branch’s head before it starts. The broad `repo` scope is required because GitHub does not offer a read-only OAuth scope for private repositories. You can revoke ShipSafe's access at any time from your [GitHub Settings > Applications](https://github.com/settings/applications). ### GitHub App Installation Data If you install the ShipSafe GitHub App, we store one installation record for it: the GitHub installation ID, the login of the account or organization you installed it on, whether that account is a user or an organization, whether GitHub has suspended the installation, the ShipSafe account it is linked to, and the time it was created. We use it for two things. First, as the gate on the App itself: an installation that is not linked to a ShipSafe account is refused before anything is read or written. Second, as evidence that you control a repository — a scan can only be published as a public receipt or badge, and our deeper credential checks can only run, where the repository owner matches your connected GitHub login or one of your installations; a suspended installation counts for nothing. We do not store a list of your repositories, and we keep nothing from the pull requests the App reviews. The changed files are read into memory at the commit under review, scanned there, and the results are written back to that pull request only — ShipSafe keeps no copy of the code and no record of the findings. ### Live-URL Scan Data If you use the live-URL scan, we collect the application URL you submit and your confirmation that you are authorized to scan it. Our servers then make read-only requests to that URL and its public assets (such as JavaScript bundles). The retrieved content is analyzed **in memory** and **no copy of it is kept**; we retain the resulting findings — the type and location of each issue, together with a short, secret-redacted excerpt of the evidence behind it — and the submitted URL. Content from a live-URL scan is **not** sent to any third-party AI provider. To keep an accountable record of authorization, we also store a short log entry for each live-URL scan: your account, the target host (not the full URL or query string), the time, and the version of these terms you accepted. We keep this record on the basis of our legitimate interest in preventing misuse of the scanner and resolving any dispute over who authorized a scan, and we retain it for up to 90 days before automatically deleting it. Where a scan detects a secret, we **redact the secret value before storing the finding**, so our stored findings are designed not to retain a recoverable credential. ### Proving You Control an Address A scan you start on our site normally performs only reading checks. If you want us to run the deeper checks against a running application — the ones that look for files that should not be public, and that re-check a fix from outside — you first prove the address is yours. We generate a single-use token, you publish it at a fixed path on that exact address, and we fetch it back over HTTPS without following a redirect anywhere else. We store the address you proved, the token, and the times it was issued and confirmed. We keep it because it is the record of your authorization, and because it expires: a proof covers only that one address and only your account, and lapses after thirty days, after which we re-check rather than assume. It is deleted with your account. We never treat one customer's proof as authorization for anyone else. ### Usage Data We collect standard usage information such as pages visited, scan frequency, feature usage, browser type, and device information to improve the service. ### Payment Information Payments are processed by Polar. We do not store your credit card number, CVC, or full card details on our servers. Polar is the merchant of record and holds your billing details. We do not receive your card number, the last four digits, the card brand, or your billing address; what reaches us is the fact that a payment succeeded and which plan it was for. ### Contact Form If you write to us through the contact form, we store the name, email address and message you send, together with whether our notification email about it went out. We store the message rather than relying on email alone so that a mail failure cannot silently lose what you sent us. We use it to reply to you and for nothing else — it is not used for marketing. We do **not** store your IP address. We store a one-way hash of it, which we use to rate-limit the form and to recognise repeated abuse; the hash cannot be turned back into an address. If your message contains something that looks like a secret — an API key, a token — we redact that value before the message is stored. ## 3\. How We Use Your Information - **Provide and operate the service** — running security scans, generating reports, and managing your account. - **Improve the service** — analyzing usage patterns to enhance scan accuracy, performance, and user experience. - **Improve detection accuracy** — when you mark a finding as a false positive, in the web app, the CLI or the MCP server, we keep a report of it so we can fix the rule that misfired. That report holds the rule that fired, the file path and line, the reason you typed, and a short excerpt of the code around the flagged line, with any detected secret value redacted before it is stored. These reports are the one thing you give us that is pooled: they go into a single queue we review across all accounts, so a rule that misfires on your code can be fixed for everyone. They are never used to train an AI model, and one customer's report never automatically suppresses a finding for another — a person reads it and edits the rule. The code excerpt is short-lived; see Section 4. - **Send notifications** — transactional emails (scan results, billing receipts, and a receipt when a fix run finishes) and occasional product updates. You can opt out of non-essential communications at any time. Unsubscribe requests are processed immediately upon receipt. - **Enforce terms and prevent abuse** — detecting and preventing misuse of the platform. ### Public verification pages Part of what ShipSafe sells is proof that someone other than us can check. To provide it we publish a redacted page about a scan, on the public internet, in two situations. The first is a badge. If your plan includes the ShipSafe Verified badge, every completed scan of a GitHub repository you control issues a badge for that repository, or refreshes one already issued. That creates a public report page at ship-safe.co/report/… and a status image at ship-safe.co/badge/… . It happens as part of the scan — you do not have to embed the badge anywhere for the page to exist, and a badge already issued keeps refreshing for its remaining window even if you later change plan. The second is exporting a PDF. If you export a scan that has no badge, we publish a receipt page at ship-safe.co/receipt/… and put its link in the PDF, so whoever you send the PDF to can check the numbers against our own record instead of trusting a file that could have been edited on the way. What these pages show: the repository URL or the host of the app that was scanned, the date of the scan, the number of findings at each severity, the platform and languages we detected and, for a badge, the issue and expiry dates and the dates of later re-scans. What they never show: the findings, file paths, code, secret values, or your name or email address. Note that a GitHub repository URL contains the account that owns it, so publishing one identifies that account. Anyone holding the link can open these pages without signing in. The link is a random, unguessable token; we do not list these pages in any directory and they are not in our sitemap, so the link is the only way to reach one. They are, however, built to be found and indexed once something links to them — that is what an embedded badge does — so treat a published page as public. A search engine that reaches the link can index it. You can take any published page down. See Section 4. ## 4\. Data Retention **Source code** is fetched only for the duration of a scan. The working copy — every file we read out of your repository — is held in memory while the scan runs and is discarded when it finishes; we keep no copy of your repository. A few much smaller things derived from that code do outlive the scan, and each is listed below: the short excerpt stored with each finding; on repository scans, a manifest of your file paths with a hash of each file's contents so a later scan can tell what changed; and, if you send fixes to GitHub, the record of that fix run, which for a finding the fix left still there keeps one redacted line of the file. The manifest holds hashes, not code, and your code cannot be reconstructed from it. Specific retention periods for other data categories: - **Account data** — retained while your account is active, deleted within 30 days of account deletion. - **Scan reports and findings** — retained while your account is active, then deleted on account closure. A finding stores the rule, the file and line, and a short code snippet showing the issue; any detected secret value in that snippet is redacted before it is stored. During the scan, an automated reviewer reads as many findings as its budget and time allow — some kinds of findings are never sent to it, and once its budget or time runs out for that scan the rest ship unreviewed. A finding that reviewer is confident has no vulnerability is then, budget and time allowing, checked by a second, independent reviewer that tries to show it is exploitable in that file; only when both agree it is not real is the finding not shown and not counted — when that second check cannot run, the finding stays shown and counted — with the finding and both reviewers' reasons kept on your account for the retention period above. Public verification pages — a published receipt, report or badge page stays up until you unpublish it or close your account. You can unpublish from the scan it belongs to in your dashboard; it takes effect immediately, so /receipt/… and /report/… return not found from that moment, as does our badge verification API. The badge image at /badge/… still returns an image, so an embed already on your site does not break, but it no longer states a verdict: it renders grey, marked expired. A badge expiring is not the same as unpublishing: an expired badge page still resolves and still shows the repository, the scan date and the counts, marked expired. Closing your account unpublishes every page you have published. Unpublishing removes the page from ShipSafe; it cannot reach a copy, screenshot or third-party cache someone already made, although a page that no longer resolves drops out of search results over time. Repository file manifest — written on each repository scan: a list of the file paths in the repository and a SHA-256 hash of each file's contents, used so the next scan can tell which files changed. It contains no code. Retained on the same basis as the scan it belongs to: while your account is active, then deleted on account closure. Scan-assistant learnings — when you mark a finding resolved, a false positive, or won't-fix, we keep that verdict together with what it refers to (the rule, the file and line, and the plain-English description of the issue), any reason you typed, and a numeric embedding of that text — a list of numbers that lets us match it to similar findings later. The scan assistant reads these back so it stays consistent with how you have triaged similar findings before. The record is yours alone: retrieval is filtered to your account, your learnings are never pooled with another customer's, and they are not used to train a model. Secrets are redacted before the text is stored and before it is sent for embedding. Retained while your account is active, then deleted when you delete your account. - **Fix runs** — when you send fixes to GitHub from a scan, we keep a record of that run: the repository URL, the name of the branch we created, the paths of the files we changed, the receipt lines (what was fixed and re-checked, what is still there, what could not be re-checked, what was not attempted, and which dependency updates to run), the automated reviewer's reasoning about a change it refused, and, for a finding the fix left still there, one line of that file as the re-check saw it — at most 160 characters, with any detected secret value redacted before it is stored — together with the reviewer's reason. If you approved the run in ShipSafe, we also keep when you approved it and the commit that approval produced on your default branch. Where the automated reviewer decides a finding is likely not a real vulnerability, its verdict and its reason, secret-redacted, are also stored on that finding. Your next fix run on the same scan or repository reads the record back so it does not repeat what the previous run learned. The record is yours alone: it is never pooled with another customer's and never used to train a model. Retained while your account is active, deleted on account closure, and included in your data export. - **Live-URL scan content** — the raw page and bundle content fetched during a live-URL scan is processed transiently and is not persisted after the scan completes; only the submitted URL and the resulting findings are retained, on the same basis as scan reports. - **Scan authorization log** (account, target host, timestamp, and accepted terms version): retained for up to 90 days as a security and abuse-dispute record, then automatically purged by a daily job. - **False-positive reports** — when you tell us a finding was wrong, we keep that report to fix the rule that misfired. It holds the rule that fired, the file path and line, the reason you gave, and a short redacted excerpt of the code that was flagged. We do not keep that excerpt for long: it is deleted as soon as we have reviewed the report, and in any case swept by a daily job once the report is 90 days old, whether anyone has reviewed it or not. What is left after that is the rule, the file path and line, and your reason — not your code. If you delete your account we do not delete these reports; we strip them instead. Your account, the repository, the scan and the finding they came from are all severed. That severing is one-way and cannot be undone, so a stripped report can no longer be traced to you or to your repository, and we keep what remains of it indefinitely as evidence about the rule. - **Usage events** — retained for 12 months, then automatically deleted by a daily job. Where your plan's AI-scan allowance is a lifetime total rather than a monthly one, we also keep a running count of the AI scans you have used on your account record. That count is a number, not a history — it records how many scans you have used, not when or on what — and we keep it for as long as your account exists so your remaining allowance is still correct after the underlying events expire. It is deleted with the rest of your account data. - **CLI tokens** — automatically purged when expired (daily cleanup). - **Contact form submissions** — the name, email address, message and hashed IP from a contact-form message are retained for one month, then automatically deleted by a daily job. If you have a ShipSafe account and you delete it, any submission sent from that account's email address is deleted at the same time, without waiting out the month. Messages you sent us from a different address are not something we can match to your account, so those fall to the one-month deletion instead — tell us the address and we will remove them sooner. - **Error monitoring data (Sentry)** — 30 days (per Sentry's retention policy). - **Audit records** — we keep a permanent log of security-relevant events on an account: plan changes, CLI tokens being issued or revoked, and account deletion itself. Each entry holds the action, the time, and an identifier for whoever performed it. We keep these on the basis of our legitimate interest in preventing fraud and in being able to settle a later dispute about what happened on an account, and there is no fixed deletion date. When an account is deleted we do not delete its audit records — we replace the identifier in them with a one-way hash, so the trail survives but no longer names the account it came from and cannot be linked back to you. - **GitHub App installation record** — kept for as long as the App is installed. It is deleted as soon as the installation is removed from GitHub. If you delete your ShipSafe account, an installation on your own GitHub account is deleted with it; an installation on an organization is shared with that organization's other members, so we remove the link between it and you and leave the installation itself working until someone uninstalls it. ## 5\. Third-Party Services We use the following third-party services to operate ShipSafe. Each has its own privacy policy governing how they handle data: | Service | Purpose | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Clerk | Authentication and user management (GitHub OAuth) | | Convex | Database — stores scan reports, account data, and application state | | Polar | Checkout, subscription management, and payment processing | | Resend | Transactional email delivery | | Vercel | Hosting and content delivery | | GitHub API | Repository access for code scanning | | OSV.dev (Google) | Known-vulnerability lookup for the dependencies listed in your lockfiles | | Upstash | Rate limiting and abuse prevention | | Anthropic | AI-powered code analysis, the scan assistant, and generated fix prompts and pull requests — code snippets, finding details, and the questions you type are sent for analysis | | Voyage AI | Text embeddings for the per-user RAG scan-assistant learning loop | | Vercel Analytics | Web performance analytics (cookie-less) | | Vercel Speed Insights | Web performance analytics (cookie-less) | | Google Analytics | Web and traffic analytics — loaded only with your analytics consent | | Google Ads | Ad-conversion measurement for advertising campaigns — loaded only with your analytics consent | | Meta Pixel | Ad-conversion measurement for advertising campaigns — loaded only with your analytics consent | Anthropic powers every AI feature in ShipSafe: AI analysis of repository code on paid tiers (from the web app, the CLI, and the MCP server), the scan assistant, and generated fix prompts and fix pull requests. The live-URL scan's own detection is pattern- and probe-based and calls no AI provider. But the findings it produces are derived from your deployed site, so if you then open the scan assistant or generate a fix prompt for a live-URL scan, we send those findings to Anthropic as context — the scanned host, the client-bundle file paths, the plain-English description of each issue, and the questions you type. Whatever we send is used solely to produce your report, your answer, or your fix. For a fix, we send the whole of each file a fix is written for, and the change itself to the automated reviewer. We send it over the paid Anthropic API under Anthropic's Commercial Terms, under which Anthropic does not train its models on the inputs or outputs of API calls. It is transmitted for the duration of the request only and is not retained by ShipSafe after the scan completes. Transfers to Anthropic (United States) are covered by the transfer safeguards described in Section 10 (SCCs / UK Addendum and, where applicable, Data Privacy Framework participation). See [Anthropic's usage policy](https://www.anthropic.com/policies) for details. ### Sub-Processors The table below is our sub-processor list, and it is the single place we publish changes to it. The providers listed are the ones we use as of the “Last updated” date at the top of this policy. Some of them were already handling data before we began publishing this list in this form — listing them here is us disclosing an existing provider, not appointing a new one, and we are not claiming they were announced in advance. From that date onward, when we add or replace a sub-processor we update this table and the “Last updated” date at least 30 days before the new sub-processor starts handling your data — sooner only if we have to replace one urgently for security or continuity reasons. Check this page, or email support@ship-safe.co and we will email you whenever this table changes. Business customers with a data processing agreement can also object to a change; see Section 4 of the DPA below. | Provider | Purpose | Data Processed | Location | | --------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | | Clerk | Authentication | Email, name, profile | United States | | Convex | Database | Account data, scan results | United States | | Polar | Billing & subscriptions | Payment info, billing, subscription data | United States | | Resend | Transactional email | Email addresses, notification content | United States | | Vercel | Hosting, content delivery, and cookie-less page-performance analytics | Application data, request and access logs, IP addresses, and cookie-less page-performance events (Vercel Analytics and Speed Insights) | United States | | Anthropic | AI code analysis, scan assistant, fix generation and review | Code snippets, finding details, and the assistant messages you type — including findings derived from a scanned live URL — and, for a fix, the whole of each file being fixed and the change itself for review. Not used to train Anthropic's models, under its Commercial Terms. ShipSafe does not retain it after the scan or run completes; any retention by Anthropic is governed by Anthropic's own retention policy. ShipSafe itself retains the redacted excerpt stored with each finding and the fix-run record — see Section 4. | United States | | Voyage AI | AI text embeddings | Chat message text and finding/triage text (secrets redacted; not retained by Voyage per their API terms) | United States | | GitHub | Repository access | Repository contents and, if you install the ShipSafe GitHub App, pull-request contents | United States | | Sentry | Error monitoring | Error stack traces and performance data (no IP, no session replays) | United States | | OSV.dev (Google) | Dependency vulnerability lookup | Package names, versions and ecosystems read from your lockfiles — no source code, no account identifier, no repository name | United States | | Upstash | Rate limiting and abuse prevention | A keyed hash of your IP address or API token, plus request counters and timestamps — we do not send Upstash your raw IP address or the contents of your requests | United States | | ImprovMX Incorporated | Inbound email forwarding for support@ship-safe.co | Sender address and message content of email you send us, including support requests and privacy rights requests | United States | | Google Analytics | Analytics (consent-based) | Page views, events, approximate location, online identifiers | United States | | Google Ads | Ad-conversion measurement (consent-based) | Conversion events, campaign attribution identifiers | United States | | Meta Pixel | Ad-conversion measurement (consent-based) | Conversion events, online identifiers | United States | ### Session Replay ShipSafe does **not** record session replays. Our error monitoring (Sentry) is configured to capture error stack traces and basic performance data only; it does not attach your IP address, cookies, or request headers to error events, and it never reconstructs or records your on-screen session. Error data is used solely for debugging, is scrubbed of secret-shaped values before it is sent, and is not used for analytics, marketing, or user profiling. ## 6\. Data Security We take reasonable measures to protect your data, including: - Encryption of data in transit (TLS) and at rest. - Access controls limiting who can view or modify production data. - Regular review of third-party service configurations and permissions. - Minimal data collection — we only collect what is necessary to provide the service. No method of transmission or storage is 100% secure. While we strive to protect your data, we cannot guarantee absolute security. ## 7\. Your Rights You have the right to: - **Access** your personal data and scan history. - **Delete** your account and associated data. - **Export** your scan reports, fix-run records and account information. - **Opt out** of non-essential communications. To exercise any of these rights, contact us at [support@ship-safe.co](mailto:support@ship-safe.co). ## 8\. Cookies ShipSafe uses essential cookies for authentication and session management (provided by Clerk). With your consent, we also use analytics and advertising-measurement cookies — Google Analytics, and, when we run advertising campaigns, Google Ads and the Meta (Facebook) Pixel — to understand traffic and measure ad performance. These load only after you choose "Accept all"; choosing "Essential only" declines them. Essential cookies are required for the service to function and cannot be disabled. | Cookie Name | Type | Duration | Purpose | Required | | ------------------------ | ----------- | ------------- | ---------------------------------------------------------------------------------- | -------- | | cookie-consent | Essential | 1 year | Stores your cookie consent preferences. | Yes | | \_\_clerk\_db\_jwt | Essential | Session | Clerk authentication session token. | Yes | | \_\_client\_uat | Essential | Session | Clerk client authentication token. | Yes | | \_ga, \_gid | Analytics | Up to 2 years | Google Analytics — traffic measurement. Only set with your consent. | No | | \_fbp, \_fbc, Google Ads | Advertising | Up to 1 year | Meta Pixel and Google Ads — ad-conversion measurement. Only set with your consent. | No | When you first visit ShipSafe, a cookie banner lets you accept or reject non-essential cookies. Rejecting is as easy as accepting: the "Essential only" choice is presented with equal prominence to "Accept all," and non-essential cookies (Sentry error monitoring, Google Analytics, and advertising measurement) are **not set unless you opt in**. You can change your choice at any time using the cookie banner; you do not need to contact us. For basic performance monitoring we also use Vercel Analytics and Vercel Speed Insights, which are cookie-less and do not track individual users across sites. **Global Privacy Control (GPC):** We honor the Global Privacy Control signal. If your browser sends a GPC signal, we treat it as a valid request to opt out of any sale or sharing of personal information (we do not sell or share it for cross-context behavioural advertising in any case) and we do not enable non-essential cookies for your session. ## 9\. Children's Privacy ShipSafe is not intended for use by anyone under the age of 16\. We do not knowingly collect personal information from children under 16\. If we become aware that we have collected data from a child under 16, we will take steps to delete it promptly. ## 10\. International Users & GDPR If you are located in the European Economic Area (EEA), United Kingdom, or Switzerland, the following additional provisions apply to you. ### Legal Bases for Processing (GDPR Article 6) We process your personal data under the following Article 6(1) legal bases: - **Art. 6(1)(b) — Contract performance** — processing necessary to provide the ShipSafe service you have signed up for, including running security scans, generating reports, managing your account, and processing payments. This basis also covers publishing the public verification pages described in Section 3\. Independent, checkable proof is the thing being provided — a receipt or a badge only works if someone else can open it without going through us — so publishing that redacted summary is performance of our contract with you, not an optional extra use of your data. We publish only the fields listed in Section 3, only for a scan we ran ourselves on a target you control, and we stop publishing when you unpublish the page or close your account. - **Art. 6(1)(f) — Legitimate interest** — improving the service, ensuring security, preventing abuse, and sending transactional communications. Our legitimate interests do not override your fundamental rights and freedoms. - **Art. 6(1)(a) — Consent** — error monitoring via Sentry, and analytics and advertising measurement via Google Analytics, Google Ads, and the Meta Pixel, all of which you can withdraw at any time through cookie settings without affecting the lawfulness of prior processing. - **Art. 6(1)(c) — Legal obligation** — processing required to comply with applicable laws, such as tax and accounting requirements for paid subscriptions. ### International Data Transfers Your data is processed in the United States. For users in the EEA and Switzerland, transfers rely on the European Commission's Standard Contractual Clauses (SCCs, Module Two) executed with our sub-processors. For users in the United Kingdom, transfers rely on the UK International Data Transfer Addendum to the EU SCCs (the UK Addendum) issued by the Information Commissioner's Office, together with the safeguards below. Where a sub-processor participates in the EU-U.S. Data Privacy Framework (and its UK Extension and Swiss-U.S. counterpart), we also rely on that certification. As supplementary measures we apply encryption in transit (TLS 1.2+), encryption at rest, least-privilege access, and data minimization (the working copy of source code is processed in memory and not permanently stored; what is retained is a short, secret-redacted excerpt with each finding and, after a fix run, one redacted line for each finding the fix left still there — see Section 4). **Transfer Impact Assessment:** We maintain an internal assessment of the risks of U.S. transfers (including U.S. government access laws) and the supplementary measures applied per sub-processor. EEA/UK users may request a summary at [support@ship-safe.co](mailto:support@ship-safe.co). ### Your Data Subject Rights Under the GDPR, you have the following rights regarding your personal data: - **Access** — obtain confirmation and a copy of the personal data we hold about you. - **Rectification** — request correction of inaccurate or incomplete data. - **Erasure** — request deletion of your personal data ("right to be forgotten"). - **Restriction** — request that we limit the processing of your data in certain circumstances. - **Portability** — receive your data in a structured, machine-readable format and transmit it to another controller. - **Objection** — object to processing based on legitimate interests or for direct marketing purposes. - **Withdraw consent** — where processing is based on consent, you may withdraw it at any time without affecting the lawfulness of prior processing. To exercise any of these rights, contact us at [support@ship-safe.co](mailto:support@ship-safe.co). We will respond within 30 days. ### Right to Lodge a Complaint You have the right to lodge a complaint with your local data protection supervisory authority if you believe your data is being processed in violation of applicable data protection law. In the United Kingdom this is the Information Commissioner's Office (ICO, [ico.org.uk](https://ico.org.uk)); in the EEA it is the supervisory authority of your member state; in Switzerland it is the Federal Data Protection and Information Commissioner (FDPIC). ### EU / UK Representative ShipSafe is operated from Israel and is not established in the EU or UK. We have not appointed an Article 27 representative in the EU or the UK. Whether Article 3(2) engages that duty is a judgement rather than a settled fact: we have no establishment, marketing, pricing or language directed at either region, but we do serve subscribers who live there. Our current assessment is that the duty is not engaged. We will appoint a representative and publish the name and address here if that assessment changes, if we gain further users in the region, or if a supervisory authority tells us otherwise. Nothing in this paragraph is a claim that the GDPR does not apply to us. Until then you can reach us directly for any data-protection matter, and we answer to the same deadlines a representative would be held to, at [support@ship-safe.co](mailto:support@ship-safe.co). ### Automated Decision-Making ShipSafe scanning is automated: rule-based analysis, AI analysis of the source code you submit, or both. What it produces are findings about code, not judgements about people. No decision producing legal effects concerning you, or similarly significantly affecting you, is made about you by solely automated means, so Article 22 of the GDPR is not engaged. Some of that automated output does have operational effect, and you should know where. If you install our GitHub App, a scan of a pull request writes a check run to that pull request with a pass or fail conclusion, and it fails when it finds a new critical or high issue on the lines the pull request changed; where your repository requires that check to pass, a failure can hold the merge until you act on it or override it. If you turn on monitoring, scans run on the cadence you set without you starting them, and can send you email. If you publish a verification badge or a public report, a later scan that finds a critical or high issue changes what that public page shows, and a badge that is not re-verified within its freshness window stops showing as verified. Each of these is an effect on your code and on pages you chose to publish, and each is something you switch on and can switch off. Automated findings can be wrong in both directions, so treat them as input to your own judgement rather than as a verdict. If you want a human to review any result, contact us at [support@ship-safe.co](mailto:support@ship-safe.co). **AI transparency (EU AI Act):** ShipSafe is a _deployer_ of a general-purpose AI model provided by Anthropic (Claude); Anthropic is the model _provider_. Our scanning is a limited-risk AI use that produces clearly-labelled, AI-generated, informational findings which you should independently verify. We do not use it for high-risk decision-making about individuals. ## 11\. California Privacy Rights (CCPA/CPRA) If you are a California resident, you have additional rights under the California Consumer Privacy Act (CCPA) as amended by the California Privacy Rights Act (CPRA). ### Categories of Personal Information Collected - **Identifiers** — name, email address, GitHub username. - **Commercial information** — subscription plan, billing history. - **Internet or electronic network activity** — usage data, pages visited, scan history. - **Professional or employment-related information** — GitHub profile data, repository information. ### Your California Privacy Rights - **Right to know** — request disclosure of the personal information we collect, use, and share about you. - **Right to delete** — request deletion of your personal information. - **Right to correct** — request correction of inaccurate personal information. - **Right to opt-out** — opt out of the sale or sharing of your personal information. **We do not sell or share personal information** for cross-context behavioral advertising as defined by the CCPA/CPRA, and we do not process sensitive personal information for purposes that would require an opt-out. ### Your Privacy Choices / Do Not Sell or Share My Personal Information Because we do not sell or share your personal information, there is nothing to opt out of. You may still submit a request to confirm this, or to exercise any of your rights above (know, delete, correct, limit sensitive information), by emailing [support@ship-safe.co](mailto:support@ship-safe.co?subject=Privacy%20Request) with the subject "Privacy Request," or via our [contact form](https://ship-safe.co/contact). We verify your identity (typically via your account email) and respond within the time required by applicable law. We also honor the Global Privacy Control (GPC) browser signal as a valid opt-out request, and you may use an authorized agent to submit a request on your behalf. **Non-discrimination:** We will not discriminate against you for exercising any of your CCPA/CPRA rights. To submit a request, contact us at [support@ship-safe.co](mailto:support@ship-safe.co). ## 12\. Additional US State Privacy Rights In addition to California (CCPA/CPRA), residents of the following US states have privacy rights under their respective state laws: - **Virginia** — Virginia Consumer Data Protection Act (VCDPA) - **Colorado** — Colorado Privacy Act (CPA) - **Connecticut** — Connecticut Data Privacy Act (CTDPA) - **Utah** — Utah Consumer Privacy Act (UCPA) - **Texas** — Texas Data Privacy and Security Act (TDPSA) - **Oregon** — Oregon Consumer Privacy Act (OCPA) - **Montana** — Montana Consumer Data Privacy Act (MCDPA) Residents of these states generally have similar rights, including: - **Access** — confirm whether we process your personal data and obtain a copy. - **Delete** — request deletion of your personal data. - **Correct** — request correction of inaccurate personal data. - **Opt-out** — opt out of the sale of personal data, targeted advertising, or profiling in furtherance of decisions that produce legal or similarly significant effects. - **Appeal** — appeal a denial of a privacy rights request. **We do not sell personal data** or use it for targeted advertising or profiling as defined under these state privacy laws. To exercise any of these rights, contact us at [support@ship-safe.co](mailto:support@ship-safe.co). If you are not satisfied with our response, you may appeal by contacting us again with "Privacy Appeal" in the subject line. We will respond to appeals within the timeframe required by your state's law. ## 13\. Data Breach Notification In the event of a data breach affecting your personal information, we will notify affected users and relevant authorities in accordance with applicable law. For users in the EEA, UK, or Switzerland, we will notify the relevant supervisory authority within 72 hours of becoming aware of a qualifying breach, as required by GDPR Article 33. Breach notifications will include: - The nature of the personal data breach. - The likely consequences of the breach. - The measures taken or proposed to address and mitigate the breach. ## 14\. Israeli Privacy Protection Law ShipSafe is operated by a founder based in Israel. Accordingly, the Israeli Protection of Privacy Law, 5741-1981 — as substantially amended by Amendment No. 13, which entered into force on 14 August 2025 — together with the Privacy Protection Regulations (Data Security), 5777-2017, applies to our processing of personal data. Amendment 13 modernized Israel's privacy framework (broader definitions of "personal information" and "information of especially sensitive nature," enhanced transparency and data-subject rights) and granted the Privacy Protection Authority (PPA) expanded enforcement powers, including significant administrative fines. ### Your Rights Under Israeli Law If Israeli privacy law applies to you, you have the following rights regarding your personal data: **Giving us your data is your choice.** No law requires you to give ShipSafe any personal data. You give us an email address to hold an account, and a repository or an application URL when you ask for a scan. If you would rather not, you simply cannot have an account or a scan — there is no other consequence, we will not charge you and we will not keep a record of the refusal. Section 11 of the Protection of Privacy Law requires us to tell you this plainly, along with why we are asking, who we pass the data to, and the two rights set out below. - **Right of access (section 13)** — you may request to review personal data held about you in our databases. - **Right to correction (section 14)** — you may request that we correct or delete inaccurate data. - **Right to object** — you may object to the use of your personal data for direct marketing purposes and request its removal from marketing databases. - **Right to deletion** — you may request that we delete your personal data, subject to applicable legal retention requirements. ### Data Security We maintain technical and organizational security measures in compliance with the Privacy Protection Regulations (Data Security), 5777-2017, including access controls, encryption, and incident response procedures. Based on the nature of personal data we process (primarily account identifiers and scan metadata), our database is classified at the "Basic" security level under the 2017 Regulations. We apply security measures that meet or exceed the requirements for this classification level. ### Cross-Border Data Transfers Personal data may be transferred and processed outside of Israel, primarily in the United States. The Privacy Protection (Transfer of Data to Databases Abroad) Regulations, 5761-2001 govern those transfers. Those Regulations ask for two things together, not either one alone: a lawful route for the transfer, and a written undertaking from the recipient covering both how it protects the data and whether it may pass the data on further. We rely on your consent as the route, and on our contract with each sub-processor for the undertaking, alongside the safeguards described in Section 10 (SCCs and supplementary measures). Israel has been recognized by the European Commission as providing an adequate level of data protection (Commission Decision 2011/61/EU). That decision covers transfers made _to_ Israel from the European Economic Area, and it means such transfers need no additional safeguard such as Standard Contractual Clauses. It does not work in the other direction: when we send your data onward from Israel to a provider outside the EEA, that transfer needs its own basis, which we describe below and in our sub-processor table. We say this plainly because an adequacy decision is often read as covering both directions, and this one does not. ### Privacy Protection Officer Amendment 13 requires certain controllers (such as public bodies, data brokers, and organizations whose core activity involves large-scale processing of sensitive data or systematic monitoring) to appoint a Privacy Protection Officer. We have assessed this requirement; as a small operator processing limited data we fall below those thresholds, and we have designated a privacy contact reachable at [support@ship-safe.co](mailto:support@ship-safe.co) for all privacy matters and PPA correspondence. ### Security-Incident Notification In the event of a serious security incident affecting personal data, we will notify the Privacy Protection Authority and affected individuals as required by the Privacy Protection Regulations (Data Security), 5777-2017 and Amendment 13. ### Database Registration Amendment 13 abolished the general obligation to register databases with the Privacy Protection Authority (and the annual-reporting obligation for holders of multiple registrable databases). General database registration is therefore no longer required for our processing; mandatory registration now applies only in limited cases (for example, data brokers), which do not apply to ShipSafe. ### Business Registration ShipSafe is operated by Tomer Goldstein, registered as an Osek Patur (exempt dealer) with the Israel Tax Authority, located at Reut 12B, Hod HaSharon 4529614, Israel. To exercise any of these rights, contact us at [support@ship-safe.co](mailto:support@ship-safe.co). We will respond within 30 days. ## 15\. Asia-Pacific Privacy Rights If you are located in the Asia-Pacific region, the following regional provisions apply in addition to the rest of this policy. Across these regions, your personal data and the code you submit for scanning are transferred to and processed in the United States by the sub-processors listed in Section 5 (including Anthropic for AI analysis). By creating an account and running scans, you provide your consent to this cross-border processing; you may withdraw it at any time by closing your account, which may end your ability to use the service. ### Data Protection & Grievance Officer We are not required to appoint a Data Protection Officer under Article 37 of the GDPR, and we have not appointed one — naming a DPO we do not need would import duties we could not meet as a one-person company. Privacy questions and complaints, including any grievance under India’s DPDP Act, go to our privacy contact at [support@ship-safe.co](mailto:support@ship-safe.co). We aim to acknowledge requests promptly and resolve grievances within 45 days (or sooner where the law requires). ### Singapore (PDPA) We collect, use, and disclose personal data with notification and, where required, consent, for the purposes described in this policy. For users in Singapore, your personal data is transferred outside Singapore to the United States; by agreeing to this policy you consent to that transfer, and we apply contractual and technical safeguards (Section 5 and Section 10) to provide a comparable standard of protection. Our designated DPO is reachable above. ### India (DPDP Act 2023) We process digital personal data on the basis of your consent, which you may withdraw at any time, and we provide notice of the purposes of processing. You may exercise your rights (access, correction, erasure, grievance redressal, and nomination) by contacting our Grievance Officer above. ShipSafe is not intended for users under 18; we do not knowingly process a child's data without verifiable parental consent. ### Japan (APPI) We notify you of the purpose of use of your personal information and obtain your consent to provide it to the third-party sub-processors in Section 5, including the cross-border transfer to the United States. The United States is not subject to an adequacy determination by Japan; we therefore rely on your consent together with contractual safeguards with each sub-processor. ### Australia (Privacy Act / APPs) Consistent with Australian Privacy Principle 8, we disclose that your personal information may be disclosed to overseas recipients (our U.S. sub-processors in Section 5). We take reasonable steps to ensure those recipients handle your information consistently with the APPs through contractual safeguards. You may complain to us first and, if unsatisfied, to the Office of the Australian Information Commissioner (OAIC). ### Mainland China (PIPL) & South Korea (PIPA) — not available ShipSafe is not offered to users located in mainland China or South Korea, and access from those regions is blocked. Full compliance with the PIPL (China) and PIPA (South Korea) — including locally appointed representatives, native-language consent flows, and, for China, an approved cross-border transfer mechanism — is not currently in place, so we have chosen not to operate there rather than offer a partial service. We may revisit this in the future; until then, users in these regions should not submit personal information or source code to ShipSafe. ## 16\. Record of Processing Activities We maintain a Record of Processing Activities (ROPA) as required by GDPR Article 30, documenting all categories of processing activities carried out under our responsibility. This record is available upon request to supervisory authorities. For questions, contact [support@ship-safe.co](mailto:support@ship-safe.co). For a detailed assessment of risks related to our AI-powered scanning, see our [Data Protection Impact Assessment (DPIA)](#dpia) below. ## 17\. Changes to This Policy We may update this Privacy Policy from time to time. When we make material changes, we will notify you by updating the "Last updated" date at the top of this page and, where appropriate, through in-app notifications or email. --- Appendix A ## Data Processing Agreement Last updated: August 24, 2026 ### 1\. Definitions This Data Processing Agreement ("DPA") forms part of the Terms of Service between ShipSafe ("Processor," "we," "us") operating at ship-safe.co and the customer ("Controller," "you") who uses the ShipSafe service. - **"Personal Data"** means any information relating to an identified or identifiable natural person, as defined under GDPR Article 4(1). - **"Processing"** means any operation performed on Personal Data, including collection, recording, storage, retrieval, use, disclosure, erasure, or destruction. - **"Controller"** means the entity that determines the purposes and means of Processing Personal Data. - **"Processor"** means the entity that processes Personal Data on behalf of the Controller. - **"Sub-processor"** means any third party engaged by the Processor to process Personal Data on behalf of the Controller. - **"Data Subject"** means the identified or identifiable natural person to whom the Personal Data relates. - **"GDPR"** means Regulation (EU) 2016/679 of the European Parliament and of the Council (General Data Protection Regulation). - **"Standard Contractual Clauses" (SCCs)** means the contractual clauses approved by the European Commission for the transfer of Personal Data to third countries. ### 2\. Scope and Purpose of Processing ShipSafe is a SaaS security scanner designed for applications built with AI-assisted coding tools. This DPA applies to all Personal Data that the Processor processes on behalf of the Controller in connection with providing the ShipSafe service. #### Subject Matter The Processor provides security scanning and analysis of source code repositories submitted by the Controller, generating security reports and vulnerability assessments. #### Nature and Purpose Personal Data is processed for the purpose of providing the ShipSafe service, including account management, authentication, security scanning, report generation, payment processing, and transactional communications. #### Types of Personal Data - Account identifiers (name, email address, GitHub username) - Authentication data (OAuth tokens, session information) - Repository metadata (repository names, scan timestamps, scan results) - Payment and billing information (processed by third-party payment providers) - Usage data (pages visited, feature usage, device information) #### Categories of Data Subjects - Customers and end users of the ShipSafe service - Developers whose repositories are submitted for scanning #### Duration Processing continues for the duration of the Controller's use of the ShipSafe service, plus any retention period required by law or described in Section 9 of this DPA. ### 3\. Data Processor Obligations The Processor shall: - Process Personal Data only on documented instructions from the Controller, unless required to do so by applicable law. - Ensure that persons authorized to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. - Implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk of processing, as described in Section 7 of this DPA. - Assist the Controller in fulfilling its obligation to respond to Data Subject requests, as described in Section 6 of this DPA. - Assist the Controller in ensuring compliance with its obligations regarding security of processing, data breach notification, data protection impact assessments, and prior consultation with supervisory authorities. - At the choice of the Controller, delete or return all Personal Data upon termination of the service, unless retention is required by applicable law. - Make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in GDPR Article 28, and allow for and contribute to audits conducted by the Controller or an auditor mandated by the Controller. - Immediately inform the Controller if, in the Processor's opinion, an instruction infringes the GDPR or other applicable data protection provisions. ### 4\. Sub-processors The Controller gives the Processor general written authorization to engage sub-processors. Notice of changes is given by publication, not individually: the table below is the Processor's sub-processor list, and it carries the date it was last changed. The Processor will add a new or replacement sub-processor to that table, with the date, at least 30 days before that sub-processor begins processing Customer Personal Data. This advance-notice obligation applies to sub-processors engaged after the date of this DPA; those already listed on that date are disclosed as existing sub-processors, to which the Controller’s general authorization above applies, and no representation is made that they were notified in advance. The Controller may object in writing to support@ship-safe.co within 30 days of the date shown against the change. If the Controller objects on reasonable data-protection grounds and the Processor cannot offer a workaround, the Controller may terminate the affected part of the Service and receive a pro-rata refund of any prepaid, unused fees. Where an existing sub-processor fails or must be replaced urgently for security or continuity reasons, the Processor may make the change immediately and update the table as soon as practicable; the Controller's right to object and terminate then runs from that update. The Controller may also ask, at support@ship-safe.co, to be emailed whenever this table changes. The Processor has engaged the following sub-processors. This register was last changed on **August 26, 2026**. Every sub-processor listed below was already engaged on that date and is disclosed as an existing sub-processor under Section 4; anything added later is shown with the date it was added, and the Controller’s 30-day right to object runs from that date. | Sub-processor | Purpose | Data Processed | Location | Added | | --------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | --------------- | | Convex | Database | Account data, scan reports, application state | United States | August 26, 2026 | | Clerk | Authentication | Email, name, GitHub profile, session tokens | United States | August 26, 2026 | | OSV.dev (Google) | Known-vulnerability lookup for dependencies | Package names, versions and ecosystems parsed from lockfiles in the scanned repository; no source code and no Data Subject identifiers | United States | August 26, 2026 | | Upstash | Durable rate limiting and abuse prevention (required in production) | Keyed hashes derived from IP addresses or API tokens, with request counters and timestamps; no raw IP addresses and no request contents | United States | August 26, 2026 | | ImprovMX Incorporated | Inbound email forwarding for support@ship-safe.co | Sender address and message content of email sent to the Processor, including support correspondence and Data Subject rights requests | United States | August 26, 2026 | | Anthropic | AI-powered code analysis, fix generation and review | Code snippets, finding metadata, and assistant messages entered by Data Subjects, including findings derived from a scanned live URL, and, for a fix, the whole of each file being fixed and the change itself for review. Not used for model training under Anthropic's Commercial Terms. The Processor does not retain it after the scan or run completes; any retention by the sub-processor is governed by its own retention policy. The Processor retains the redacted excerpt stored with each finding and the fix-run record, as described in Section 7 of this DPA. | United States | August 26, 2026 | | Voyage AI | AI text embeddings | Chat message text and finding/triage text (secrets redacted; not retained by Voyage per their API terms) | United States | August 26, 2026 | | Resend | Transactional email | Email addresses, notification content | United States | August 26, 2026 | | Polar | Payments & subscription management | Payment info, billing data, subscription state | United States | August 26, 2026 | | GitHub | Repository access via GitHub OAuth and the ShipSafe GitHub App | Repository contents, pull-request contents, OAuth tokens and GitHub App installation tokens. The GitHub App acts only on an installation linked to a ShipSafe account; an installation with no linked account is refused and no token is issued for it | United States | August 26, 2026 | | Sentry | Error monitoring, performance tracking | Error stack traces and basic performance data — no IP addresses, no cookies or request headers, and no session replays | United States | August 26, 2026 | | Vercel | Hosting, edge compute, and cookie-less page-performance analytics (Vercel Analytics and Speed Insights) | Request logs, IP addresses, and cookie-less page-performance events | United States | August 26, 2026 | The Processor shall impose the same data protection obligations as set out in this DPA on each sub-processor by way of a contract, ensuring that each sub-processor provides sufficient guarantees to implement appropriate technical and organizational measures. This list covers every sub-processor that handles Customer Personal Data under this DPA, and it names the same providers as the sub-processor table in Section 5 of the Privacy Policy. The consent-gated analytics and advertising tags also named in Section 5 — Google Analytics, Google Ads and the Meta Pixel — are deliberately not listed here: they run in a website visitor's browser, only after that visitor accepts analytics cookies, and they receive no Customer Personal Data processed under this DPA. The Processor remains fully liable to the Controller for the performance of each sub-processor's obligations. ### 5\. Controller Obligations The Controller shall: - Ensure that it has a lawful basis for the processing of Personal Data and that all necessary consents have been obtained from Data Subjects where required. - Provide documented processing instructions to the Processor. - Ensure that repositories submitted for scanning do not contain Personal Data beyond what is necessary, or that appropriate safeguards are in place where they do. - Comply with its obligations under applicable data protection laws, including GDPR. ### 6\. Data Subject Rights The Processor shall assist the Controller in responding to requests from Data Subjects exercising their rights under GDPR, including: - **Right of access** — obtaining confirmation and a copy of Personal Data being processed. - **Right to rectification** — correcting inaccurate or incomplete Personal Data. - **Right to erasure** — deleting Personal Data ("right to be forgotten"). - **Right to restriction of processing** — limiting the processing of Personal Data in certain circumstances. - **Right to data portability** — receiving Personal Data in a structured, commonly-used, machine-readable format. - **Right to object** — objecting to processing based on legitimate interests or for direct marketing. The Processor shall promptly notify the Controller if it receives a request directly from a Data Subject and shall not respond to the request without the Controller's prior written authorization, unless required by applicable law. Data Subject requests can be submitted to [support@ship-safe.co](mailto:support@ship-safe.co) and will be addressed within 30 days. ### 7\. Data Security Measures The Processor implements the following technical and organizational measures to protect Personal Data, in accordance with GDPR Article 32: #### Technical Measures - Encryption of data in transit using TLS 1.2 or higher. - Encryption of data at rest in all databases and storage systems. - The working copy of submitted source code is processed in memory, is never written to disk or to our database, and is discarded once the security report is generated. Two derivatives are persisted with the report: a short code excerpt stored with each finding — normally the flagged line plus five lines of context on each side, with any detected secret value redacted before it is stored — and, for repository scans, a manifest of file paths with a SHA-256 hash of each file's contents. A third is persisted only where the Controller sends fixes to GitHub: a record of that fix run holding the repository URL, the branch name, the changed file paths, the receipt lines, the automated reviewer's reasoning and, for a finding the fix left still there, one line of that file of at most 160 characters with any detected secret value redacted before it is stored. The Controller's next fix run reads that record back; it is retained while the account is active, deleted on account closure, and included in the data export. - Role-based access controls limiting access to production systems and Personal Data. - Regular security assessments and vulnerability scanning of our own infrastructure. - Automated monitoring and alerting for anomalous access patterns. #### Organizational Measures - Principle of least privilege for all personnel with access to Personal Data. - Confidentiality obligations for all personnel who process Personal Data. - Regular review of third-party service configurations and access permissions. - Data minimization — we collect and process only the Personal Data necessary to provide the service. - Documented incident response procedures for handling data breaches. ### 8\. Data Breach Notification The Processor shall notify the Controller without undue delay, and in any event **within 72 hours**, after becoming aware of a Personal Data breach, in accordance with GDPR Article 33. The notification shall include: - A description of the nature of the Personal Data breach, including the categories and approximate number of Data Subjects and records concerned. - The name and contact details of the Processor's point of contact for further information. - A description of the likely consequences of the breach. - A description of the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects. The Processor shall cooperate with the Controller and take reasonable steps to assist in the investigation, mitigation, and remediation of each Personal Data breach. ### 9\. International Data Transfers Personal Data is processed primarily in the **United States**. For Controllers and Data Subjects located in the European Economic Area (EEA), United Kingdom, or Switzerland, the Processor ensures that appropriate safeguards are in place for international transfers of Personal Data. #### Transfer Mechanisms - **Standard Contractual Clauses (SCCs)** — the Processor uses the European Commission's Standard Contractual Clauses (Module Two: Controller to Processor) for transfers of Personal Data to third countries that do not have an adequate level of data protection, as approved by Commission Implementing Decision (EU) 2021/914. - **Sub-processor agreements** — the Processor ensures that all sub-processors listed in Section 4 maintain equivalent data transfer safeguards, including SCCs where applicable. - **Supplementary measures** — the Processor implements additional technical and organizational measures (such as encryption and access controls) to supplement transfer mechanisms where necessary. The Processor shall promptly inform the Controller if it becomes aware of any changes in applicable law that may affect the validity of the transfer mechanisms in place. ### 10\. Duration and Termination This DPA shall remain in effect for the duration of the Controller's use of the ShipSafe service. Upon termination of the service: - The Processor shall, at the Controller's choice, delete or return all Personal Data processed on behalf of the Controller within **30 days** of receiving a written request, unless applicable law requires further retention. - The Processor shall delete existing copies of Personal Data unless applicable law requires storage of the Personal Data. - Upon request, the Processor shall provide written certification of deletion to the Controller. Obligations relating to confidentiality, data security, and cooperation with supervisory authorities shall survive the termination of this DPA. ### 11\. Liability Each party's liability under this DPA is subject to the limitations and exclusions of liability set out in the Terms of Service. Nothing in this DPA limits either party's liability for obligations that cannot be limited under applicable data protection law. ### 12\. Record of Processing Activities The Controller maintains a Record of Processing Activities in accordance with Art. 30 GDPR. The Processor maintains its own Record of Processing Activities documenting all categories of processing carried out on behalf of Controllers, available upon request to supervisory authorities. --- Appendix B ## Data Protection Impact Assessment GDPR Article 35 — Last updated: June 2026 ### 1\. Description of Processing #### What Data Is Processed ShipSafe's AI-powered scanning processes source code from GitHub repositories submitted by the user. The data sent to the AI model (Anthropic Claude) includes: - Source code files from the specified repository (read via the GitHub API) - File paths and directory structure metadata - Repository name and scan configuration parameters - For a fix run, the whole of each file a fix is written for, and the change itself for the automated reviewer Source code may incidentally contain personal data such as developer names in comments, email addresses in configuration files, or hardcoded credentials (which the scan aims to detect and flag). #### Purpose of Processing The purpose of AI scanning is to identify potential security vulnerabilities, misconfigurations, and risks in user-submitted source code. The AI model analyzes code patterns and produces a plain-English security report with findings and remediation recommendations. #### Technology Used ShipSafe uses Anthropic's Claude API for AI-powered code analysis. Code snippets are sent via encrypted API calls and processed in real-time. Anthropic does not use API inputs for model training (per their commercial API terms). Pull request reviews produced by the ShipSafe GitHub App are an exception to the above: they run on the ShipSafe rule engine alone, and no pull request code is sent to Anthropic. ### 2\. Necessity and Proportionality Assessment #### Necessity AI-powered scanning is necessary to provide the core value of ShipSafe: identifying complex security vulnerabilities that rule-based scanners cannot detect. Every scan runs against a target you chose. You start most scans yourself, by submitting a repository or an application URL. On a paid plan you can also give a standing instruction: the re-scan cadence you set in Settings, and a repository you connect so that a push or a pull request triggers a scan. Both routes process only targets you gave us, and both are necessary to deliver the plan you signed up for (Article 6(1)(b), as set out in Section 10). #### Proportionality - **Started or scheduled by you:** Scanning runs only against a repository or live application URL you submitted yourself. On a paid plan that includes monitoring, re-scanning is part of the plan: ShipSafe re-scans the repositories you most recently submitted, up to your plan's project limit, together with your most recent live-URL target. You choose the cadence in Settings; a cadence faster than your plan provides is applied at your plan's cadence. If you install the ShipSafe GitHub App on a repository, a pull request there triggers a review of the changed files. Scheduled re-scanning ends when the paid plan ends, and connection-triggered scanning ends when you uninstall the App. We do not browse or index your other repositories, and we never scan a repository you have not submitted or connected. - **Minimal data:** Only source code necessary for security analysis is processed. We do not analyze commit history, pull requests, issues, or other repository metadata beyond what is needed. - **No copy of your repository is kept:** The working copy of your source code is processed in memory and discarded once the scan report is generated. What is retained is the findings and their metadata — and each finding stores a short excerpt of the flagged code, normally that line plus about five lines of context on either side, with any detected secret value redacted before it is stored. - **Transient API processing:** Code sent to Anthropic's API is processed in real time. Under Anthropic's Commercial Terms it is not used to train models. ShipSafe does not retain it after the scan completes; any retention by Anthropic is governed by Anthropic's own data retention policy for the commercial API. ### 3\. Risks to Data Subjects | Risk | Likelihood | Severity | Description | | ------------------------------------------------ | ---------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Code exposure in transit | Low | High | Source code could be intercepted during transmission to the AI provider. | | Incidental personal data in code | Medium | Low | Code may contain developer names, emails, or other personal data in comments or configuration files. | | False positive findings | Medium | Low | AI may incorrectly flag secure code as vulnerable, potentially causing unnecessary remediation effort. | | False negative findings | Medium | Medium | AI may fail to detect actual vulnerabilities, leading to a false sense of security. | | Prompt injection via code | Low | Medium | Malicious code could attempt to manipulate the AI model's behavior through embedded instructions. | | Unauthorized repository scanning | Low | High | A user could submit a repository they do not have authorization to scan. | | Findings published where others can read them | Medium | Medium | The GitHub App writes its findings into the pull request as inline comments and a check run. Everyone who can see the pull request can read the file path, the line and the plain-English description of an unfixed vulnerability; on a public repository that is anyone. | | Fixes sent to a public repository | Medium | Medium | When the user sends fixes to GitHub, the changed code and the pull request are visible to everyone who can see the repository; on a public repository that is anyone. On a public repository the pull request description carries only the three counts and a link to the scan page; the full receipt — the findings the run did not fix, with their file paths, and the automated reviewer's reasoning about a change it refused — stays in the signed-in account (and in the completion email, when the user has not opted out). On a private repository the description carries that receipt too, with any detected secret value redacted before a line reaches it. The user chooses when to send fixes and to which repository, and can close the pull request. | | Scanning that outlives the attention of the user | Medium | Low | Once a repository is connected, scheduled, push-triggered and pull-request scans keep reading it without a fresh instruction, so code may continue to be processed after the user has stopped thinking about the connection. | ### 4\. Mitigation Measures #### Encryption and Transport Security - All API calls to Anthropic use TLS 1.2+ encryption in transit. - GitHub API access uses encrypted OAuth tokens. - The working copy of a scanned repository is never written to disk or to our database — it is held in memory only while the scan is running. #### What Is Kept After a Scan - The working copy of the repository is processed in memory and discarded when the scan completes. ShipSafe does not keep a copy of the repository. - Two derivatives of the code are persisted. Each finding stores the rule, severity, file path, line number, a plain-English description, and a short code excerpt around the flagged line — normally that line plus five lines of context on each side — with any detected secret value redacted before it is stored. Separately, each repository scan stores a manifest of file paths with a SHA-256 hash of each file's contents, so a later scan can tell which files changed; the manifest holds hashes, not code. - A third is persisted only when the user sends fixes to GitHub: the fix run's record — repository URL, branch name, changed file paths, receipt lines, the automated reviewer's reasoning and, for a finding the fix left still there, one line of that file of at most 160 characters, secret-redacted — which the user's next fix run reads back. If the user approved the run in ShipSafe, the record also keeps when they approved it and the commit that approval produced on their default branch. Retained while the account is active and deleted with it; see Section 4 of the policy. - Under Anthropic's Commercial Terms, inputs to the commercial API are not used for model training; retention is governed by Anthropic's own data retention policy. #### Prompt Injection Defense - The AI scanning prompt uses structured system instructions that separate code content from analysis directives. - Code is provided to the AI as data context, not as executable instructions. - Output is validated and structured before being presented to users. #### Access Controls - Scanning a private repository requires your own connected GitHub account; without it, a private repository cannot be reached. Public repositories are different: reading one is not access-controlled, and where you have not connected GitHub we fetch them using a ShipSafe server credential limited to public read-only access. Any signed-in user can therefore submit any public repository. The control here is contractual rather than technical — our Terms require you to scan only repositories you own or are authorized to scan, and you are responsible for that representation. One technical control does apply further down the line: a scan can only be turned into a public ShipSafe receipt or badge when the repository owner matches your connected GitHub login or one of your GitHub App installations. - Your full scan results — the findings, the file and line, the code snippet and the fix guidance — are visible only to you, in your signed-in account. There are two exceptions. The first is the public verification pages described in Section 3: a redacted summary of a single scan, published at an unguessable link, showing the repository or app host that was scanned, the scan date and the number of findings at each severity, and never the findings themselves, file paths, code or secret values. The second is a fix you send to GitHub: the changed code and the pull request are visible to everyone who can see the repository, and on a public repository that is anyone. On a private repository the pull request description also names the findings the run did not fix and the automated reviewer's reasoning about a change it refused; on a public repository it carries only the three counts and a link to the scan page, and that receipt stays in your signed-in account (and in the completion email, unless you have opted out). - The one write that reaches your default branch — merging a fix pull request you approved in ShipSafe — happens only with your own GitHub access, only for the exact commit the receipt covered, and only once per approval: if that commit was changed on GitHub after the receipt was written, no longer fits your code, or your repository requires a review or a check first, GitHub refuses the merge rather than apply it, and ShipSafe tells you plainly rather than force it through. Approving on GitHub yourself works exactly as it always has, outside ShipSafe's control. - GitHub OAuth tokens are stored securely via Clerk and are never exposed to the client. #### Transparency and User Control - Users are informed that AI analysis is performed by Claude (Anthropic) at the point of scan. - Scan results clearly state that findings are AI-generated and should be independently verified. - Users can delete their account at any time from their account settings. That removes everything held under it — scans, findings, chat history, drift records and file manifests — in a single action. There is no per-scan delete button; to have one scan removed rather than the whole account, write to us and we will do it. - Exporting a scan's PDF publishes a public verification receipt for that scan at a private link. Where a receipt is live, the scan page shows the link and a "Take it down" control, which stops the link working for everyone, including anyone who already has it. ### 5\. Conclusion Based on this assessment, the residual risk of ShipSafe's AI-powered scanning to data subjects is **low**. The processing runs only against a repository or application URL you gave us, whether you start each scan yourself or set the schedule and repository connections that repeat it; it is transient in the sense that no copy of your repository is kept — only a short, secret-redacted excerpt stored with each finding, as set out in Section 4 of this DPIA — and it is encrypted in transit and covered by the commercial data protection commitments Anthropic makes for API inputs. Unattended re-scans change how often processing happens, not what is processed: the same targets, the same in-memory handling, the same kind of report, and they end when you remove the connection or leave the paid plan. The informational nature of scan results means no automated decisions with legal or similarly significant effects are made. We will review this DPIA annually or when material changes are made to the scanning process. ## 17\. Contact ShipSafe is operated by Tomer Goldstein, a sole proprietor doing business as ShipSafe. The data controller for the purposes of GDPR and applicable data protection law is Tomer Goldstein. Data Controller & Legal Contact Tomer Goldstein d/b/a ShipSafe Reut 12B, Hod HaSharon 4529614, Israel Email: [support@ship-safe.co](mailto:support@ship-safe.co) ## Sitemap Every page of this site, in markdown: [https://ship-safe.co/sitemap.md](https://ship-safe.co/sitemap.md)