Do you hold a SOC 2 report or an ISO 27001 certificate?

No. Pealboard does not hold any security certification or audit report today, and this page does not claim one. If that changes, we will state it here with the report’s date and scope.

Where is data stored?

Your data lives in Neon Postgres, hosted in the AWS us-east-2 region. Attachments are stored in Cloudflare R2, and the application runs on Cloudflare Workers. There is no option to choose a different region today.

Do you have a penetration test?

Not yet. No third-party penetration test has been carried out. When one has, this page will say so, with the date and the tester.

How do I report a vulnerability?

Email security@pealboard.com and describe what you found and how to reproduce it. We’ll reply.

Can an admin read another workspace’s data?

No. No role in any workspace, including an admin, can reach another workspace’s data. That boundary lives in the database and applies to every query, so it does not depend on our application code being correct.

Security

How we protect your data

Here’s how Pealboard keeps your data safe, in plain words. We don’t hold a certification or an audit report yet, and we won’t pretend otherwise. If a safeguard isn’t listed here, we haven’t built it yet.

We hold no security certification

Pealboard has no SOC 2 report, no ISO 27001 certificate, and no third-party penetration test. If your procurement process requires one of these, Pealboard doesn’t meet it yet.

Keeping workspaces separate

Your workspace’s data is kept apart from every other workspace’s, and the database enforces that boundary, not only our application code. Every table that holds workspace data has row-level security enabled and forced, with policies keyed to the workspace.
Even our own application can’t get around this boundary. It connects to the database using a role that cannot bypass row-level security and does not own the tables.
If that boundary ever failed, you would see no data rather than someone else’s. Every request runs inside one transaction that sets the workspace first, so a query that runs without one returns nothing, never another workspace’s rows.
The same protection applies between portals. Portal-scoped tables carry a second policy keyed to the portal, so a request in one portal cannot reach another portal’s data, even inside the right workspace.
New features cannot accidentally expose data either. A new database table with no explicit grant fails loudly instead of quietly inheriting access.

Who can do what

Every part of the API states up front who is allowed to call it, and that is checked automatically: code that skips this step does not compile, so it cannot ship.
Before we look up anything you ask for, we check that it actually belongs to you. Every identifier in a path or a body is checked against the caller’s scope before it is used.
You cannot even tell whether something exists in someone else’s workspace: asking about it comes back “not found”, never “forbidden”. The API never confirms what exists outside your own reach.
An API key can never do more than the person who created it could do. If that member’s role changes, their keys’ permissions change with it, at the same moment.

Signing in, kept safe

Your session cookie can only be used on the exact site that set it. It carries the __Host- prefix, which makes it host-only and stops it being set for a parent domain.
This also stops other sites from tricking your browser into taking action on Pealboard. Cookies are SameSite=Lax, and every change a cookie triggers is checked against the request’s Origin.
Your browser never has to talk to a different domain behind the scenes: the application and the portals proxy the API through their own host.
A customer signed into a portal can never end up with access to your workspace, or the other way around. Workspace sign-in and portal sign-in are two separate systems with separate tables.
Customers never need to create or remember a password. Portal sign-in uses a 6-digit code, good for ten minutes and five attempts, or a sign-in link.

Protecting secrets and credentials

Credentials that power Pealboard are never left lying around. They exist only as Worker secrets, never in a file that is committed, a log line, or a response.
No one at your company, however senior, can see the credential that connects Pealboard to GitHub. The GitHub App’s private key is used only to mint short-lived installation tokens, and no workspace role can see the key or a raw token.
Your API key is shown to you once, when you create it. After that, not even we can recover it: keys are stored as SHA-256 digests, not as the key itself.
Pealboard never asks GitHub for your source code, repository contents, actions or secrets. It reads issues, comments, labels, milestones, projects and organization members, and writes issues, comments and project field values.

What we write into GitHub

You can always tell what Pealboard wrote versus what a person wrote. Everything Pealboard writes into GitHub carries a visible attribution line and a hidden marker naming the portal and the request.
We never put an email address into GitHub on a customer’s behalf. The attribution line carries a display name and a company instead, because text Pealboard writes can be edited later, and an issue in GitHub cannot be taken back.
Your engineers’ internal discussion stays internal by default. Nothing written in GitHub reaches a customer unless a member marks that comment public, or a workspace admin turns on the setting that shows every comment.

Keeping spam and abuse out

Pealboard checks that every update really came from GitHub before acting on it. Every webhook signature is verified before the payload is parsed, and deliveries are recorded by delivery id, so the same one is never applied twice.
Files you attach to a request are not stored in GitHub. Pealboard stores them in Cloudflare R2 and serves them through signed URLs that last 30 days and are re-signed each time the page renders.
This keeps bots from spamming your portal or your sign-up page. Every form you can use without signing in, sign-up, portal sign-in, and submission on an open portal, carries Cloudflare Turnstile, and every one of those paths is rate limited.
A brand new customer’s first request on an open portal does not go straight into GitHub. It waits in a queue until a member releases or rejects it.

Keeping a record

Every change Pealboard makes is logged, with who made it and what kind of credential they used.
If something goes wrong, you will have what you need to report it. Every API response carries a request id, on success and on failure.
You can always see how fresh your data is. Every synced object records when it was last read from GitHub, and that time is shown in the interface.

Questions

Do you hold a SOC 2 report or an ISO 27001 certificate?: No. Pealboard does not hold any security certification or audit report today, and this page does not claim one. If that changes, we will state it here with the report’s date and scope.
Where is data stored?: Your data lives in Neon Postgres, hosted in the AWS us-east-2 region. Attachments are stored in Cloudflare R2, and the application runs on Cloudflare Workers. There is no option to choose a different region today.
Do you have a penetration test?: Not yet. No third-party penetration test has been carried out. When one has, this page will say so, with the date and the tester.
How do I report a vulnerability?: Email security@pealboard.com and describe what you found and how to reproduce it. We’ll reply.
Can an admin read another workspace’s data?: No. No role in any workspace, including an admin, can reach another workspace’s data. That boundary lives in the database and applies to every query, so it does not depend on our application code being correct.

Reporting a vulnerability

Email security@pealboard.com with what you found and how to reproduce it, rather than opening a public GitHub issue. There is no bug bounty and no monetary reward, but you will get an acknowledgement and a fix.