Security and trust
The short version: Groundskeeper runs on your own Windows server and only reads from your systems; it never changes them. A small, listed set of things leaves your network, each for a stated reason. Releases are code-signed and the server checks the signature before it installs an update. RSJ Software is one person, and Groundskeeper has not had an independent penetration test or a security certification. This page sets out what is done, how it is checked, and what is not done yet.
Who builds it, and how
RSJ Software Ltd is a one-person company. Groundskeeper is written with AI coding tools, under rules that are enforced by the tools rather than left to good intentions:
- Tests before publishing. A suite of automated tests and code checks must pass before any change is published. It includes checks aimed at whole classes of mistake: user data put into PowerShell scripts, pages that do not escape what they display, and a connector that reports “all fine” when it could not actually read anything.
- Independent review before publishing. Every code change is read by a second AI model that did not write it. Changes to sign-in, licences, installing and updating, and the agent on your PCs are also read by a model from a different company. A check on the code repository refuses to publish code that has not been reviewed.
- Real installs before release. Each build is installed on a small test network (Windows Server 2022 virtual machines in an Active Directory domain, with test PCs) and checked: a clean install and upgrades from earlier versions, the service and its account, and the logs.
- Antivirus scans. Every public release is scanned with VirusTotal, and the result is linked from the release notes.
None of this replaces an independent security test. It is what one person can do, done every time.
What runs where
- The Groundskeeper server runs on a Windows server you choose, as a Windows service. It serves its web pages over HTTPS on port 8443. It creates its own certificate by default, and you can use your school’s own certificate instead. It will not start without HTTPS unless an administrator deliberately turns HTTPS off, for example behind a reverse proxy.
- Its data (the SQLite database, settings and logs) stays on that server, in a folder that only SYSTEM, Administrators and the Groundskeeper service account can open.
- The RSJ Agent is optional. It runs on PCs and servers you choose and reports their health to your Groundskeeper server, never to us.
Read-only by design
Groundskeeper observes; it does not act. Its connectors only read from Microsoft 365, your firewall, switches, backups and the rest, and they are built and reviewed on that rule. To be precise, this is a design rule that every change is reviewed against. Nothing in the software technically stops a connector from writing. We recommend giving Groundskeeper read-only accounts and API keys wherever your systems offer them. Then the guarantee does not rest on our code.
What leaves your network, and why
| What | When | What is sent |
|---|---|---|
Licence check to api.rsjsoftware.com | Once a day, and when the service starts. On by default, including on the free Community edition. | The licence key, the Groundskeeper version, a random install ID, the school’s details as set in Settings (name, URN, postcode, local authority, phase, type, trust, and the colour chosen for the interface — all public information) and the names of the connectors that are switched on. It sends no settings, passwords, device names, users or alerts. A paid licence keeps working for 7 days if the check cannot get through. |
| Update check to GitHub | Hourly, daily or weekly (your choice). | A request for the latest release. It sends nothing about your school; GitHub sees your server’s internet address. |
Software advisory list from groundskeeper.rsjsoftware.com | When newer lists are published. On by default; can be switched off in Settings. | A plain download of a public file, with no identifier. The list must carry a valid digital signature from RSJ, and an older list is never accepted in place of a newer one. |
| Community key request | Only when you ask for a key. | The contact details you type in and the school’s identity. |
| Cloud AI (OpenAI, Claude, Gemini, Azure) | Only if you choose a cloud AI provider. The default is Ollama, which runs on your own server. | Summaries of recent alerts. Before anything is sent, email addresses, internet and network addresses, user and computer names in the usual forms are removed. Treat this as reducing the risk, not removing it: a name typed into free text can still go out. |
| Email and chat alerts | Only if you set them up. | Alerts, to the mail server or webhook you configure. |
| Early-test reports to RSJ | Only on the Alpha (pre-release) update channel, which schools are not on by default. | “Report to RSJ” and page-error reports, and (only if you tick it) the day’s log with names replaced by codes that cannot be reversed without a key that stays on your server. |
The connectors talk to the services you connect them to (your Microsoft 365 tenant, your Meraki dashboard and so on), using the credentials you give them. That traffic goes to those services, not to us.
Installers and updates
- The installers and the programs inside them are code-signed by RSJ Software Ltd (Microsoft’s Azure Artifact Signing).
- Python packages are installed into the build only from a list that fixes each package’s version and its SHA-256 checksum. A new package needs a deliberate decision and a check on who publishes it.
- Automatic installation of updates is off by default. When an update is installed, the server checks the download’s SHA-256 checksum. A separate task, running as SYSTEM, copies the installer to a folder the service cannot write to. That task checks that Windows considers the signature valid and that the signer is RSJ Software Ltd. If either check fails, it does not run the installer.
- The RSJ Agent refuses to install an update or a module that RSJ Software Ltd did not sign. An administrator on that PC can deliberately switch this off, for testing. The agent logs a warning each time.
Signing in, and protecting what is stored
- Each person has their own account with a role: administrator, technician, or senior leadership (a summary view only).
- Passwords are stored as PBKDF2-SHA256 hashes (600,000 rounds, with a salt for each password).
- Two-factor sign-in with an authenticator app is available for every account. Recovery codes are stored only as hashes. It is per person: an administrator cannot yet make it compulsory.
- After five wrong passwords from one address, that address is blocked for a minute. The count is not kept across a restart, and it is per address, not per account.
- Session cookies are HttpOnly, SameSite and, over HTTPS, Secure. Requests that change something are refused if they come from another website.
- Passwords and API keys in Groundskeeper’s settings are encrypted with Windows DPAPI, tied to that server. Anyone with administrator access to the server itself can still decrypt them, so protect that server like the systems it reads from.
The agent on your PCs
- PCs talk to your server only over HTTPS and check the server’s certificate. Either they match it against a fingerprint given at install, or they accept only a certificate Windows already trusts. If neither was set, the first certificate seen is recorded. After that, a different certificate is refused, never silently accepted.
- PCs prove themselves to the server with one secret shared by all of them, which you can change. There is not yet a separate key for each PC.
What we have not done yet
- No independent penetration test or code audit.
- No security certification (such as ISO 27001 or SOC 2).
- The update check and the daily licence check cannot be switched off in Settings. Very restricted networks can turn the licence check off with an environment variable on the server (
GK_NO_CALL_HOME); a paid licence then falls back to Community after 7 days. - No Content-Security-Policy on Groundskeeper’s own pages yet. We deliberately do not send HSTS (strict HTTPS) either, because on a school network it makes a certificate mistake harder to recover from.
- Two-factor sign-in cannot be made compulsory, and the sign-in lockout is per address, as above.
Reporting a security problem
Please email security@rsjsoftware.com rather than posting publicly. Our security policy sets out what to include, how quickly we respond, and our target times for fixes by severity. We do not take legal action against good-faith research. There is no paid bug bounty, but we credit reporters who would like it.