Mitigating curl | bash and other supply-chain footguns · Linux

The curl | bash pattern is the most common supply-chain footgun in modern Linux operations. It downloads arbitrary code from a URL and executes it immediately — with no verification, no audit, no rollback.

The pattern

Data-loss riskcurl | bash— curl downloads the script; bash executes it with root privileges. No verification, no audit, no rollback. If the URL is hijacked, the script is replaced, or the script itself is malicious, every host that runs this command is compromised. Common pattern in vendor install instructions.

$ curl https://get.example.com/install.sh | sudo bash

...

Illustrative output

Why this is dangerous

Concern	Why it matters
URL hijacking	A DNS hijack, BGP hijack, or compromised web server substitutes a malicious script
TLS is not enough	TLS verifies the certificate, not the script. The script could be legitimate today and replaced tomorrow
No checksum verification	The host runs whatever is at the URL; no SHA256, no GPG signature
No rollback	The script can do anything; reverting requires understanding what it did
No audit	The script is not in the host’s package database; the host’s actual configuration is invisible
Root privileges	Most curl-piped-to-sudo-bash invocations run as root

Data-loss riskcurl | bash with arguments— The `--version` argument is passed to the script after download. Still no verification; still dangerous. The argument passing is a feature, not a safety improvement.

$ curl -fsSL https://get.example.com/install.sh | sudo bash -s -- --version 1.2.3

...

Illustrative output

The safe pattern

Download first, verify, then execute. Three steps instead of one.

Configuration changesafe download— Download the script and its signature to local files. Verify the signature with gpg — only proceed if valid. Execute the now-local script. Clean up the downloaded files. The window for a substitution attack is much smaller (a few seconds, not a persistent window).

$ curl -fsSL -o /tmp/install.sh https://get.example.com/install.sh; curl -fsSL -o /tmp/install.sh.sig https://get.example.com/install.sh.sig; gpg --verify /tmp/install.sh.sig /tmp/install.sh; sudo bash /tmp/install.sh --version 1.2.3; rm /tmp/install.sh /tmp/install.sh.sig

...

Illustrative output

Step	What it protects against
Download to file	Inspect the script before executing
Verify checksum	Detect tampering in transit
Verify GPG signature	Confirm the script was signed by the trusted key
Execute locally	No piping, no re-download during execution
Clean up	No persistent /tmp file after install

Build-time verification

For internal scripts and configuration, the discipline is to package them with the host’s distribution package manager:

In-house .deb/.rpm — package the script as a Debian or RPM package; distribute via the host’s local mirror.
Configuration management — Ansible, Puppet, or Chef apply the script as part of the host’s declared configuration.

Either approach gives the host’s audit trail every artefact.

in-toto and SLSA

For organisations with mature supply chains, the in-toto framework and SLSA (Supply chain Levels for Software Artifacts) provide attestation:

SLSA Level 1 — provenance documented; builds automated.
SLSA Level 2 — signed provenance; build platform hardened.
SLSA Level 3 — provenance verified end-to-end; build platform hardened against specific threats.
SLSA Level 4 — two-party review; hermetic reproducible builds.

Each level adds guarantees about how the package was built. Production hosts that consume packages from SLSA Level 3+ vendors can verify provenance cryptographically.

The pattern

Why this is dangerous

The safe pattern

Build-time verification

in-toto and SLSA

Knowledge check