Security testing

How we test our own security.

Two layers: a continuous automated isolation-and-authorization suite that runs on every build, and a scoped brief we hand a third-party penetration tester. We tell you exactly where each stands — including that no third-party attestation exists yet.

A third-party penetration test is scoped and scheduled — it has not yet been completed. There is no external DAST/pen-test engagement on record, and we make no completed-attestation claim. The automated suite below runs continuously today; the human engagement below is the scope we will hand a tester. We will publish the result honestly when it exists.

01 · Continuous automated suite

Isolation, proven on every build.

A penetration tester’s most common SaaS finding — broken object-level authorization (BOLA/IDOR) — is pre-empted structurally and re-proven by CI on every commit. These are real test files at the current build.

security/tenant-isolation-audit.test.ts
Structurally scans every dynamic, id-bearing route and asserts ZERO are unscoped — a new route that forgets to scope fails the build (drift-proof).
routes/cross-tenant.test.ts
Behavioral proof that a tenant-A session against tenant-B resource ids returns "not found" — never another tenant’s data.
lib/tenant-isolation.test.ts
Unit-level enforcement of the automatic query-scoping layer that injects the caller’s tenant into every read/write.
db/org-scope-fail-closed.test.ts
The data layer fails CLOSED with no established tenant context — it cannot silently return cross-tenant rows.
security/route-auth-audit.test.ts
Every API route is provably either guarded or EXPLICITLY declared public — no route is accidentally unauthenticated.
security/authz-completeness-audit.test.ts
Mutating operations are role-gated; a change that weakens a required authorization check fails the build.
security/view-as-write-guard.test.ts
Super-admin "view-as" is read-only — it can never drive a WRITE into a target tenant.
security/connector-secret-sealing.test.ts
Connector credentials are envelope-sealed with the tenant bound into the encryption context; a wrong-tenant decrypt fails at the auth-tag layer.
02 · Third-party test scope

The brief we hand a human tester.

The deliverable is a per-finding CVSS report plus a tenant-isolation attestation — zero successful cross-tenant reads or writes across the matrix. Tenant isolation is the primary focus.

01Authentication & session
Account-setup token flow, mandatory-MFA bypass attempts, session cookie hardening/fixation, and anti-enumeration on login and password reset.
02Authorization, IDOR/BOLA & tenant isolation — primary focus
Cross-tenant object access across the full id-route surface, vertical privilege (BFLA), write-path IDOR, view-as abuse, and super-admin gating.
03CSRF
Exact Origin/Referer allow-listing on every state-changing request; allow-list bypass and fail-closed behaviour on a missing config.
04SSRF on connectors & outbound
Self-hosted connector base-URLs and report webhooks pointed at cloud metadata, loopback, link-local, RFC1918, DNS-rebinding, and encoding bypasses.
05Secrets handling
KMS/secretbox-encrypted connector creds and sensor secrets — plaintext leakage in responses, logs, error messages, and public receipt endpoints.
06Rate limiting & DoS
Per-route caps, XFF-spoof bypass, fail-closed fallback, and resource exhaustion on the heavy remediation-preview and scan endpoints.
07Public receipt / verification endpoints
Confirm the unauthenticated receipt endpoints expose only signed, non-sensitive data, ids are unguessable, and no aggregation reconstructs a tenant’s posture.
08Webhooks
Signature verification and replay on the billing webhook, and token strength/scoping on the PR-merge webhook.
09AI / engine-specific
Prompt/policy injection into remediation-engine inputs, and confirming dry-run previews persist nothing (no ledger/cache/credit side effects).

Out of scope for the tester: infrastructure/cloud-account compromise, social engineering, physical security, and the customer’s own connected estate (we hold read-only grants only).

03 · Report a vulnerability

Found something? Report it to security@trustfix.dev. We acknowledge promptly and follow a coordinated, 90-day disclosure timeline with safe harbor for good-faith research. A formal bug-bounty program is not yet published — that is a disclosed roadmap item.

Penetration-testing methodology | TrustFix