Cinderblock

Disclaimer

The pgtap suite proves the patterns shipped in this template. It does not prove your fork is secure if you modified the policies.

Cinderblock's test suite asserts a specific surface: every policy under the public schema honors the tenant boundary, every app_private.*helper is hardened, every audit invariant holds, the seat trigger fires when expected. If you change any of those — even "just renaming a column" — the guarantee is your fork's responsibility, not the template's.

What the tests prove

  • A user with no membership in workspace X cannot read, create, update, or delete rows belonging to X — under SELECT, joins, UNION, CTEs, subqueries, and aggregate queries.
  • Append-only audit (no UPDATE or DELETE grant exists for authenticated).
  • Search-path attack denied (helpers have set search_path = '').
  • Past-due-beyond-grace and canceled workspaces are read-only (workspace_is_writable gates inserts/updates).
  • Insert-first Stripe webhook idempotency (duplicate event_id returns 0 rows from RETURNING).

What the tests do NOT prove

  • Your fork's policies are correct after modification. Extend the tests when you modify a policy.
  • Anything about your hosting environment (TLS termination, DDoS mitigation, secret leakage via logging, etc).
  • Cinderblock is not a substitute for a third-party security audit. Use the pgtap suite as a structural floor; layer audits, penetration tests, and ongoing reviews on top for production.

Compliance

See Compliance posture for SOC2 / GDPR framing. Short version: Cinderblock ships the technical controls (audit log, impersonation tracing, MFA enforcement, retention) that make a compliance posture defensible, not the attestation itself.