Mechanisms, not posture

Tenant isolation is enforced by the database, not by application code. Every table has row level security switched on, and every policy keys off the workspace a row belongs to — directly, or through the parent it hangs from. A query that forgets a where workspace_id = returns nothing rather than returning someone else’s monitors.

This is the difference between a mistake being a bug and a mistake being a breach. Application-layer checks are one forgotten clause away from leaking; a policy at the row itself has to be deliberately removed.

Inside a workspace, members have roles, and what each role may do is checked on the server on every request rather than by hiding buttons in the interface.

There are two ways in: Google, or a one-time link sent to your email. We store no passwords, which means there is no password database of ours to leak, no reuse risk from another site’s breach, and nothing for anyone to phish out of us.

Sessions are held in HTTP-only cookies that browser JavaScript cannot read, over HTTPS only. Signing out ends the session.

Because the email inbox is the credential, the security of your account is the security of your email. Put a second factor on that account if you have not.

API keys are stored as a hash. We keep a short prefix so you can tell which key is which in a list, and nothing else — which is why a key is shown once, at creation, and cannot be shown again. If we could show it to you later, we could also lose it to whoever read our database.

Keys are scoped to one workspace, record when they were last used, and can be revoked immediately. The public API is read-only, so a leaked key cannot be used to change or delete anything.

This is the risk unique to a monitoring product. We run HTTP requests against addresses that customers type in, from our own infrastructure. Done carelessly, that is a server-side request forgery engine with a signup form on the front.

So every outbound check goes through a guard that:

• resolves the hostname and rejects private ranges, loopback, link-local and unspecified addresses, in both IPv4 and IPv6;
• rejects cloud metadata endpoints specifically, including 169.254.169.254, which is the address that turns an SSRF into stolen credentials;
• re-validates every redirect hop rather than only the first URL, capped at five hops, because a public URL that redirects to an internal one is the obvious way around a naive check;
• pins the connection to the IP address it validated, so a DNS answer that changes between the check and the connection — the rebinding attack — cannot move the request somewhere else.

The one range that a development flag can open is loopback, so the local test target can be checked during development. Private networks and metadata addresses stay blocked even then.

Every notification is recorded in an outbox in the database first, and only then handed to email, Slack, Telegram or your webhook. The record of what we tried to tell you, and when, survives a failure of the thing that was meant to deliver it — including a failure of ours.

Each outbox row carries a key unique to one transition and one destination, enforced by the database rather than by the code that writes it. A retry, a replay or two workers racing produce the same key and the second write is rejected, so a team is paged once for an incident opening rather than fifty times.

Webhook payloads go to the URL you set, over HTTPS. Treat that URL as a secret: anyone who has it can post to your endpoint.

Everything is served over HTTPS, including status pages on your own domain, where certificates are issued and renewed automatically.

Data at rest is encrypted by the providers that hold it — the database, the check-history store and the payment provider — each of which is named on the subprocessors page with what it can see.

Card details never reach us at all. Checkout happens on the payment provider’s own page; what comes back to us is an identifier, an amount and a date.

Server-side secrets — the database service key, provider API tokens — exist only in server environments and are never bundled into anything a browser downloads.

Actions that change a workspace are recorded with the actor, the target and the time, and workspace admins can read them. It is there so that “who deleted that monitor” has an answer, which is a question that only ever gets asked on a bad day.

A security page listing only strengths tells you nothing, so here is the other half. None of the following is true today, and we will not imply otherwise:

• No SOC 2 report and no ISO 27001 certificate. We have not started either. If your procurement process requires one, we are not the right vendor yet, and we would rather you found that out on this page than three weeks into a questionnaire.
• No third-party penetration test has been carried out on the platform.
• No bug bounty programme. We will thank you, credit you if you want it, and fix the thing. We cannot pay for reports yet.
• No SAML single sign-on and no enforced two-factor authentication of our own. The second factor today is whatever protects your email or Google account.
• Checks run from a single region. Multi-region probes are on the roadmap, not in the product.
• No formal 24/7 on-call rotation on our side. We are small, and we would rather say that than imply a follow-the-sun operation that does not exist.

Email hello@pinguhq.com with the subject “Security report”. Include what you found, how to reproduce it, and how you would like to be credited. Nothing fancier than that is needed and there is no form.

We aim to acknowledge within three working days and to tell you what we are doing about it within ten. If it is serious we will move faster and we will keep you posted while we fix it.

Testing safely

We will not pursue anyone who reports a genuine issue found in good faith, provided you:

• test only against your own account and your own data;
• do not run denial-of-service or load tests, do not spam the signup form, and do not use automated scanners against production;
• stop as soon as you have proved the issue, and do not read, modify or keep anyone else’s data;
• give us a reasonable chance to fix it before you publish.

Reports that are only the output of an automated scanner, missing security headers with no exploitable consequence, or issues in a third-party service rather than in ours, are the ones we are least able to act on.

If something happens to us

If we suffer a breach affecting your data, we will tell you what happened, what was affected and what we did, without undue delay and without a press release about how seriously we take security. Where the law requires a regulator to be told, we will tell them too.