Security and data
Slipmark works on hashes, not code. We record which files a verdict was about and whether they still match, and nothing that would let anyone reconstruct the files themselves.
What we never store
Source code or file contents. The GitHub Action hashes files inside your own CI job and sends only paths and hashes. To re-verify a run, Slipmark Cloud uses the GitHub App to read the attestation files and each attested file from GitHub's copy of that commit, hashes them in memory and keeps only the hashes and the result. The app also lists which files a pull request changed. Agent notes are stored as written, so keep secrets out of attestation notes as you would out of commit messages.
What we store
| Data | Details |
|---|---|
| Repositories | Name, owner, GitHub repository and owner ids, and whether the repository is public or private. |
| Runs | Commit SHA, branch or pull request ref, pull request number, workflow name, workflow run id and attempt, event type, and a pseudonymous id for the person who triggered the run. Their GitHub login is held separately so it can be erased. |
| Verdicts | File paths, SHA-256 hashes, agent names, verdicts, the time each attestation says it was made, and any note the agent wrote. |
| Gate results | For each verdict, whether it was verified, stale, missing or not passing: both CI's report and Slipmark Cloud's own re-verification against GitHub. |
| Accounts | GitHub account id, login and type, your plan, seat count, and Stripe customer and subscription ids. |
| Rules and logs | Your rules, rule results per run, and the account log of rule changes and overrides, including the reason text. |
| Alerts | Each destination an admin adds: its webhook URL, PagerDuty key or email addresses, which events it gets, and the last 30 days of deliveries. Generic webhook signing secrets are generated by us. For the Slack app, the workspace and channel, and the bot token, encrypted with AES-256-GCM. |
| Slack links | If someone approves from Slack: their Slack workspace and user id, linked to their GitHub id and login. |
Records are kept indefinitely so they stay verifiable. The ledger and the account log are append-only by design and cannot be deleted. Rule results and re-verification results are stored the same way. People are kept out of those records: each run holds only a random id for whoever triggered it, and their GitHub login sits in a separate table. If someone asks to be erased, we remove their login from that table and every run they triggered becomes unlinkable to them, without breaking the chain. Logins of admins who change rules or approve overrides stay in the account log, because that record of who approved what is the point of it. Keep personal data out of agents' notes: they are stored as written. Privacy notice · Data processing agreement · Sub-processors.
Where it lives
| Provider | Used for |
|---|---|
| Supabase | Database and ingest functions, in the eu-west-2 (London) region. |
| Vercel | Hosting for this website and dashboard. Server code runs in London (lhr1). |
| Stripe | Payments, subscriptions and invoices. |
| GitHub | Sign-in, the GitHub App, and the checks we post on pull requests. |
| Sigstore Rekor | Public anchors: signed digests of ledger hashes only, with no repository names, file paths or verdicts. |
| Resend | Email alerts, only if you add an email destination. Emails include the repository, pull request, rule names and file paths. |
| Alert destinations you choose | Slack, Microsoft Teams, Discord, Google Chat, PagerDuty or your own webhook receive the alerts you route to them, including the repository, pull request, rule names and file paths. Nothing is sent anywhere you haven't added. |
How access works
- Recording runs. The ingest endpoint only accepts a GitHub Actions OIDC token issued for the audience
slipmark, verified against GitHub's published keys. The repository, commit and run come from the signed token, so a run can only write to its own repository's ledger. There are no API keys to leak. - Not trusting CI alone. Where the GitHub App is installed, Slipmark Cloud re-checks every verdict against GitHub's own copy of the commit and uses its own result for checks and rules. If CI reported verdicts that GitHub's copy doesn't support, the Slipmark check fails and says so. Very large commits (over 200 attestation files or 600 attested files, or a tree too big for GitHub to list in full) fall back to CI's report, and the proof page says when that happened.
- Signing in. GitHub OAuth. Your session is an encrypted, HttpOnly cookie that expires after 8 hours. We check which repositories you can see through GitHub on each visit, so leaving a GitHub organisation removes your access here too.
- Private repositories. Their proof pages are only shown to signed-in users who can see the repository on GitHub. Share images never include private repositories.
- Admin actions. Rules, overrides, alerts and billing need an organisation admin, checked with GitHub at the time of the action.
GitHub App permissions
| Permission | Access | Why |
|---|---|---|
| Checks | write | Post the Slipmark and Slipmark policy checks. |
| Contents | read | Re-hash attested files from GitHub's copy of the commit, and list the files a commit changed. |
| Metadata | read | Required by GitHub for every app. |
| Pull requests | read | Find a pull request's head commit and changed files. |
| Members | read | Check who is an organisation admin. |
The app never writes code, opens pull requests or changes settings.
Open source
The gate, the CLI and the GitHub Action are open source under Apache-2.0 at github.com/founder-ship-it/Slipmark. You can read exactly what runs in your CI and what it sends.
Reporting a security issue
Email hello@replyintelligencegroup.co.uk with what you found and how to reproduce it. We reply within two working days, keep you updated while we fix it, and credit you if you'd like. Please give us a reasonable time to fix an issue before you publish it, and don't access other people's data, disrupt the service or test against accounts that aren't yours. We won't take legal action over research done in good faith within these rules. Our security.txt has the same details.
Contracts and reports
Slipmark Cloud is run by Reply Intelligence Group Ltd, registered in England and Wales, company number 17040048. A data processing agreement is available on request, and comes with Business. To ask for one, or to report a security issue, write to hello@replyintelligencegroup.co.uk.