Security

How saryasa protects your accounts, your code and the results it reports. To report a vulnerability, write to support@bapc.app.

Accounts

Passwords are stored only as scrypt hashes. Repeated failed sign-ins are slowed down and then locked for a while.
Two-step sign-in with an authenticator app and single-use recovery codes. Organizations can require it for every member.
Sessions are held in a secure, HTTP-only cookie and end after inactivity; every change also needs a per-session security token, which blocks cross-site request forgery.
You are told by email when a new device signs in, and can end any session from your account.

Each organization's data is separated in the database by row-level security, not only by the application.
Five roles decide who may do what, and every request is checked on the server.
Important actions are written to an audit log with who, what and when.

Protected branches take changes only through merge requests with approvals on the latest commit.
Changes written by AI always need a human approval before they can be merged.
Commits that look like they add credentials are blocked, and projects can be scanned for secrets, vulnerable dependencies, licences and sensitive data.

Jobs run in gVisor sandboxes with limits on time, CPU and memory, on a pinned commit.
Dependency downloads go through a proxy that allows only listed package registries over HTTPS and refuses private and internal addresses.
Logs are scrubbed of secrets before they are stored and again before they are shown.
Results are signed with an Ed25519 key; exported test runs include the signature and the public key to check it.