Security at BryanLabs

Posture

BryanLabs is a single-operator infrastructure company. The platform is not SOC 2 audited. The controls below are organised against the Trust Services Criteria (security, availability, confidentiality) so that a reviewer can map them to their own questionnaire, and every claim here is one we can show on request. If your procurement needs a formal attestation, write to us; demand is what decides when we commission one.

Infrastructure

Everything public runs on hardware we own, in a rack we control, behind a pfSense firewall and an HAProxy edge that terminates TLS. Workloads run on a bare-metal Kubernetes cluster with a default-deny network policy: each service is allowed only the connections it needs, and nothing else can reach it. Blockchain nodes, databases and the website are separate workloads with separate credentials. Cluster state is declared in version control and continuously compared against what is running, so drift is visible.

Transport

TLS 1.2+ everywhere, Let's Encrypt certificates renewed automatically, CAA records limit who may issue, HSTS at the edge.

Network

Default-deny Cilium policies per workload. Internal services such as the metrics store, databases and the faucet signer are not routable from the internet.

Hosts

Operating systems patched on a schedule with documented reboot runbooks. SSH key-only, no password login.

Backups

Databases and stateful volumes are snapshotted to object storage we run; restores are exercised when the runbooks change.

Access control

Operator access goes through a single identity provider (Authentik) with hardware-key second factor. There are no shared accounts. Secrets live in a password manager and in Kubernetes Secrets with namespaced access; they are never committed to repositories, never in logs, and the automation that runs unattended uses a read-only vault. Site sign-in offers passkeys, OAuth providers and wallet signatures; API keys are hashed at rest and shown once.

Data handling

We hold as little as the service needs. Account data is an email or wallet address and the records you create (webhooks, API keys, registered wallets). Request logs carry IP, path, user agent and request id. Analytics are self-hosted and cookieless. We do not sell data, do not run advertising, and do not share data with third parties except the sign-in provider you chose and the services you explicitly connect. The privacy policy is the authoritative statement of what is collected and why. Data from wallets you query (tax events, balances) is public chain data and is not tied to your account unless you register the address.

API security

Authentication

Session cookies for the browser, bearer API keys for machines. Keys are scoped, rotatable and revocable from the account page; every use is attributed to a key and shown to its owner.

Errors and tracing

RFC 9457 problem details with stable codes, and an X-Request-Id on every response that matches our logs.

Rate limiting

Per-client quotas signalled with the IETF RateLimit headers and Retry-After. Service-wide abuse controls on the faucet are deliberately not published.

Idempotency

Idempotency-Key on spending endpoints so a retried request never acts twice.

Webhooks

Outbound deliveries are HMAC-SHA256 signed with a per-endpoint secret and a timestamp for replay protection.

Deprecation

Changes announced in the changelog and on the wire with Deprecation, Sunset and Link headers; 90 days minimum before removal.

The full contract is on the API conventions page.

Monitoring and incident response

Every public page, API and node is probed every 30 seconds from inside the cluster, and metrics, logs and traces flow to a Grafana stack we run. Alerts page the operator through Alertmanager; each alert has a written runbook. The status page is rendered from those same probes, so what you see is what we see. Abuse of the faucet, failed logins, and unusual request patterns raise alerts of their own.

Change management

All infrastructure and application changes go through version control with signed commits. Deployments are image-digest pinned and recorded; the running cluster is compared with the repository continuously so an unreviewed change is visible. Dependencies are updated on a cadence and scanned on build.

Report a vulnerability

If you find a security issue in bryanlabs.net, its APIs, or the public nodes, email hello@bryanlabs.net with the steps to reproduce. The same contact is published in /.well-known/security.txt (RFC 9116). We aim to acknowledge within two business days and to tell you what we did about it. Please do not test against other users' data, do not run denial-of-service tests, and give us a reasonable window before disclosure; we will credit you here if you want.