Security
Security isn't a feature. It's how we build.
We're a small team that takes security seriously. Not because a compliance checklist told us to, but because the systems we build are the thing standing between a customer's data and everybody else's.
Consulting work means holding other people's credentials. Production database access, cloud accounts, deploy keys, payment gateway secrets — the engagement usually starts with someone handing over the keys to a system they cannot afford to have broken. That is a real thing to be trusted with, and it shapes how we work more than any policy document would.
So what follows is deliberately specific. Not a list of the security practices a company is supposed to claim, but the ones you can point at in systems we have actually shipped — how tenants are kept apart, where secrets live, what a token is allowed to do, and what gets written down when something happens.
Found something?
If you've discovered a security vulnerability, we want to hear about it. Skip the public GitHub issue and reach out directly. We respond fast and we'll credit you, unless you'd rather stay anonymous.
Initial acknowledgment within 24 hours
Full triage within 72 hours
Depends on severity, usually 30-90 days
Include in your report
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (optional)
Please don't
- Disclose publicly before we've patched
- Access other users' data
- Perform destructive testing
Security baked in, not bolted on.
Every line below is something running in a system we built and still maintain, which is the only version of this list worth publishing.
Platform & edge
- WAF on production sites — rate-limit rules, IP blocking, referrer filtering
- DDoS protection with per-site sensitivity
- Edge configuration driven through our own API
- Partners never hold CDN vendor credentials
Tenant isolation
- Every query scoped to the authenticated account
- Ownership checked in policy, not per controller
- Shared traits make an unscoped query hard to write by accident
- Isolation asserted in the test suite, not assumed
Credentials & secrets
- Secret values stored in AWS Secrets Manager, never returned by the API
- Passwords and tokens shown exactly once
- Reserved keys blocked so config can't shadow platform internals
- Sensitive parameters marked so they can't reach a log line
Authentication & access
- Token auth with granular, per-resource ability scoping
- Abilities enforced at middleware on every route group
- A read token cannot write, whatever the endpoint does
- Staff access is a separate, deliberate path
Rate limiting & abuse
- Budgets per operation class, not one global bucket
- Mutations and credential resets held to 10/hour
- Deployments 30/hour, CDN and log queries 60/hour
- Expensive infrastructure calls protected without slowing reads
Verification & audit trail
- Static analysis at PHPStan level 7 with strict rules
- 759 test files, 266 of them on the hosting platform alone
- HMAC signature verification on every inbound callback
- Every event logged with actor, token, IP and resource — and queryable
Security advisories
When something significant happens, we communicate. Security advisories go out through:
- Security advisories on the affected repository, for anything in our open source projects
- Direct email to affected customers
- Critical issues posted here
Questions about any of this, or about how we'd handle access on an engagement of your own? We're happy to go into more detail than this page does.