Security at trustbox

How we protect the certification data you share through trustbox, and how to tell us about a vulnerability. Our trust center summarizes this with our privacy, compliance and reliability practices.

Hosting and data location

• Your trust center runs on infrastructure separate from your cloud service offering, so agencies can still reach it when your service is down.
• Your availability page runs as its own service with its own database, so it keeps reporting while the trust center itself is down.
• We ask our hosting provider to place our databases and file storage in eastern North America. That is a placement request, not a contractual data-residency guarantee. If you need one, tell us.
• Trust centers and the customer admin app load no third-party scripts.

Encryption

• Data is encrypted in transit (TLS) and at rest (AES-256).
• Our sites tell browsers to reach them only over HTTPS (HSTS).
• Sign-in links, sessions and API tokens are random values. We store only a hash of each, so a copy of our database can't be used to sign in.

Access control

• Agency users sign in with a single-use link sent to their work email, valid for 15 minutes. Federal addresses are checked against CISA's list of federal .gov domains, refreshed daily, and .mil. Other addresses don't get automatic access.
• Agency systems use the documented API with OAuth 2.0 client credentials. Each client holds only the permissions its creator has, and a permission taken away stops working on live tokens at once.
• Your team signs in to the admin app the same way, and each person's permissions come from their role. The admin app and trust centers refuse forms posted from other sites.
• trustbox staff reach the staff console only through single sign-on, and only if they are on a named list. Every staff change to an account is recorded with who made it, in a log that can't be edited or deleted.

Logging and retention

• Every agency page view, download and API call is logged. You see who accessed what, with monthly and six-month summaries you can export.
• Raw access logs are kept for at least 400 days. Access summaries can't be deleted for 400 days, and their counts can't be lowered.
• Each Ongoing Certification Report freezes a snapshot of your certification data, in storage that locks it against change or deletion.

How we check the CR26 rules

We track every CR26 Certification Data Sharing rule in FedRAMP's list as met or not met yet. A rule counts as met only when an automated test named for it passes. That test runs on every change before it merges, and the build fails if a rule is missing from the list or a met rule has no test. Using trustbox doesn't by itself make your offering meet FedRAMP's rules; you remain responsible for that.

Reporting a vulnerability

If you think you've found a security problem in trustbox, email security@trustbox.dev. Tell us what you found, where, and the steps to reproduce it. Please don't share it with others until we've fixed it.

• Response times. We acknowledge your report within 3 business days and send our assessment within 10 business days. We keep you updated until it's fixed, and we'll credit you if you'd like.
• In scope. trustbox.dev, app.trustbox.dev, status.trustbox.dev, every trust center on tbox.page or a customer's own domain, the trust center API and the tc command-line tool.
• Out of scope. Our customers' own cloud services, denial of service or load testing, social engineering, physical attacks, and reports from automated scanners with no demonstrated impact.
• Safe harbor. We won't take legal action against research done in good faith under this policy. That means you only use accounts and data you own or have permission to use, stop and tell us as soon as you reach anyone else's data, don't keep or share it, and don't degrade the service for others.

We don't run a paid bug bounty. Our contact details are also in security.txt.