Skip to main content

What the check does

Flags any inline run: script that fetches a binary or archive with curl or wget but does not perform an integrity check in the same step. The check looks at the entire script text for the download command and then for any of:
  • sha256sum, sha512sum, shasum
  • openssl dgst
  • gpg --verify
  • cosign verify, cosign verify-blob, cosign verify-attestation
  • slsa-verifier verify
  • gh attestation verify
  • minisign -V, signify -V
If at least one verification command is present in the step, the check passes. File-extension filter: only downloads of binary/archive shapes are flagged (.tar, .tar.gz, .tgz, .zip, .deb, .rpm, .pkg, .msi, .exe, .jar, .war, .whl, .gem, .apk, .so, .dll, .dylib, .bin, .run, .sh, .7z). Fetching JSON/text or piping straight to a shell are handled by other rules (the latter is BEST-PRAC-1).

Why it matters

A workflow that downloads tool.tar.gz and immediately extracts and runs it trusts:
  • That the upstream server hasn’t been compromised since the workflow author last looked.
  • That the TLS chain hasn’t been MITM’d on the runner.
  • That a typo or unicode lookalike in the URL hasn’t redirected to an attacker’s CDN.
Any of those can swap the binary’s contents without changing its path. The artifact then runs with the workflow’s GITHUB_TOKEN and every secret in scope — a textbook supply-chain compromise. A checksum or signature checked in the same step catches all three: the bytes the runner extracted have to match a value the workflow author wrote down.

Vulnerable example

Safe alternatives

Checksum pinned in the workflow:
Signature verification via cosign:
Provenance-based verification: