Security
Last updated: 2026-09-14
Our commitments
TestifySec is a small operating team, and the security program is written down rather than implied. Every policy lives in the same repository as the product, changes by pull request, and is reapproved at least once a year. What follows describes what runs today. Where a control is incomplete, this page says so instead of rounding it up.
- Customer data is encrypted in transit and at rest.
- Production access is limited to named operators using multi-factor authentication.
- Platform activity is logged, and the audit record is retained.
- A reported security issue gets a first response within one business day.
How we protect data
Encryption
- In transit: TLS 1.2 minimum, TLS 1.3 preferred, with ECDHE key exchange over P-256 or X25519.
- At rest: AES-256-GCM for databases, blob storage, and backups, under AWS KMS customer-managed keys with HSM backing.
- Signing: ECDSA P-256 for attestations and internal service tokens. DES, 3DES, RC4, MD5, and SHA-1 for new signatures are prohibited.
Access control
- Production is reachable only through AWS and GitHub, both with federated identity and MFA. TestifySec runs no corporate VPN and no internal network perimeter, so a valid cloud credential with MFA is the only way in.
- Platform accounts authenticate through Ory Kratos: TOTP and WebAuthn, a 12-character password minimum, and a check against known breached passwords. Customers who federate to their own identity provider inherit that provider's MFA policy.
- Every record that holds customer data carries a mandatory tenant key, and access is filtered at the data layer on every query and mutation by fail-closed privacy rules rather than by a filter someone remembered to add. Access is downward-only: a team cannot reach its parent or its siblings.
Logging
- Application logs are structured JSON, retained 30 days.
- The platform audit log is retained one year in PostgreSQL and backed up to S3 for seven years.
- AWS CloudTrail is retained 90 days hot, then archived to Glacier for seven years.
- Amazon GuardDuty analyzes Kubernetes audit events, CloudTrail, VPC flow logs, DNS queries, S3 data events, and database login attempts.
Backups
On 2026-08-09 we restored the production database from a point-in-time snapshot onto an instance of identical class and engine. It reached a query-serving state in 10 minutes 36 seconds, with a recovery point of 5 minutes 4 seconds and 743 of 743 foreign-key constraints validated. That test measured the database restore, not the application cutover onto a restored database, which remains untested and is the objective of the next drill. TestifySec keeps no off-region copy of production data today, and that gap is carried in our risk register.
Secure development
We build the platform on the same evidence pipeline we sell.
- Every change reaches the main branch through a pull request. Force-push to main is disabled, and branch protection is enforced at the organization level.
- Each pull request needs a human approval, and an automated reviewer runs alongside it. Security-relevant changes need the technical security lead's approval.
- Pushes through Pushgate carry a signed push certificate, and builds emit in-toto attestations signed against our own certificate authority, timestamp authority, and transparency log. Public Sigstore infrastructure is not used.
- Unit tests, integration tests against a real database, and browser acceptance tests run on every pull request, with the Go race detector enabled.
- A scheduled weekly sweep runs
govulncheckacross our Go modules and opens a tracking issue for each advisory it finds. Dependabot proposes dependency updates on a schedule. - Container images are scanned for critical and high-severity vulnerabilities when a change enters the merge queue. That scan reports findings to the author today; it does not yet fail the build.
- GitHub secret scanning with push protection rejects a push that contains a recognized credential.
Compliance program
TestifySec is pursuing a SOC 2 Type II examination, using Secureframe as the compliance platform of record, against the Security, Availability, and Confidentiality Trust Services Criteria. This is readiness work. We are not certified, we hold no auditor's opinion, and nothing on this page is an attestation. Processing Integrity and Privacy are out of scope and are not claimed. We track the same estate against CIS Critical Security Controls v8, Implementation Group 1.
Our internal mapping records, for every criterion, which policy covers it and whether that coverage is complete, partial, or absent. Customers and prospective customers can request the policy package and the current mapping from their TestifySec contact.
Report a vulnerability
Email [email protected], open a private advisory from the Security tab of github.com/testifysec/judge, or use the vulnerability report form. On-premises customers can also use their shared Slack channel. Our RFC 9116 contact file is published at /.well-known/security.txt.
- First response: one business day for every severity, measured from when we are made aware. Business hours are Monday to Friday, 9:00 AM to 6:00 PM U.S. Eastern, excluding U.S. federal holidays. This is a first-response commitment, not a resolution time.
- Fix shipped, measured from confirmation: 7 days for Critical, 30 days for High, 90 days for Medium, and best effort for Low. Severity follows CVSS v3.1, adjusted for how exploitable the issue is in our own deployment.
- Affected customers are notified within one business day of confirmation, before public disclosure.
Subprocessors
TestifySec has not yet published a subprocessor list. Customers and prospective customers can request the current list by email at [email protected]. Any vendor that receives Confidential or Restricted customer data is covered by a data processing agreement, and customers are notified when customer data goes to a new subprocessor.
Related pages
- Privacy Policy — what we collect and how we handle it.
- Trust architecture and PKI — how signing keys, certificates, and rotation work in the platform.
- Security coverage — which threats Pushgate addresses, and which it does not.