Start free

Security

What is true today, and nothing that is not

This page states the security posture as it is. Pealboard holds no certification and no audit report, and nothing on this page implies one. Where a control does not exist, it is not listed.

No certification is claimed

Pealboard has no SOC 2 report, no ISO 27001 certificate, and no third-party penetration test. If your procurement process requires one, Pealboard does not meet it today. That sentence is here rather than in a footnote because it is the first thing a security reviewer needs to know.

Tenant isolation

  • The tenant is the workspace. Isolation is enforced by the database, not by the application: every tenant table has row-level security enabled and forced, with restrictive policies keyed on the workspace.
  • The application connects as a role that cannot bypass row-level security and does not own the tables.
  • Every request runs inside one transaction that sets the workspace first. A query that runs without one returns nothing rather than returning somebody else’s rows.
  • Portal-scoped tables carry a second restrictive policy on the portal, so a portal request cannot reach another portal’s data even inside the right workspace.
  • A new table without an explicit grant fails loudly rather than inheriting access.

Authorization

  • Every route declares who may call it. A route without that declaration does not compile.
  • Every identifier that arrives in a path or a body is checked against the caller’s scope before it is used.
  • An object in another tenant is reported as not found, never as forbidden. Whether an object exists elsewhere is not something the API confirms.
  • An API key can never do more than the role of the member who created it. Changing that member’s role changes what their keys can do at the same moment.

Sessions and browsers

  • Session cookies carry the __Host- prefix, so they are host-only and cannot be set for a parent domain.
  • Cookies are SameSite=Lax, and every state change carried by a cookie is checked against the request’s Origin.
  • The browser never leaves its own origin: the application and the portals proxy the API through their own host.
  • Workspace sign-in and portal sign-in are two separate systems with separate tables. A customer’s portal session can never become a workspace session, or the reverse.
  • Portal sign-in is a 6-digit code with a ten-minute life and five attempts, or a link. There are no portal passwords.

Secrets and credentials

  • Secrets exist only as Worker secrets. None is in a file that is committed, in a log line, or in any response.
  • The GitHub App’s private key is a secret used only to mint short-lived installation tokens. No workspace role can see it or a raw token.
  • API keys are stored as SHA-256 digests. A key is shown once, at creation, and cannot be recovered afterwards by anyone, including us.
  • Pealboard never asks GitHub for code, repository contents, actions or secrets. It reads issues, comments, labels, milestones, projects and organization members, and writes issues, comments and project field values.

Data written into GitHub

  • Everything Pealboard writes into GitHub carries a visible attribution line and a hidden marker naming the portal and the request.
  • The attribution line carries a display name and a company, never an email address, because a body Pealboard authored can be rewritten later and an issue in GitHub cannot be recalled.
  • Nothing an engineer writes in GitHub reaches a customer unless a member marked that comment public, or a workspace admin turned on the portal setting that shows every comment.

Webhooks, uploads and abuse

  • Every GitHub webhook signature is verified before the payload is parsed. Deliveries are recorded by delivery id and are idempotent.
  • Attachments are stored by Pealboard in Cloudflare R2 and served through signed URLs with a 30-day life, re-signed on each render. They are never served from GitHub.
  • Every unauthenticated form — sign-up, portal sign-in, and submission on an open portal — carries Cloudflare Turnstile, and every unauthenticated path is rate limited.
  • An open portal holds a new customer’s first request in a queue that a member releases or rejects. Nothing reaches GitHub until it is released.

Record keeping

  • Every write is recorded in an audit log with the actor and the kind of credential used.
  • Every API response carries a request id, on success and on failure.
  • 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 holds no security certification and no audit report, and this page claims none. When that changes it will be stated here with the report’s date and scope.
Where is data stored?
Pealboard’s database is Neon Postgres in the AWS us-east-2 region. Attachments are in Cloudflare R2. The application runs on Cloudflare Workers. There is no regional residency option today.
Do you have a penetration test?
No third-party penetration test has been carried out. This page will say so, with the date and the tester, when one has.
How do I report a vulnerability?
Email security@pealboard.com. Describe what you found and how to reproduce it. You will get a reply.
Can an admin read another workspace’s data?
No role in any workspace can reach another workspace’s data. The boundary is in the database, applied to every query, and it does not depend on the application being correct.

Reporting a vulnerability

Email security@pealboard.com with what you found and how to reproduce it. Do not open a public GitHub issue. There is no bug bounty and no monetary reward; there is an acknowledgement and a fix.