This page summarises the threat model for Scolah Compass Platform (“Platform”). It is meant to help your security team decide whether the Platform fits your risk appetite, and which controls you need to add yourself. Read it alongside Architecture & Data Flow.
1. What We Protect
| Asset | Where it lives | Why it matters |
|---|---|---|
| Your applications’ data | Your servers | Often personal data about vulnerable people |
| Installation credentials (database, admin and encryption keys) | Your servers, plus an encrypted copy held by the Platform | They unlock the data above |
| The release signing key | Scolah’s secret store | Whoever holds it can produce software that agents will accept |
| Server identity keys | Each server, generated locally | They let a server act as itself towards the Platform |
| Integrity of what runs on your servers | Your servers | Tampered software could leak or alter data |
| Portal accounts | Scolah’s identity service | They can change what runs on your servers |
2. Trust Boundaries
- Between your infrastructure and the internet. The agent connects only outbound. No inbound port is needed unless you publish an installation on a domain.
- Between the agent and the Platform. Each side authenticates the other: requests from the agent are signed with the server’s key, and what the Platform sends is verified against the pinned release key.
- Between installations on the same server or cluster. Each installation has its own credentials and, on Kubernetes, its own namespace with default-deny ingress.
- Between Scolah staff and customer organisations. Staff access to the Platform is role-restricted and audit-logged. Staff have no access to your servers.
3. Threats and Controls
| Threat | Controls |
|---|---|
| Someone on the internet attacks your servers through the Platform | The Platform cannot open connections into your network; the agent only polls out. Connecting a server needs no inbound port. |
| Tampered software or bundle — in transit, in a registry, or in storage | Every bundle and revision is signed with Ed25519. The agent checks the signature and the SHA-256 of every file, and refuses unlisted files. On Kubernetes, the operator re-verifies with a key pinned from its own configuration, so a compromised agent cannot make it apply unsigned software. Published versions are immutable. Images are pinned in the signed bundle. |
| Bundle tries to take over a Kubernetes cluster | The operator applies only a closed set of namespaced object kinds. Bundles cannot create cluster roles, webhooks or custom resource definitions. |
| Bundle executes arbitrary commands via the agent | Bundles describe what to run; they cannot carry scripts for the agent to execute. Setup actions, such as creating a read-only database user, are built into the agent and operator. |
| A stolen enrolment token | Tokens are single-use, expire after 24 hours, and are stored only as a hash. |
| An attacker impersonates a server | Each server signs every request with a private key that never leaves it. A blocked server is refused immediately. |
| Secrets intercepted on the way to a server | Secrets are sealed (X25519, HKDF-SHA256, AES-256-GCM) to the destination server’s key, inside TLS. They are written readable only by the installation. |
| One installation reads another’s data | Connections between installations use a separate, read-only account per connection, which excludes tables holding passwords, tokens and keys. It is deleted when the connection is removed. |
| A portal account is compromised | Two-factor authentication is available for every user. Members cannot add servers, create or delete installations, or manage users. Every privileged action is recorded in the organisation’s activity log. |
| Data loss on your server | Optional encrypted backups to an object store you control, with restore verification and drills. |
| A bad upgrade | A read-only precheck runs before changes. Upgrades need user confirmation. A failed upgrade reverts to the previous revision. |
| The Platform is unavailable | Installations keep running. Only management actions pause. |
4. Residual Risks
These risks are not fully removed by the Platform’s design. We state them so that you can decide how to handle them.
4.1 Compromise of Scolah’s control plane
The Platform holds an encrypted copy of every installation’s credentials, and can direct agents to deploy software signed with the release key. An attacker who fully compromised the control plane, including its secret store, could therefore try to deploy signed but malicious software to connected servers. They would still have no network path into your servers.
How we reduce it: a hardened, access-restricted production environment; secrets encrypted with keys held apart from the database; signing keys held in a managed secret store; staff access limited and logged (Security Practices).
What you can do: block a server in the portal, or stop its agent, to stop it acting on new instructions immediately; running installations are not affected. Restrict the agent host’s outbound access to the Platform and the registries you use. Rotate installation credentials if you end your subscription.
4.2 Administrative access to your infrastructure
Anyone with root on a server, or cluster-admin on a cluster, can read every installation’s data and secrets on it. The Platform cannot protect against that.
What you can do: limit and audit administrative access, keep the operating system patched, and encrypt disks.
4.3 Shared Kubernetes clusters
To manage installations, the agent and operator need broad permissions across the cluster, including reading and writing Secrets.
What you can do: run Platform installations on a dedicated cluster, not alongside unrelated workloads.
4.4 Unrestricted outbound traffic from installations
Installations can make outbound connections by default, because many applications need to.
What you can do: add an egress NetworkPolicy or firewall rules that allow only the destinations each application needs.
4.5 Vulnerabilities in third-party applications
Catalog applications are maintained by their upstream projects. We publish tested bundles for upstream security releases (SLA), but a vulnerability may exist before a fix is available.
What you can do: apply security upgrades promptly, and expose only the installations that need to be public.
4.6 Optional integrations
Integrations you enable, such as Scolah-managed AI, send data off your servers. See Data Residency.
5. Review
We review this threat model when the architecture changes, and at least once a year. Questions or disagreements: security@scolah.com.