BleedWatch
Available from Community

The pre-launch checklist nobody publishes.

What I've shipped, what I haven't, and which gaps I'm comfortable about vs which keep me up. A solo founder's honest pre-launch ledger.

Founder byline - 2026-03-14

Why this article exists

Most security vendors publish a Trust Center that reads like the destination. "SOC 2 Type II. ISO 27001. NIS2 controls mapped. DORA evidence chain." No mention of the year and a half it took, the cluster of compromises along the way, the items still on the backlog. The Trust Center is the polished surface. The work happens behind it.

I haven't reached most of those certifications yet. BleedWatch is six months old and pre-launch. I am one person. The honest version of where we are is more useful than a polished version of where I want to be in 2027. This is that honest version.

What's shipped and battle-tested

Tenant isolation at the database layer. PostgreSQL row-level security covers Phase 1 tables (findings, scans, assets) and Phase 2 (saintscan_mcp_audit, saintscan_mcp_breakers). Application identity sets app.current_tenant on each request. The connection routing is tenantDb() / scopedDb() for tenant-scoped paths and dbAdmin (commented with rationale) for admin-only paths. CI enforces a header annotation on every new file under apps/api/src/modules/ and apps/scanner/src/workers/.

Envelope encryption with the master key off-host. AES-256-GCM with per-tenant data encryption keys. The master KEK lives in a Cloudflare Worker (the KMS proxy) and is not extractable by any application process. Encrypt/decrypt operations go through the worker.

MCP gateway for active validation. The SaintScan path — nuclei, sqlmap, naabu, httpx, katana — is mediated by a gateway that runs each invocation through an allowlist, scope validator, argv sanitizer, digest-pinned image resolver, policy gate, circuit breaker, and synchronous audit insert into an immutable table. No tool runs without the audit row landing first. The audit table uses REVOKE + trigger to enforce append-plus-one-finalize semantics at the database layer.

Multi-LLM cross-validation in the detection pipeline. Four models — Claude Sonnet, Gemini Pro, GPT-5.5, Mimo-32B — on every high-stakes detection. Documented in the Clearwing article. Real escalation queue at ~4% rate.

Bot/scanner protection at three layers. Caddy WAF rules, Next.js middleware blocking scanner UAs and honeypot paths, Fastify onRequest blocks at API. UFW limits to 22/80/443 on the VPS.

Daily encrypted backups. Hetzner Falkenstein primary, encrypted backup target. Restoration tested quarterly — last drill was 2026-04-11, restored to clean staging in 48 minutes.

These are not aspirational. They are running today. I will stake my credibility on the trace evidence behind each.

What's partially shipped

SOC 2 control mapping. The control inventory is mapped (CC1-CC9, plus the trust services criteria). Evidence collection is automated for ~70% of controls. We don't have an audit firm engaged yet. Target Q3 2026. The status badge on /trust says "In progress" — that's accurate.

ISO 27001. Annex A control mapping is done. Statement of applicability drafted. Information security management system documents are sketched. Not certifying until 2027 at earliest.

Bench public methodology. The bench table at /bench is published with capability claims from public docs and product trials. Methodology is documented. Corrections are accepted at [email protected]. What's missing: the quantified methodology — repeatable scan reproductions with shareable test corpora. I want this and it's a 2026 H2 item.

Customer-facing audit log for high-impact actions. Activity logging exists for admin actions (security audit log table). It's not surfaced to customers in-product as a viewable log yet. Target: Q3 2026.

What's on the gap list

These are the things that legitimately keep me up some nights.

Penetration test summary. I have not yet had an external pentest. I plan to commission one in Q3 2026, with the summary published on /trust once landed. Until then, the platform's security posture rests on internal review + multi-model architecture audits + the controls listed above. This is the single biggest credibility gap I'd point a CISO toward myself.

Bug bounty program. No formal bounty yet. Responsible disclosure policy is published at /security#responsible-disclosure with PGP key + scope + SLA + safe harbor. I respond to disclosures myself, same day for criticals. A formal program with rewards lands when the platform has a paid customer base that warrants the operational ramp.

24×7 incident response. Sentinel-tier SLA in the pricing matrix promises 24×7 incident response. Today that's me + a paging mechanism. The pricing matrix is honest that this tier ships at the high end and reflects what's realistic for a solo founder. When I hire, the first hire is likely SecOps for exactly this.

Multi-region inference for the LLM dependency. Anthropic API EU region is GA-pending. Until it lands, EU-residency-strict customers are on the AI-Off toggle. This is an acceptable but imperfect answer that I want to upgrade.

Disaster recovery RTO under 4 hours. Current restore time on the quarterly drill is 48 minutes for the application tier, but reconstituting the full kill-chain correlation graph from cold backups takes longer because of the index rebuild. The 4-hour target is achievable; the validation of a clean 4-hour drill is a 2026 H2 item.

The reasoning behind the publication

I am publishing this because I think transparency is the only credibility move that compounds in the right direction.

A polished Trust Center that doesn't acknowledge the gaps is fragile. The first time a customer asks the right question and the answer is "we don't have that yet," the polish becomes the liability. Versus: a checklist that names the gaps in advance means the customer is reading the platform's actual state, not a marketing fiction. Every conversation I've had with a CISO since publishing this exact list has gone faster, not slower.

There is one risk I'm taking by publishing this. A competitor's marketing team will screenshot it and claim "BleedWatch admits they haven't shipped X." That's fine. The competitor's customers will eventually ask their vendor the same question — "show me the equivalent honest ledger" — and the silence will be the answer.

What the next checklist looks like

Six months from now I'd like the published version of this to mention: external pentest summary published, SOC 2 Type II in audit window, EU multi-region inference live, bug bounty program with first researchers credited, 4-hour DR drill passed. Two or three of those will land. The other items will move. That's how the work goes.

If you want to track the cadence, the changelog at /changelog posts release entries when items move from this list to the shipped one. The current list is at /changelog filtered by tag:trust.

If you've shipped this kind of ledger publicly and want to compare notes, [email protected].

The detection described in this article is available from Community tier upward.

Start scanning what attackers see.

Free tier, 3 assets, no credit card. Or jump straight to Shield with a 14-day trial.