Security & Trust

How We Protect
What You File With Us.

A short, plain-language summary of how Timberlark's infrastructure, access controls, and testing practices work — and how to reach us if you find a problem.

🔐 Infrastructure & Data Protection
Timberlark runs on Supabase (Postgres) and Vercel, two infrastructure providers used by companies well beyond our size, rather than self-managed servers. All data in transit is encrypted via HTTPS/TLS. Application secrets and API keys live in the hosting platform's encrypted environment variable store, never in source code. Customer-facing API keys are stored as one-way hashes — Timberlark itself cannot read a key back out once it's issued, only verify a match.
Encrypted at rest & in transit
Database storage and all network traffic use industry-standard encryption throughout.
Hashed credentials
API keys and equivalent secrets are stored as hashes, never in plain text.
Managed infrastructure
Hosting, patching, and network security are handled by established providers, not ad hoc.
🧱 Access Control
Every table in the database enforces row-level security (RLS) — access rules evaluated by the database itself on every single query, not just checked once in application code. A user's own data is scoped to their own account by default; anything made public (like a shareable verification link or the public Chain Explorer) is an explicit, deliberate exception, not an accidental gap. Public, unauthenticated endpoints are rate-limited to prevent abuse.
Row-level security everywhere
Database-enforced, not just application-layer — the rule holds even if a request bypasses the app.
Least-privilege by default
Public visibility is an explicit, named exception on specific fields — never a blanket default.
Rate limiting on public endpoints
Unauthenticated tools (like our live verification check) are capped per visitor to prevent abuse.
🧪 Testing Methodology
Changes that touch access rules or sensitive data are verified against a live, real database connection using the actual permission role a real end user would have — not just assumed correct from reading the code. Before anything is considered done, we confirm both that legitimate access still works and that access that should be blocked is actually blocked. We run periodic reviews of the platform's access rules as new features are added, since a rule that was correct on day one can be quietly undermined by something built later.
📣 Responsible Disclosure
If you believe you've found a security issue with Timberlark, we want to hear about it directly, before it goes anywhere else. We commit to acknowledging your report, investigating promptly, and keeping you updated as we work on a fix. Please give us a reasonable window to resolve an issue before any public disclosure, and avoid accessing, modifying, or exfiltrating data beyond what's needed to demonstrate the issue.

Found something? Please report it directly rather than posting it publicly — we take every report seriously and respond personally.

jeanine.bradbury@timberlark.com →
Where we are today: Timberlark is an early-stage platform, and we'd rather be upfront about that than overstate it. Dedicated Technology Errors & Omissions insurance is not yet in place — quotes have been obtained and coverage will be secured before our first enterprise contract signs. We don't run a bug bounty program at this stage, but every report is read and acted on directly by the founder.
© 2026 Still Stumpin Logging Inc. All Rights Reserved.
Still Stumpin Logging Inc, operating as Timberlark  ·  timberlark.com