What stops it is a signature check on the client, made against a key the server never held. If the update server can sign its own files, a break in gives the attacker every install. If the signing key lives somewhere else, the server can serve a bad file but the app should refuse it.
Three layers, three questions
| Layer | Question it answers | Example from the docs |
|---|---|---|
| Archive signature | Is this file the one the key holder signed? | Sparkle EdDSA signatures on archives |
| OS code signing | Does the platform trust the publisher? | Squirrel.Mac needs a signed app for autoUpdater, per the Electron docs |
| Signed metadata | Is this the newest, unexpired, right set of files? | TUF metadata with hashes, versions and expiry |
None of these is magic on its own. Together they narrow what an attacker with server access can do.
What the server can still do
Even with signatures, a compromised server can try to:
- Withhold new releases, so users never learn an update exists. TUF describes this as a freeze: the attacker keeps serving the same file.
- Serve an older, vulnerable but validly signed version, which TUF describes as a rollback.
- Change unsigned parts of the feed, such as release notes, unless the feed is signed too.
Version numbers and expiry dates in signed metadata are how an update system defends against the last two.
Where the key must not be
The Sparkle documentation says to keep signing keys off the machine that hosts your product, so a compromised web server cannot expose them. Electron's updating guide lists update sources that put different parties in your delivery path, from a static storage location to a custom server. Whoever can write to that location can replace files, so the signature is the control that matters.
A response checklist
- Take the update endpoint offline or pin it to a known good release.
- Check the signatures on every file currently served against your key.
- Confirm the signing key was never on the server. If it was, treat it as stolen.
- Review feed and notes for edits.
- Tell users which versions are safe, through a channel the server does not control.
Try it yourself
The demo walks through a continuous check on shipped software. Click through and consider how a regular verification of what your server serves would catch a swapped file.
Click through it at your own pace, or open it full screen.
Quick check
Does HTTPS alone protect an update channel?
No. HTTPS protects the connection to a server, not the server itself. If the server is compromised, it serves bad files over a clean connection. The signature check is what catches that.
Is a valid signature proof the update is safe?
It proves who signed it, not that the build was clean. A compromised build step can sign a bad file with a good key.
Safeguard's policies, gates and SBOM scanning help check what goes into a release before it is signed. A free scan is at gold.safeguard.sh/scan.
Sources
- Sparkle documentation
- Electron updating applications
- Electron code signing
- The Update Framework overview
Last reviewed: 19 October 2026.
