What backs the mark, and what does not.
A certificate is only worth as much as the record behind it. This page says what the audit keeps, how the platform protects it, and the limits that remain.
What the audit keeps.
The public mark is a summary. The durable, versioned record is the basis for it.
Everything the audit decided, and whyA certificate is a summary; the audit record underneath it is what makes the summary defensible. Every check is stored with its verdict, its duration, the exact detail it reported, and — for a finding — the remedy. A dispute about a Tbench Certified is settled by reading the record, not by asking someone to remember why they decided something months ago.
per-check verdict, detail and remedy retained
A revision, fixed at submissionA set is graded against the methodology revision that was current when it arrived, and that revision is printed on the certificate. The methodology can change; a past certificate does not silently change meaning with it. Re-auditing under a newer revision is a separate, explicitly requested act.
methodology version recorded per certificate
Refusals are keptA refused set stays in the register and stays findable by its id. Deleting refusals would turn the register from a record into a marketing channel — and the first buyer who noticed would be entitled to discount every certificate on it.
refusals retained and verifiable
What protects it.
These are the controls the platform implements today, with the evidence behind each claim available in the disclosure.
The database is not on the networkPostgres runs in a container with no published port. It is reachable only by the API container over the internal compose network. A port scan of the host shows nothing on 5432.
db: 5432/tcp, no host mapping
Data at rest is encrypted by the volume underneathOn the recommended deployment the container's data directory lives on an encrypted EBS volume. This is worth being precise about: encryption at rest comes from the block storage under the database, and must be enabled before the instance is created — an existing EBS volume cannot be encrypted in place.
EBS encryption, enabled at instance creation
The containers are locked downThe API container runs with a read-only root filesystem, no privilege escalation, and all Linux capabilities dropped except the ones it needs. A compromised process has less to work with.
read-only rootfs, cap_drop: ALL
Backups are real and the restore is provenDumps are taken in Postgres custom format, which is restorable and verifiable. The restore procedure is documented and has been run end to end against the live stack — including a scrub-restore into a throwaway database that cannot touch production.
pg_dump -Fc, restore drilled
What we do not claim.
These are deployment boundaries, not decorative warnings. They are published so a technical reviewer can assess the platform on the facts.
- 01
The database container's volume is not encrypted by itself. Encryption at rest is a property of the block storage underneath it, not of the container.
- 02
There is no secrets manager. Configuration lives in an environment file with restrictive permissions, and rotating a secret is a documented manual procedure.
- 03
There is no intrusion detection or fail2ban. The recommended deployment exposes 443 only, and 80 solely for certificate issuance.
- 04
There is no rate limiting on the API by default. The proxy configs include a commented-out block for it.
- 05
The deployment is a single instance. There is no high-availability story, and no automatic failover.
- 06
The API's interactive docs are served by default. On a deployment that should not advertise them, one directive in the proxy config returns 404 for /docs, /redoc and /openapi.json.
The session.
Sign-in issues a signed, expiring token. The API re-reads the account row on every request rather than trusting the token’s claims, so deactivating an account or changing someone’s role takes effect on their very next request rather than whenever their token happens to expire.
The web client keeps that token in browser storage for now, which means a script running on the page could read it. That is a real limitation and it is on the list above rather than omitted. Moving it to an HTTP-only cookie requires the API to issue one and CSRF protection to go with it, and the client is written so that change is a small one.