It is convenient and it runs whatever the server sends, as the user, with no chance to read it first. For an internal tool it is acceptable only if the script is short, served over HTTPS from a location you control, pinned to a version and verified against a checksum. Otherwise offer a package or a download and verify step.
What actually happens
The pattern downloads a script and feeds it straight to a shell. There is no point at which a person or a tool inspects it. If the server is compromised, if a redirect is hijacked, or if someone with write access changes the file, the next person to paste the line runs the change. Another subtle problem: a connection that drops partway through can leave a script half executed.
The installer then usually drops a binary on the PATH and sometimes edits shell profile files. Those are persistent changes made by code nobody read.
When it is defensible and when it is not
| Situation | Verdict |
|---|---|
| Tool for a handful of engineers, script under fifty lines, hosted in your own repo | Acceptable with a pinned version |
| Tool used by many teams with write access to production | Prefer a package manager or managed deployment |
| Script that edits system files or uses elevated privileges | Avoid; ship a package |
| Installer URL that always serves the latest | Avoid; pin |
| Installer that downloads another script | Avoid; one hop only |
How to keep the convenience and add safety
- Keep the script small and readable. If you cannot review it in a minute, split it.
- Host it somewhere write protected, with changes by pull request, not a shared bucket that many people can edit.
- Put the version in the URL so a given line always installs the same thing.
- Have the script download the binary and verify a checksum that is published separately, then exit if it does not match.
- Wrap the logic in a function and call it on the last line, so a truncated download executes nothing.
- Install to a user directory by default. Do not ask for sudo.
- Print what it will change and where, before it does it.
- Publish the two step alternative in the same README: download, read, then run.
For teams on managed laptops, a package pushed by device management is better than any one liner. You also get inventory.
Make it easy to read first
A short line in your docs helps: "If you prefer, download the script, read it, then run it." Security minded engineers will do exactly that, and the others lose nothing.
What to tell new hires
Make the habit explicit: do not paste an installer line from a chat message you cannot trace to the official docs page. Attackers do impersonate teammates and send helpful install commands. The rule covers external tools too.
Related controls
A signed release and provenance make the checksum meaningful, because the checksum itself must come from a trustworthy place. See our posts on securing an internal CLI and on update models for the larger picture.
Where Safeguard fits
Safeguard's CLI is available from the download page through curl and PowerShell installers. The free scan at gold.safeguard.sh/scan needs no install.
Quick check
Why wrap the installer in a function?
So a download that is cut short does not execute a partial script. The function only runs when the final line is reached.
Is HTTPS enough?
It protects the connection, not the content. If the server or its files are compromised, you still run the bad script, so pin versions and verify checksums.
Last reviewed: 19 October 2026.
