Security

Sandboxing

Each engagement runs its tools inside a container sandbox. Hosted sandboxes each get their own Docker network with no route to the database, and the scan worker that creates them is the only service with access to the Docker socket. Under a proxy_only execution profile, an egress gateway with host and port allow-lists is the sandbox's only exit.

The security model in the docs has the detail.

Approvals

Consequential work waits for a person. A retest needs a second reviewer who did not propose it, a response action waits for an approver who is recorded, and a fix arrives as a pull request your team reviews and merges. Platform scans run under an engagement and a signed execution profile.

Encryption

Integration credentials and OAuth tokens are encrypted with a keyring the deployment supplies, and credential operations fail closed without it. Jobs carry references to secrets rather than the secrets themselves. Caddy terminates TLS and is the only published service.

Workspace isolation

Every stored record carries its owner and workspace, and the boundary is enforced in repository queries, not only in the interface. Roles are checked on the server: Viewers read, Analysts and Security leads run security workflows, and Owners and Admins manage members, settings and integrations.

Where it runs

The hosted workspace runs in Google Cloud's europe-west9 region in Paris. Rokkhe can also be self-hosted on infrastructure you operate.

What runs where, and what leaves your network covers a self-hosted deployment. The privacy policy lists the processors behind the hosted service.

Certifications

Rokkhe does not hold a SOC 2 report or an ISO 27001 certification today, and makes no other compliance claim. Buying a plan does not make a deployment compliant: that depends on the defined system, its controls, operating evidence and an independent audit.

Reporting a vulnerability

Report security issues in the rokkhe CLI, the hosted service at rokkhe.com or a self-hosted build to [email protected], in English or French, with the product and version, the steps to reproduce and the impact you saw. The same contact is published in security.txt.

Rokkhe acknowledges every report, keeps you informed until it is resolved, and publishes an advisory once a fix is available, crediting you unless you would rather not be named. A vulnerability that is being actively exploited is also reported to CERT-FR and ENISA, as the EU Cyber Resilience Act requires.

Testing rules

Test only accounts and workspaces you own or have permission to test. Do not access, change or keep other people's data; if you reach any, stop and tell us. No denial of service, social engineering or physical attacks. Give us 90 days, or until a fix ships if that is sooner, before you disclose publicly.

If you act in good faith and within these rules, Rokkhe treats your research as authorised and will not take legal action against you for it. This covers Rokkhe's own systems, not anyone else's.

Out of scope: findings in systems you assessed with Rokkhe, which belong to those systems' owners; scanner output without demonstrated impact; and missing headers on pages with no sensitive function.

Security advisories

Rokkhe has not published a security advisory. Advisories will appear here with the affected products and versions, the severity, the fixed version and how to update.

Contact

For questions about Rokkhe or this page, email [email protected].