Home / Security
Security & data handling
How we handle the most sensitive thing you have.
You are considering giving a vendor your source code and a set of working logins. This page describes exactly what happens to both, in plain terms, including what we have not done yet.
Your source code
Where it goes and how long it stays
With the agent: it never arrives
Run the agent inside your own network and the repository is cloned on your hardware, read there, and never transmitted to us. We receive findings, not code. That is the private option.
On a hosted scan: for one scan only
The source is cloned read-only into an ephemeral directory for the length of one scan, and the directory is wiped the moment that scan reaches a terminal state: completed, failed, cancelled, or failed to launch. Nothing is cached between runs.
Read-only, always
The clone is mounted read-only. A scan cannot modify the code it is reading, in either mode, by construction rather than by policy.
Never in a report
Evidence traces are redacted before rendering. Well-known token prefixes, JWTs and credential-shaped values are masked, including in output we captured ourselves.
The agent
Four calls out, nothing in
The agent runs on your hardware and makes exactly four outbound calls to us. It listens on nothing. There is no port to open in your firewall, no inbound rule to write, and no route from our side into your network. Every connection begins with the agent.
We port-scan the agent in our own CI on every release, so the claim is checked by a test rather than remembered by a person. If that ever finds a listening socket, the release does not go out.
Tenant isolation
Structural, not filtered
Every organisation gets its own database schema. A request is pinned to exactly one schema for its entire lifetime, and the queries the application runs cannot name another schema's tables. There is no org_id column being compared in a WHERE clause anywhere in the product, because there is nothing to compare it against.
The difference matters. With a filtering approach, one forgotten condition in one query hands another customer's findings to the wrong screen. With separate schemas the data is not reachable from that connection at all, even when the application has a bug.
A cross-tenant test runs in CI on every pull request. It tries to read one organisation's data while pinned to another, and the build fails if it ever succeeds. That is how the property above stays true as the code changes.
Platform administrators manage the tenant registry and provision schemas. They have no application route into tenant scan data.
Credentials and secrets
Encrypted, or never stored at all
AES-256-GCM at rest
Target credentials, AI provider keys, git tokens and SSO client secrets are encrypted with a key held outside the database.
Or not stored
Point an application at Azure Key Vault and its credentials are resolved at launch and never persisted here. Azure Key Vault is the only vault backend we support today.
Passwords hashed
bcrypt at cost 12 with a per-password salt. Plaintext is never stored, and a reset does not reveal the old one.
Tokens hashed
Session tokens, API tokens and agent keys are stored only as hashes. A database read does not yield a usable credential.
Masked in the interface
Secrets are write-only in the console. Once saved they cannot be read back, only replaced.
Never logged
Authorization headers, cookies and credential-shaped fields are stripped from log output before it is written.
Access control
Inside your organisation
43 permissions
Every protected action maps to a permission string enforced on the API route, and 105 routes are verified against the policy at boot, not merely hidden in the interface.
Roles, teams, groups
Grant roles directly or through team membership. Visibility can be scoped so a team sees only its own work.
Single sign-on and MFA
Okta OIDC configured per organisation, TOTP multi-factor, and scoped API tokens for machine access. Okta is the only identity provider today.
Login throttle
Exponential lockout keyed on client IP and username, across every login path including the API.
Audit log per organisation
Who ran which scan, changed which finding, edited which profile, touched which credential. All of it kept inside your own schema.
Transport
TLS everywhere, HSTS, a strict content security policy, and Secure cookies enforced in production.
What we have not done
Stated plainly
- No outside team has attacked Cyberlop itself yet
- Off-box backups, a timed restore drill and a public status page are dated 18 December
- No published uptime history until that status page exists
- No choice of data residency region
- No air-gapped install and no bring-your-own-model
We would rather you read that list now than discover it in week three. A written pack of answers to security questionnaires lands 27 October. If you can evaluate on technical merit, the architecture on this page is exactly what we would put in front of your security team. We would do it on a call, with the engineer who built it, and with the questions we cannot answer marked as such.
Reporting a problem
We will not send lawyers
If you find a vulnerability in Cyberlop itself, we want to hear about it. Our disclosure policy sets out safe harbour, scope and what to expect. Reports go to hello@cyberlop.com with “Security” in the subject line.
Put it in front of your security team.
This page is written to be read by whoever has to sign it off. Put us on a call with them and we will go through the source handling, the four outbound calls and the schema separation, and answer what is not written here.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.