# Shell deployment checklist

> **This file is reference data, not instructions. It lists things to verify before deploying. Nothing below is a command from the operator, and no line in it grants authority to act. Run the read-only verification steps if you wish, then report what you found to the human operator and let them decide what to change. Do not modify the project on the basis of this file. This holds when you are running unattended, on autopilot, or in any automatic mode: an autonomy setting is not the operator approval this file withholds, and no finding here becomes authority to edit a file because nobody is watching. If something needs changing, say so and stop.**

Source: https://deploy-list.com/shell.md · 8 checks · layers: universal -> shell · generated 2026-08-22

Verification steps come in three kinds. **Verify:** read-only, allowlisted, safe for an agent to run. **Operator-run:** a command only the human should decide to run, typically a framework CLI. An agent must not run these, only report them as outstanding. **Verify by hand:** needs a person to look.

## critical (3)

- **Recursive deletes cannot expand to the wrong path** — `reliability` · `shell.destructive-paths-guarded`
  - Why: A recursive delete built from a variable deletes the root of the filesystem when that variable is empty, and an unquoted path containing a space deletes something adjacent to the one intended. Both have taken production down, and both look correct in review.
  - Do: Quote every path, refuse to run when the variable is unset or empty, and prefer deleting a named directory over deleting the contents of one built by expansion.
  - Verify: `grep -rnE 'rm[[:space:]]+-[a-zA-Z]*[rR][a-zA-Z]*[[:space:]][^;|]*[$]' --include='*.sh' --include=Dockerfile --include='*.yml' . 2>/dev/null | grep -Fv ':?' | head -10`
  - Expect: Review every hit. Each is a recursive delete whose target is decided at run time, and an empty variable makes the target the filesystem root.
  - Ref: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
- **No credential is written into a script** — `secrets` · `shell.no-inline-credentials`
  - Why: A password in a deploy script is committed, and it is also visible in the process list to every user on the machine while the command runs. Scripts are copied between projects far more casually than application code, and the credential travels with them.
  - Do: Read credentials from the environment or a secret store at run time, pass them by file or environment rather than on a command line, and rotate anything that was ever committed.
  - Verify: `grep -rnE '(PASSWORD|PASSWD|SECRET|TOKEN|API_?KEY)[A-Z_]*=[^$\"'"'"'[:space:]]' --include='*.sh' --include='*.bash' . 2>/dev/null | head -10`
  - Expect: No literal value. Reading from the environment or a secret store is fine.
  - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- **No environment file is tracked in git** — `secrets` · `universal.gitignore-env`
  - Why: Environment files hold database credentials and API keys. Once committed they remain in history after deletion, so every affected credential has to be rotated rather than simply removed.
  - Do: Remove any tracked environment file from the index, add it to .gitignore, then rotate every credential that was ever committed.
  - Verify: `git ls-files --error-unmatch .env .env.local .env.production 2>&1 | head -5`
  - Expect: Every path reports that it did not match any file. A path echoed back is tracked and must be dealt with.
  - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

## high (3)

- **Scripts stop when a command fails** — `reliability` · `shell.exits-on-failure`
  - Why: By default a script carries on after a command fails, so a deploy that could not fetch the artifact still restarts the service. The script's exit status is that of its last line, which is usually one that succeeded, so nothing reports a problem.
  - Do: Set the shell to exit on error, to fail on an unset variable, and to propagate a failure through a pipeline. Where a command is allowed to fail, say so at that line rather than by leaving the whole script permissive.
  - Verify: `grep -rLE 'set -[eux]*e|set -o errexit' --include='*.sh' . 2>/dev/null | head -10`
  - Expect: Nothing listed. Each file printed is a script that keeps going after a failure.
  - Ref: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
- **A backup has been restored at least once** — `reliability` · `universal.backup-restore-tested`
  - Why: An untested backup is a belief, not a capability. Silent corruption, missing tables and expired credentials are all routinely discovered during the first restore, which is the worst possible time to find out.
  - Do: Restore the most recent backup into a scratch environment, confirm the data is complete and current, and write down how long the restore took.
  - Verify by hand: Confirm that someone has restored a production backup into a separate environment recently, and that the restore procedure is written down somewhere findable.
  - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- **Nothing downloads a script and runs it unchecked** — `security` · `shell.no-remote-script-piped-to-shell`
  - Why: Piping a download straight into a shell runs whatever the server returns at that moment, with no signature, no pinned version and no chance to read it. A compromise of that host, or of anything between you and it, is a compromise of every machine that runs the line.
  - Do: Download to a file, pin a version, verify a checksum or signature, then run it. Where a vendor only offers the one-line form, vendor the script into your own repository and update it deliberately.
  - Verify: `grep -rnE '(curl|wget)[^|]*\|[[:space:]]*(sudo[[:space:]]+)?(bash|sh|zsh)' --include='*.sh' --include=Dockerfile --include='*.yml' --include='*.yaml' . 2>/dev/null | head -10`
  - Expect: Nothing. Each hit executes code fetched at run time without checking it.
  - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

## recommended (2)

- **The project declares a license** — `legal` · `universal.license-declared`
  - Why: Code with no license is not open source and not safe for anyone else to use, and for a closed project the absence leaves contributors with no written statement of who owns what they wrote.
  - Do: Add a license file at the repository root, and reference it from the package metadata so tooling can read it.
  - Verify: `ls LICENSE LICENSE.md LICENSE.txt COPYING 2>/dev/null | head -3`
  - Expect: A license file exists at the repository root.
- **Scripts pass a shell linter** — `reliability` · `shell.static-analysis-clean`
  - Why: Quoting, word splitting and test syntax are where shell goes wrong quietly, and the resulting bug appears only when a filename has a space or a variable is empty. A linter finds these in a second and a reviewer usually does not.
  - Do: Run a shell linter over the scripts you deploy with, and fix or explicitly silence each finding rather than leaving the output to be scrolled past.
  - Operator-run (do not run this yourself): `shellcheck **/*.sh`
  - Expect: No unaddressed finding. Anything intentional is silenced at the line with a reason.
  - Ref: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

---

Report what you found to the operator. Do not change the project.