SECURITY
Security is a boundary, not a promise.
TraceFi uses layered controls for accounts, administration, learning progress, and Foundry execution. These controls reduce risk; they do not make the service perfectly isolated or invulnerable.
Implemented controls
- Authenticated administration: staff access is backed by Better Auth sessions, account state, roles, and server-side permission checks. Owner-only operations enforce the Owner role again at the action or repository boundary.
- Email and request controls: account email verification gates sensitive learner execution, and authentication and selected operational routes use rate limits and transactional security logging.
- Internal Runner boundary: browser requests pass through the authenticated TraceFi application. The Runner listens on an internal loopback address and requires an internal service credential.
- Restricted execution: Lab containers run with networking disabled, a read-only root filesystem, dropped capabilities, no-new-privileges, a non-root user, and CPU, memory, process, request-size, and temporary-filesystem limits.
- Protected verification: learner-visible files are separated from server-hidden verifiers and reference solutions. Submitted protected inputs are checked, and applicable completions are based on server-authoritative evidence.
- Release operations: the reviewed deployment design uses immutable release directories, an explicit rollback path, health checks, and a database backup before forward migrations.
Current limitations
- Container isolation and application authorization can contain defects or be weakened by host, dependency, or configuration failures.
- Some rate limits are process-local and are not a substitute for network-edge abuse controls.
- Operational logging helps investigation but cannot guarantee detection of every attack.
- TraceFi is an independent project, not a staffed security operations center or an audit firm.
- No vulnerability bounty or payment is promised.
Future improvements
Security work may include stronger distributed rate limiting, expanded monitoring and alerting, additional dependency and image controls, narrower service privileges, and independently reviewed operational hardening. Future work is not presented as an implemented control.
Responsible disclosure
No public security contact is configured right now. Please do not publish sensitive details; check this page again for an enabled disclosure address.
When testing or reporting, do not:
- Access another user’s data or account.
- Destroy or alter production data.
- Perform denial-of-service or resource-exhaustion testing.
- Expose credentials, verifier material, or other secrets publicly.
- Test third-party systems without their authorization.