It depends on how well you can verify and roll back releases. Auto-update gets fixes to everyone quickly, but a compromised or broken release reaches everyone just as fast. If you can sign or verify releases, stage rollouts and pull a bad version, automatic updates are reasonable. If not, prefer notify and manual.
Definition
Auto-update means the tool fetches and installs a newer version of itself without the user asking. For internal developer tools, that update channel is part of your supply chain: whoever controls it can run code on every developer machine that has the tool.
Four update models
| Model | How it works | Best when | Main risk |
|---|---|---|---|
| Silent auto-update | Tool updates itself in the background | You have signed releases and fast rollback | A bad release lands everywhere at once |
| Update on next run with prompt | Tool offers the update at start | Users are technical and releases are frequent | Prompt fatigue; people click through |
| Notify only | Tool prints a notice, user upgrades through the package manager or installer | You want central control and review | Stale versions linger |
| Pinned and pushed by IT | Managed devices receive approved versions | Regulated or high privilege tools | Slower fixes, more admin work |
Questions that decide it
- Can you verify what you ship? If releases are built in CI with published checksums and provenance, a client can check them. SLSA's build levels describe this: level 1 means provenance exists, level 2 adds signed provenance from a hosted build platform, and level 3 a hardened build platform. The higher you are, the more comfortable automatic updates become.
- Who controls the update server? Anyone who can write to the place the tool downloads from can ship code to every machine. Protect that location like a production deploy key.
- Can you stop a bad release? You need a way to withdraw a version and have clients refuse it. Without that, auto-update is a one way door.
- How sensitive is the tool? A formatter and a deployment CLI are not the same decision. The more access the tool has, the more you want review before it changes.
- How fast do fixes need to land? For a tool that fixes security problems often, running a month behind is its own risk.
A middle path that works for many teams
Use staged rollout. Publish the new version to a small ring first, such as the tool's owners, watch for failures for a day, then widen. Clients check a signed manifest that names the current allowed version and a minimum version. If you need to block a release, you update the manifest, and clients stop installing it.
For tools on managed laptops, let the device management system handle versions. That also gives you an inventory of who has what, which you will want the day a release turns out to be bad.
What to avoid
Fetching an update over an unauthenticated channel. Executing a downloaded script without verification. Letting the update check read an endpoint from a project level config file. Updating while the tool is mid operation.
Record the decision
Write down which model each internal tool uses, who owns the update channel and how a bad release is withdrawn. It is a short note, and it is the first thing you will want during an incident.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a release candidate can be held back by a check before it ships.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and CLI can check each release candidate before it ships, and policies and gates can hold it back. The free scan is at gold.safeguard.sh/scan.
Quick check
Is silent auto-update always risky?
Not always. With signed releases, staged rollout and a way to withdraw a version it can be reasonable. Without those, prefer notify and manual updates.
What should clients check before installing an update?
That it came from your official channel, matches the published checksum or signature, and is an allowed version according to a manifest you control.
Sources
Last reviewed: 19 October 2026.
