Last reviewed: 2026-09-01
We track every SOC 2 Trust Services Criterion and ISO 27001 Annex A control we consider in scope against what the product’s code actually does — each one backed by a specific file, not a checkbox. That live map is our internal /admin/compliance dashboard; the numbers below are a snapshot of it.
Not a marketing list — every item below is shipped code, cited to its file:
src/lib/auth.ts).src/lib/credentials.ts)./admin/audit-log — never recording secrets or a failed login’s attempted email/identifier.The same honesty standard applies in both directions. These are open, tracked items — not hidden, not silently deferred:
The real, working login bot-check (botCheck.ts) covers login-form submissions specifically. It is not network-layer protection against volumetric abuse, credential stuffing, or general scraping. This is infrastructure a hosting edge (Cloudflare, Vercel's edge network, or similar) provides — it's scoped out of a single Next.js app's own code, and belongs to whoever operates the real deployment, not this reference build. What changed 2026-09-01: real, ready-to-apply configuration for both providers now exists (edge/cloudflare/waf.tf — a Terraform cloudflare_ruleset, syntax-verified against the real HCL parser; edge/vercel/apply-firewall-rules.sh — real `vercel firewall` CLI commands), with every rate-limit threshold set relative to this app's actual existing src/lib/rateLimit.ts numbers rather than invented, and explicit bypasses for the Stripe webhook and cron endpoints. Still genuinely `open`, on purpose — nothing is active, since this sandbox has no real domain or edge account to apply it against; applying it to a real deployment is now a copy-paste-and-fill-in-credentials step instead of a from-scratch design exercise.
Nothing in this build is a substitute for an independent penetration test before handling real homeowner/contractor PII at scale. This is a reference/demo build with no production deployment or bug-bounty program. A real, live self-assessment was run 2026-09-01 (compliance/security-assessment/2026-09-01-self-assessment.md — npm audit plus curl against an actually-running production build) as the closest honest substitute achievable from inside this sandbox, and it found and fixed one genuinely high-severity issue (DEMO-LOGIN-1) — real evidence that this kind of testing finds real things, and exactly why it still isn't a substitute for a professional, adversarial pentest with far more time, tooling, and creativity than a scripted pass can bring.
Not every finding needs the same fix. These are documented, deliberate trade-offs, not oversights:
npm audit reports 7 moderate findings, all in drizzle-kit's (@esbuild-kit/*) and @capacitor/cli's (xcode → uuid) own dependency chains. Both tools already sit at their latest published version and only ship the vulnerable sub-dependency in a local dev CLI (drizzle-kit push/studio, npx cap add/sync/open) — neither is part of the deployed web app or the built native app. The only available 'fix' for the drizzle-kit chain is a major downgrade, which is a worse trade than the finding itself. Re-evaluate as each upstream project migrates off its vulnerable sub-dependency.
We classify data into four tiers — Restricted, Confidential, Internal, and Public — and handle each differently; the public marketplace listings (contractor profiles, category/location pages) are intentionally public, the same way a Yelp or Google Maps listing already is, while account data, messages, and payment metadata sit behind authentication and are excluded from search indexing. Full detail is in our internal Data Classification Policy. See our Privacy Policy for what we collect and why.
We maintain a written policy set — Information Security, Access Control, Incident Response, Data Classification, Vendor Risk Management, and Business Continuity/Disaster Recovery — each grounded in a specific mechanism in the codebase rather than generic template language, reviewed at least annually. These are internal documents; specifics are available on request.
We have no bug-bounty program. If you find a real vulnerability, please report it responsibly — with enough detail to reproduce it — and we’ll investigate and respond through the process defined in our Incident Response Plan.
This page reflects 43 tracked controls across both frameworks as of 2026-09-01. It is maintained alongside the codebase and updated when our security posture actually changes — not on a marketing schedule.