Security
A patch tool runs as SYSTEM and root on every server. We built it like it.
Marshal opens no port on your servers and stores no password for them. Each agent dials out, proves who it is with a certificate, and can only do three things. The whole design has had a written security review, and every high-risk finding is fixed in 0.6.0.
The agent knows three verbs.
No scripts, no shell, no arbitrary commands. Even someone who took over the console could only ask for what a patch tool already does.
Ask Windows Update, apt or dnf what is missing, and report it.
Install approved updates by their ID, straight from Microsoft or the distribution. Marshal never handles update files.
Restart in the window, then check the required services came back.
Every link, and what protects it.
Outbound only, mutual TLS 1.3. The agent holds a certificate from Marshal’s own CA and pins that CA. Every request is checked against the database, so a removed server is locked out at once.
The proxy forwards blind: the agent’s TLS ends at the console, so the proxy can’t read or forge anything. Its file cache serves only files the console lists, checked by hash and signature.
Updates come from Windows Update, apt or dnf, signed by their publisher. Marshal never stores or serves update files.
The line pins the agent API’s public key, then checks the hash of the MSI or Linux build before installing it.
Through nginx with TLS and HSTS. Mandatory TOTP for local accounts or Entra ID sign-in, strict cookies, CSRF checks and a strict Content-Security-Policy.
HTTPS only. Webhooks can be signed with a timestamped HMAC, so a receiver can refuse replays.
Built in, not bolted on.
Release signing off the console
Agent and proxy builds are signed while the image is built, from a key on your build machine. It is in no image and no data folder, so a compromised console still can’t push code.
No downgrades
Signatures cover product, platform and version. Agents refuse an older build unless it was deliberately signed as a rollback.
Re-enrollment needs approval
Reinstalling on a known server sends it back to awaiting approval and raises an alert, because a reinstall can’t be told apart from someone posing as the server.
A catalogue no customer can poison
What one customer’s servers report only becomes shared once a second customer agrees. Until then, nothing they send can decline another customer’s updates.
Separated keys and roles
The internet-facing agent API has no vault key, no signing key and its own database role, which can’t read users, sessions or notification secrets.
Customers walled off
Users limited to customers can’t see others: every API answers 404 rather than reveal they exist. Every change lands in the audit log.
Locked-down agent files
State and certificates live in folders only SYSTEM and Administrators, or root, can read. The agent refuses to start if the permissions are wrong.
Encrypted backups
Nightly database dumps are encrypted with age. The keys folder is kept out of them on purpose.
Pinned supply chain
Python packages install with required hashes, base images are pinned by digest, and one script audits all three ecosystems.
Your part, when you deploy
- Put the web UI behind nginx with TLS, and only on your admin network
- Expose only the agent port to servers, and pass its TLS through untouched
- Back up the keys folder and the signing key offline, apart from the database dumps
- Set allowed networks on every proxy
- Keep install links short-lived, and auto-approve only for test rings
- Use Entra ID with Conditional Access for admins; keep local accounts for break-glass
Still open, said plainly
- Authenticode signingThe build signs the exe and MSI as soon as a code-signing certificate is supplied. Marshal’s own release signatures protect updates today.
- Separate issuing CAsPlanned for the next CA rotation.
- SBOMA software bill of materials for each release is still to come.
Found something? Tell us first.
We answer security reports directly and credit the people who send them.