Security at Cipherwake

We sell harvest-now-decrypt-later risk quantification. Our own security posture has to hold up to the same scrutiny we apply to other people’s domains. This page documents what we collect, how we protect it, which third parties we depend on, and how to report a vulnerability. No spin, no audit-report theater.

Last updated: 2026-05-13.

What data we collect

Public scanner traffic

Every /api/scan invocation is recorded in an event log used only for internal analytics + abuse detection. The fields stored:

• Domain scanned — validated against our DNS hostname regex; never raw IP addresses.
• Score, grade, reachable — output of the scan.
• Client class — web / CLI / extension / action / slack / other (inferred from User-Agent and explicit ?source= tag).
• Hashed IP — SHA-256 of the client IP, salted with a server-side secret. The IP is never stored in raw form. Even we cannot reverse the hash. If the salt env var is missing, we store null instead of an unsalted hash.
• Referrer host only — truncated to 128 chars; query strings and paths are discarded.
• API endpoint name + CLI subcommand — for the analytics dashboard.

We do not collect: cookies, fingerprints, geolocation, names, or any field that could re-identify an individual visitor.

Verified Monitoring Badge subscribers

For customers who buy the $49/mo badge, we additionally store:

• Email address — collected by Stripe at checkout; we mirror it to the verified_badges row.
• Domain — the customer’s domain that the badge monitors.
• Stripe identifiers — customer ID, subscription ID, price ID, checkout session ID. No card data is ever stored on our infrastructure.
• Signing secret — a per-row HMAC seed used to sign embed tokens. Stored as a 256-bit hex string in the DB.
• Portal access token (hashed) — we store SHA-256 of the raw token plus a server-side pepper. The raw token is only ever in the customer’s welcome email. A DB leak alone cannot reconstruct usable portal credentials.

How we protect it

Subprocessors

The third parties we depend on. Each carries a portion of the data described above:

This list is the complete set. We add or remove subprocessors on this page within seven days of any change.

Personal-data breach notification

Cipherwake will notify affected paid-account owners by email within 72 hours of becoming aware of a Personal Data Breach affecting their data (GDPR Article 33-style). The notification will describe the nature of the breach, the categories and approximate number of affected data subjects, the likely consequences, and the measures taken or proposed to address the breach. Notifications are sent by email to the account-owner address on file — keep that address current.

Full breach-notification terms live in our Data Processing Agreement §8.

Incident response

We don’t publish a formal incident-response playbook (Cipherwake is a solo-founder pre-revenue project), but our practice is: triage on receipt, contain immediately, preserve evidence, notify affected customers within the 72-hour window above, then publish a public post-mortem for incidents with broad customer impact. Past incidents (none material to date) would be listed on /status.

Support response expectations

We aim to acknowledge customer emails on a best-effort basis. There is no formal SLA on Starter / Growth / Scale self-serve subscriptions. Security-related emails (security@cipherwake.io) are prioritized above general support. We’ll be honest about turnaround if it’s slower than usual.

Backup & disaster recovery

Customer data is hosted on Supabase (Postgres on AWS us-east-1), which performs continuous WAL backups and daily snapshots with managed retention. We do not publish guaranteed RPO/RTO numbers on self-serve tiers. If your organization needs contractual recovery targets, contact legal@cipherwake.io to discuss whether we can accommodate.

Account-owner recovery

Accounts have exactly one owner (enforced by database constraint). If the original owner is unreachable — left the company, lost credentials — a team admin can request owner-transfer by emailing legal@cipherwake.io with proof of corporate authority (e.g., an employment-verification letter on company letterhead OR a DNS-TXT-record demonstration of control over the account’s primary domain). We review each case and complete legitimate transfers once verification is satisfactory; specific timelines aren’t guaranteed.

Vulnerability disclosure

If you find a security issue in Cipherwake — the scanner, the website, the browser extension, the CLI, the API, the GitHub Action — please email security@cipherwake.io with details.

What to include

• Description of the issue.
• Step-by-step reproduction (URL, request body, expected vs. actual).
• Suggested severity (your read).
• Whether you’re willing to be credited publicly.

What we promise

• Acknowledge receipt within 72 hours.
• First-pass triage within seven days.
• Disclosure timeline negotiated with you; default 90 days from acknowledgement.
• Public credit on this page once the issue is fixed (unless you prefer anonymity).

Out of scope

• Reports generated by automated scanners with no manual verification.
• Social engineering attacks against staff.
• Denial-of-service via excessive request volume (we’ve already rate-limited every public endpoint).
• Missing security headers on assets that don’t need them (e.g., no CSP on the badge SVG endpoint — the SVG is the response body).

Safe harbor

If you act in good faith and follow this policy — no destructive actions, no exfiltrating data beyond what’s needed to prove the issue, no public disclosure before the agreed timeline — we will not pursue legal action or report you to your employer / ISP / etc. Cipherwake considers your research authorized.

We don’t currently run a paid bug bounty. If you want to be paid for substantive findings, mention it in your initial email and we will discuss.

Compliance posture (honest answer)

We do not currently hold SOC 2, ISO 27001, or any other formal compliance certification. We don’t pretend to. We’re a small, pre-Series-A engineering team, and our customers are mostly individual engineers and small teams — not Fortune 500 procurement departments.

What we offer instead:

• This page — the same level of disclosure a SOC 2 Type II report contains (data flows, encryption, subprocessors), without the audit-fee theater.
• Public methodology pages for every scoring component — see /methodology.
• Source-available scanning logic — the CLI (npm: pqcheck) runs the same code we run server-side. Auditors can read it.
• Coordinated vulnerability disclosure (above).

If your purchasing process requires SOC 2, we’re happy to discuss timelines — we plan to begin SOC 2 prep when a customer specifically needs it. Email hello@cipherwake.io.

Security contact

Reports: security@cipherwake.io
Procurement / due-diligence questions: hello@cipherwake.io
Machine-readable contact (RFC 9116): /.well-known/security.txt

This page is the canonical source of truth for Cipherwake’s security posture. We update it whenever something material changes.