This page describes the technical and organisational measures that protect Scolah Compass Platform (“Platform”). It is the reference for the security measures annex of our Data Processing Addendum.
1. Encryption
In transit
- All traffic between agents, browsers and the Platform uses TLS. Agents validate the Platform’s certificate against the system’s trusted roots.
- Every agent request is also signed with the server’s Ed25519 key, over the method, path, timestamp and a hash of the body. A request is rejected if its timestamp is more than five minutes from the Platform’s clock.
- Installations with a public domain get HTTPS from the agent’s edge, with certificates from a public certificate authority (via ACME) or your own.
At rest — Scolah’s systems
| Data | Protection |
|---|---|
| Platform database | Encrypted at rest; replicated; automated backups kept 30 days |
| Cache | Encrypted at rest and in transit |
| Object storage | Encrypted at rest |
| Installation credentials held by the Platform | Additionally encrypted with AES-256-GCM under a master key held in a managed secret store, separate from the database |
| Portal user passwords | Held by our identity service as salted one-way hashes, never in plain text |
At rest — your servers
- Secrets are delivered sealed to one server: X25519 key agreement, HKDF-SHA256, AES-256-GCM. Only that server’s private key can open them.
- On a server, secrets are written to a file readable only by its owner (
0600), or to a Kubernetes Secret in the installation’s namespace. - Backups taken by the agent are encrypted by restic before they leave the server.
- Disk encryption on your servers is your responsibility. We recommend it.
2. Key Management
| Key | Where it is created | Where it lives | Who can use it |
|---|---|---|---|
| Server signing key (Ed25519) | On the server, at enrolment | On the server only | The agent |
| Server sealing key (X25519) | On the server, at enrolment | On the server only | The agent |
| Release signing key (Ed25519) | Scolah | Managed secret store, injected only into the Platform service | The Platform’s release process |
| Platform master key | Scolah | Managed secret store | The Platform service |
| Enrolment tokens | Platform | Stored only as a SHA-256 hash; single-use; 24-hour expiry | — |
The release public key is pinned by each agent at enrolment, and pinned separately in the operator’s configuration on Kubernetes. To replace a server’s keys, block the server, then enrol it again.
3. Scolah Staff Access
To your servers
None. Scolah staff have no shell, login, VPN or inbound network path to your servers. When we help with a problem, we use the status and progress reports the agent already sends, and anything you choose to share with us.
To the Platform
- Customer-facing roles are Organisation admin and Member. Scolah staff hold a separate platform administrator role, granted only to named employees who need it for operations or support.
- With that role, staff can see organisations, servers, installations, connections, deployment progress and usage. They can suspend an organisation, block or unblock a server, set quotas, manage registry credentials, reset a portal user’s password, and re-apply a published bundle version to repair a deployment.
- Staff actions are recorded in an audit log and kept for 365 days. Audit records are kept for the same period for actions taken by your own users, and are visible to your organisation admins in the Activity log.
- Production infrastructure access is limited to a small number of engineers, through individual accounts with multi-factor authentication.
4. Software Supply Chain
- Signed releases. Every bundle and every revision is signed. Agents and the operator refuse anything unsigned, altered, or containing unlisted files.
- Immutable versions. A published bundle version is never edited. A fix is always a new version.
- Pinned images. Bundles reference container images by fixed version or digest.
- Third-party images unmodified. We deliver upstream images as published. Where we rebuild one from source, we use the project’s own build scripts and make no code changes (Open-Source Licences).
- Minimal Scolah images. The agent and operator are built on distroless base images and run as non-root users. The Platform’s own services run as non-root, with read-only root filesystems, all Linux capabilities dropped, and the default seccomp profile.
- No silent agent updates. The agent does not update itself. You install new agent versions.
5. Application Security
- Changes to Scolah software are code-reviewed and pass automated tests and static analysis before release.
- Dependencies are tracked and updated for security fixes.
- We act on vulnerability reports as described in our Vulnerability Disclosure Policy.
6. Logging and Monitoring
- The Platform keeps an audit log of privileged actions by your users and by Scolah staff.
- Platform services and, when enabled, agents send operational logs and metrics to Scolah’s own monitoring stack, which runs in our infrastructure. Agent logs describe the agent’s work; they are not your applications’ logs.
- We monitor the Platform’s availability externally, as the basis for our SLA.
7. Resilience
- The Platform database is replicated and backed up, with 30 days of recovery history.
- Infrastructure is defined as code and deployed through a reviewed GitOps pipeline.
- A Platform outage does not stop your installations (Architecture).
8. People
- Staff with production access are bound by confidentiality obligations.
- Access is removed promptly when someone changes role or leaves.
9. Certifications
Scolah does not currently hold a third-party security certification such as ISO 27001 or SOC 2. We will answer security questionnaires and support reasonable customer audits as described in the DPA.