Data and security
This page answers the questions a security review or vendor questionnaire asks about MopokeHQ. For the legal terms, see the privacy policy and terms of service.
Where your data is stored
Section titled “Where your data is stored”Everything MopokeHQ stores for an organisation is held in one region: accounts and memberships, SBOMs, scanner findings, deploy reports, external scan results, the evidence log, evidence packs, and code review diffs while they wait for review.
| Region today | Sydney, Australia |
| Storage | A managed PostgreSQL database in DigitalOcean’s Sydney region, encrypted at rest |
| Package proxy | Runs in the same region. It caches public packages only, never your private ones. |
| Regions per organisation | One. All of an organisation’s data stays in its region. |
We are opening more regions. If you need your data held somewhere else, tell us where. We will not move an organisation’s storage region without its agreement.
What leaves your data region
Section titled “What leaves your data region”Stored data stays in your region. Some processing and delivery happens outside it:
| What | When | What is sent |
|---|---|---|
| Lilly: alert notes, suggestions, Ask Lilly, client notice paragraphs | While AI is on for the organisation (it is on by default) | Minimal facts: the public advisory, package names and versions, environment names and confidence. Never source code, secret values, or repository, project, client or people’s names. |
| Code review | Only while AI is on and the project has code review on | The merge request’s diff, with files that hold secrets left out and anything that looks like a credential redacted. No repository, project or customer names. |
| Network traffic | Always | Requests to app.mopokehq.com and registry.mopokehq.com pass through Cloudflare for DNS and network protection. |
| Always | Alerts, digests and client notices are delivered through Cloudflare’s email service. |
AI requests go to model providers that run with zero data retention: they keep nothing after answering. They are outside Australia, in the United States or other countries.
DigitalOcean is a US company. Its support access to data hosted in Sydney is governed by its data processing agreement.
The full list of sub-processors, where each is located and the transfer safeguards in place are in the privacy policy. Customers get at least 30 days’ notice of a new sub-processor that handles their data.
The AI off switch
Section titled “The AI off switch”Each organisation has one switch: AI settings, Lilly notes, suggestions, Ask Lilly and AI code review. Owners and admins change it, and every change is recorded in the evidence log with who made it.
With AI off, nothing about your organisation is sent to an AI provider:
- no alert or secret notes, and no “not affected” suggestions,
- no Ask Lilly,
- no code review on any project, whatever its owner chose,
- client notices use the plain template.
Alerts, escalations, digests, priorities and deadlines work exactly the same, because none of them use AI.
Code review is also a per-project choice. Client projects start with it off; turning it on needs the project owner, an owner or an admin to confirm the client’s contract allows code diffs to be sent, and that confirmation is logged. Internal projects start with it on, so switch it off on the Projects page if your policy needs that. Diffs are deleted as soon as the review is done, and within a day if a review never runs.
How MopokeHQ connects to your systems
Section titled “How MopokeHQ connects to your systems”Nothing connects into your network. The mopoke CLI runs in your own CI, on your runners, from the public scanner image gitlab.boosoft.com.au:5050/mopokehq/scanner:1, which pulls without a login. It scans there and pushes the results out over HTTPS with a token you control. A self-managed GitLab, Gitea or Forgejo behind a firewall works as is.
What the CLI uploads. The SBOM (package names and versions) and the scanners’ findings, cut down to a small subset: rule, file, line and severity, with no code snippets, code flows or surrounding source. A secret’s value is read on the runner to label it and is never kept or sent. Source code never leaves your runner, except merge request diffs for code review on projects that turn it on.
Fix merge requests come from the scheduled mopoke act job in your own pipeline, which collects the work queued for it. In the default setup MopokeHQ stores no Git platform credentials.
The only connections MopokeHQ itself starts toward your systems are ones you set up:
| Connection | To | Set up by |
|---|---|---|
| External scanning | The public sites you add as targets, from 115.186.255.201 |
Adding a target |
| Webhooks | The HTTPS endpoints you add | Adding an endpoint |
| Package proxy private scopes | Your package registry, with a read-only deploy token | Adding a private scope |
GitLab deployment webhooks, if you use them, are sent by your GitLab to MopokeHQ, so they need outbound HTTPS from your GitLab. Where that is not allowed, the mopoke deploy CI step reports deployments instead.
How your data is protected
Section titled “How your data is protected”- Isolation between organisations. Every organisation’s rows carry its organisation, and PostgreSQL row-level security enforces it on every query, not only in application code. Tests check that one organisation cannot read another’s data.
- Encryption. In transit over HTTPS. At rest in the managed database.
- A key per organisation. Secrets you give MopokeHQ, such as webhook signing secrets and registry deploy tokens, are also sealed with a data key unique to your organisation.
- Hashes, not credentials. Sign-in sessions, CI tokens, runtime tokens, API keys, proxy keys and invite codes are stored only as hashes. Each is shown once, when it is made.
- Narrow tokens. A runtime check-in token can only report runtimes, so a leaked one can raise false alarms but never hide a real one or close anything (see Priorities).
- Roles and teams. Owners, admins, members and read-only Viewers, with teams to limit who sees which projects, and a quarterly access review.
- An append-only evidence log. Hash-chained, so any change to a past record shows (see Evidence).
- Sign-in is through BooAuth, BOO Soft’s identity service.
Retention and deletion
Section titled “Retention and deletion”- Your data is kept while your organisation is active. You can export evidence packs and the evidence log at any time.
- When an owner closes the organisation, members can still sign in and export for 30 days, and an owner can cancel the closure.
- After that, MopokeHQ deletes the organisation’s data and destroys its data key, so secrets sealed with it cannot be read, including in backups. Database backups that still hold deleted data expire in the ordinary course.
- The evidence log cannot be edited or deleted record by record (that would break the chain), so erasure requests are met by deleting the organisation’s data as a whole.
Certification
Section titled “Certification”MopokeHQ does not hold ISO 27001 or SOC 2 certification. Its evidence packs help you show your own controls to your auditor; they do not certify MopokeHQ or you.
Report a security problem
Section titled “Report a security problem”Found a vulnerability in MopokeHQ? Email [email protected] with the details.