Why CAIQ-Lite, not SIG Lite
We organised this by the Cloud Security Alliance's framework (CAIQ-Lite) rather than Shared Assessments' SIG Lite because: answering in our own words under the CSA's domain names needs no licence agreement (SIG Lite is licensed content from Shared Assessments, and the actual CAIQ-Lite spreadsheet is itself free to download from CSA); it is scoped to cloud services specifically, which matches what we are (a handful of Cloudflare Workers, D1 databases and R2 buckets, not a general enterprise IT estate SIG Lite's broader scope is built for); and it is the form we expect the studios and publishers who review us first to ask for. We'll answer a SIG Lite, or a specific enterprise's own questionnaire, on request if a customer's procurement process requires it.
Toward a STAR Level 1 listing (owner decision O7, D143)
The owner has decided to list Mulno on the CSA's STAR Registry at Level 1 (a free self-assessment, not audited) before the first enterprise security review. Not done yet — this page is our own narrative answer, not that submission. What it takes, so the reviewer or the owner can track it:
- Create a free STAR submission account (an existing Google, Microsoft or LinkedIn sign-in works, or email and password) at the CSA's STAR portal.
- Fill in the CSA's own CAIQ v4 or CAIQ-Lite questionnaire — the real one, its own question text, CSA's own downloadable spreadsheet (not this page's prose, which is only our source material for it).
- Submit it through the portal's "Manage Assessments" / import flow.
- CSA typically publishes it within 1 business day (up to 5 for a manual review); the listing is valid for a year, after which it needs re-submitting.
No fee applies at Level 1. This is tracked as an owner to-do, not yet started.
Audit and Assurance
Every review (broker, api, signer, OAuth) is a written report with severity-rated findings, proof tests, and a re-check after the fix (docs/security/*.md). No outside penetration test or SOC 2/ISO 27001 audit yet (D113) — see security.md for when that starts.
Application and Interface Security
Every request body is checked field by field before use; every database statement is parameterised (a source check fails the build on SQL assembled from a value); the api's and the broker's routes are exercised by automated tests including deliberate misuse — forged tokens and cross-workspace attempts, and randomised (fuzz) input for the broker. A dedicated signer origin, with its own strict Content-Security-Policy proven by an automated XSS test, keeps a bucket-reading credential out of the page that renders untrusted, tester-typed text (see security.md). The web app at app.mulno.com is served with its own Content-Security-Policy (PLAN D110): never 'unsafe-inline' for scripts, no framing, and a bucket host named only for a live member of that project.
Business Continuity Management and Operational Resilience
Our databases (Cloudflare D1) keep a point-in-time copy for 30 days, from which a database can be restored; object storage (R2) is Cloudflare's, with its own durability. We have no written, tested continuity or disaster-recovery plan yet, and no stated recovery-time objective; a Private-bucket studio's recordings never depend on our availability, only its remote playtests' invite codes, upload authorisations and launcher build downloads do. Workers KV (remote MCP connections) has no point-in-time copy: losing it means clients sign in again.
Change Control and Configuration Management
Every change is a small, reviewed commit on its own branch, merged into an integration branch and then main; nothing is pushed straight to a production branch. Continuous integration (GitHub Actions) runs source-pattern checks (no dynamic SQL, one logger, no secret in a committed config file), a typecheck, an automated test suite against a local Cloudflare Workers/D1 simulator, and a wrangler deploy dry-run that validates configuration without touching any account, on every change to the api or the broker — before a production deploy is even considered. The remote-MCP Worker and the lent-key signer have the same checks and tests, but no CI workflow runs them yet (they run on each merge by hand) — an open item. A production deploy itself is made only by the owner, or by an AI agent after the owner's explicit confirmation of that specific change in chat (root CLAUDE.md's Cloudflare rule); no account id, resource id, token or key is ever committed to source control.
Cryptography, Encryption and Key Management
TLS on every connection to our servers. Bucket credentials (and a workspace's broker token) are encrypted (AES-256-GCM) with keys held outside the database as Cloudflare Worker secrets, never in application code, in a committed file, or in logs. The broker's key rotates without downtime; the api's and the lent-key signer's keys don't yet (after a change, the affected credentials are entered again) — an open item. A campaign's in-game configuration (consent text, surveys) is encrypted before it reaches us, with a key our servers don't hold. An NDA a studio sets for the launcher to show before download is stored as readable text, because the launcher must display it.
Datacenter Security
We operate no datacenter of our own — every production component is a Cloudflare Worker, D1 database or R2 bucket, so Cloudflare's own datacenter security applies (it publishes its own compliance: ISO 27001, SOC 2, PCI DSS).
Data Security and Privacy Lifecycle Management
Personal data is minimised by design: a Private project's bucket is never read by our servers unless a lent key is explicitly turned on; the broker holds no tester name, e-mail or IP address in readable form. See what we store, retention and, for people who deal with Mulno directly rather than through a studio, our own privacy notice for exactly what is held, where, and for how long.
Governance, Risk Management and Compliance
A small team (mostly AI-written code, human-reviewed decisions — PLAN D46) with one owner who signs off every production deploy and every priced or billable change. No dedicated security team; every security review to date is done by an AI review agent at the highest reasoning effort (D122), not an outside firm, with findings tracked to a fix and a re-check before anything they gate ships.
Human Resources
A small, named team; access to Mulno's Cloudflare account is limited to named people (the owner today), with production changes made by the owner or by an AI agent only after the owner's explicit confirmation in chat for that specific change.
Identity and Access Management
Studios and workspace members authenticate with a pre-issued token (M2 studios), a signed-in session from a magic link (M3 workspaces, no passwords to leak), or — for a remote MCP client (Claude Code, claude.ai, ChatGPT) — an OAuth 2.1 grant scoped to one workspace, chosen projects and named scopes (sessions:read, notes:write, media:read), lasting at most 30 days (the client can revoke it; Mulno has no screen to list or revoke grants yet — an open item). Every route that reads or changes anyone's data requires a credential; the open ones are the health check, sign-in itself, joining the beta waitlist, the entitlement public keys, Paddle's signed webhook and the few public pages security.md lists. Every workspace- or studio-scoped query is scoped to that credential (tested on every route). The beta waitlist's own page in the web app opens only for the accounts named in our server configuration (the owner's, today). Removing a workspace member takes effect on their very next request to the api, and within about a minute for a remote MCP call (membership is cached up to 60 seconds); a Studio licence already issued stays valid offline for up to 30 days, but reaches no data on its own.
Interoperability and Portability
Our export paths (JSON Lines audit exports, a session's own open file format) are documented in what we store and the product's own specs (spec/session-format-v1.md).
Infrastructure Security
We run no servers of our own: every production component is a Cloudflare Worker, D1 database or R2 bucket — Cloudflare's own infrastructure security applies (see its own published compliance: ISO 27001, SOC 2, PCI DSS). We hold no account id, resource id or secret in source control; a production deploy is confirmed by the owner in chat before it runs.
Logging and Monitoring
Two kinds of log, kept separately and for different reasons. Our request logs — one structured line per request (route, status, account id, a keyed hash of the IP address, never a body or a token), stored in Cloudflare Workers Logs with Cloudflare's own metadata (including the request's full URL) — are kept 7 days; the owner reads them to operate the service and to watch for events such as the first EU or UK workspace (PLAN D136). Our own workspace audit log (D114) is an application-level record — sign-ins, membership and role changes, storage and lent-key changes, and every read our own servers make of a Private project's recordings under a lent key — kept 1 year (or the workspace's plan's own retention if longer) and exportable by an admin as JSON Lines. We have no dedicated monitoring dashboard, alerting rules or SIEM beyond Cloudflare's own — an open item, not yet built.
Security Incident Management, E-Discovery and Cloud Forensics
If we learn of a breach affecting your data, we tell you within 48 hours (D137), with what we then know: the nature of the breach, roughly how many records and of what kind, what we're doing about it, and a contact for more. We have no written incident-response runbook or e-discovery / forensics process yet — an open item; today's practice is the owner and the AI review agent investigating directly from Cloudflare's own logs and our own audit log.
Supply Chain Management, Transparency and Accountability
See the subprocessor list for exactly who touches what, and 30 days' notice before that list changes. We name every third party our own servers call — we don't have any we haven't disclosed.
Threat and Vulnerability Management
Every route is reviewed as part of each security review round; findings are tracked by severity with a proof test that flips from failing to passing once fixed, so a fix can't silently regress. See docs/security/ for the review history. Dependencies are kept few — the api, broker, signer and lent-key signer have no runtime dependencies at all; the remote-MCP Worker has two, pinned to exact versions — and locked by a lockfile. No automated dependency-vulnerability scanning runs yet, and no review so far has audited third-party dependencies — an open item.
Universal Endpoint Management
We ship no mobile app and manage no fleet of endpoints — the only endpoints with any bearing on this product are the owner's own computers, from which production changes are made. Every account that can reach production (Cloudflare, the mailbox that receives its password resets, Paddle, the source repository and the domain registrar) uses multi-factor sign-in. Disk encryption and a screen lock on those computers are not on yet — an open item for the owner before a STAR submission or a customer's own review asks for it.