DevOps Bootcamp · 강의

ShellCheck를 활용한 정적 분석 및 감사

Q: “ShellCheck를 활용한 정적 분석 및 감사” 강의는 무료인가요?

네 — “ShellCheck를 활용한 정적 분석 및 감사” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 DevOps Bootcamp 강의 전체를 잠금 해제할 수 있습니다. DevOps Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

Q: DevOps Bootcamp을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 DevOps Bootcamp은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

Q: “ShellCheck를 활용한 정적 분석 및 감사” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

Q: 이 DevOps Bootcamp 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 DevOps Bootcamp 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

ShellCheck를 보안 게이트에 통합하고 분석 결과를 해석하여 모든 스크립트를 더욱 안전하게 만듭니다.

ShellCheck를 활용한 정적 분석 및 감사은(는) CoddyKit의 무료 DevOps Bootcamp 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 DevOps Bootcamp 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. DevOps Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

ShellCheck란 무엇이며 왜 중요한가

ShellCheck는 셸 스크립트를 위한 오픈 소스 정적 분석 도구입니다. Bash(및 POSIX sh, dash, ksh) 소스 코드를 실행하지 않고 분석하여 버그, 안전하지 않은 구문, 이식성 문제와 스타일 문제를 보고합니다. 각 항목에는 SC2086처럼 고유한 규칙 코드가 표시됩니다.

보안이 강화된 파이프라인에서 ShellCheck는 필수 관문 역할을 합니다. 검사를 통과하기 전에는 어떤 스크립트도 배포하지 않습니다. 이것이 중요한 이유는 다음과 같습니다.

많은 셸 취약점(단어 분할, 삽입, 따옴표 없는 확장)은 정상 경로 테스트 중에는 보이지 않지만 공격자가 제어하는 입력에서 발생합니다.
ShellCheck는 이러한 종류의 버그를 실행 전에 비용 없이 찾아냅니다.
각 패턴이 왜 위험한지 설명하므로 시간이 지날수록 팀의 인식이 높아집니다.

어떤 시스템에든 설치할 수 있습니다.

# Debian / Ubuntu
sudo apt-get install shellcheck

# macOS (Homebrew)
brew install shellcheck

# From source via Cabal (any platform)
cabal update && cabal install ShellCheck

# Verify
shellcheck --version

처음으로 ShellCheck 실행하기

가장 간단한 호출 방법은 shellcheck <script>입니다. ShellCheck는 셰뱅 줄을 읽어 셸 방언을 확인한 다음 결과를 표준 출력으로 내보냅니다.

각 결과에는 다음이 포함됩니다.

파일 및 줄 번호 — 정확한 위치
심각도 — error, warning, info 또는 style
SC 코드 — 조회하거나 억제할 수 있는 안정적인 규칙 식별자
사람이 이해할 수 있는 설명 — 무엇이 잘못되었는지, 그리고 대개 어떻게 수정하는지 알려 줌

아래 스크립트를 실행하고 ShellCheck가 출력할 결과를 확인해 보십시오.

#!/usr/bin/env bash
# demo_bad.sh — intentionally flawed for ShellCheck demonstration

FILE=$1

if [ $FILE == '' ]; then
  echo "No file given"
fi

cat $FILE | grep 'error' | wc -l

ShellCheck 출력 및 SC 코드 해석하기

이전 장면의 스크립트에 대해 ShellCheck는 다음과 같은 결과를 내보냅니다.

SC2086(경고) — 글로빙과 단어 분할을 방지하려면 큰따옴표로 묶으십시오. — [ $FILE == '' ]의 $FILE과 cat $FILE의 $FILE에 해당합니다.
SC2039 / SC3010(정보) — [ ] 안의 ==는 bashism입니다. POSIX에서는 =를 사용하십시오.
SC2002(스타일) — 쓸모없는 cat입니다. cat file | cmd 대신 cmd < file을 사용하십시오.

각 SC 코드는 https://www.shellcheck.net/wiki/SCxxxx의 위키 페이지로 연결되며, 그곳에서 근거와 수정된 예시를 확인할 수 있습니다.

해당 스크립트의 수정된 버전은 다음과 같습니다.

#!/usr/bin/env bash
# demo_fixed.sh — ShellCheck-clean

FILE="$1"

if [ -z "$FILE" ]; then
  echo "No file given" >&2
  exit 1
fi

grep -c 'error' "$FILE"

심각도 단계와 조치할 항목

ShellCheck는 모든 결과를 심각도별로 분류합니다. 보안 관문에서는 다음과 같이 처리해야 합니다.

error — 버그나 보안 취약점일 가능성이 매우 높습니다. 빌드를 차단하고 즉시 수정하십시오. 예: 셰뱅이 없는 SC2148, 따옴표로 묶지 않은 $?가 있는 SC2070.
warning — 악용될 가능성이 높은 패턴입니다. 빌드를 차단하고 수정하거나 억제 이유를 명시적으로 정당화하십시오. 예: 따옴표로 묶지 않은 변수에 대한 SC2086.
info — 현재는 올바를 가능성이 높지만 취약하거나 이식성이 떨어집니다. 범위 밖이라고 판단하지 않는 한 같은 PR에서 수정하십시오.
style — 외형적 문제 또는 POSIX 선호 사항입니다. 순수 Bash 코드베이스에서는 권장되지만 선택 사항입니다.

--severity=warning을 사용하면 경고 이상의 결과가 있을 때만 0이 아닌 상태 코드로 종료됩니다. 이는 표준 보안 관문 임계값입니다.

#!/usr/bin/env bash
# gate.sh — fail CI on errors and warnings only
shellcheck --severity=warning scripts/*.sh
echo "ShellCheck exit code: $?"

CI 보안 관문으로 ShellCheck 통합하기

보안 관문은 필수이고 자동화되어 있을 때만 유용합니다. 아래 패턴은 ShellCheck를 다음 작업을 수행하는 CI 단계로 감쌉니다.

저장소의 모든 .sh 파일을 찾습니다.
--severity=warning과 기계 판독이 가능한 JSON 출력을 사용하여 ShellCheck를 실행합니다.
결과가 하나라도 있으면 파이프라인을 실패시킵니다(exit 1).
요약을 출력하므로 엔지니어가 CI 로그를 벗어나지 않고 결과에 대응할 수 있습니다.

이 파일을 저장소에 넣고 CI 파이프라인(GitHub Actions, Jenkins, GitLab CI 등)에서 호출하십시오.

#!/usr/bin/env bash
# ci/shellcheck_gate.sh
set -euo pipefail

SCRIPTS=$(find . -name '*.sh' -not -path './.git/*')
FAILED=0

for script in $SCRIPTS; do
  echo "==> Checking: $script"
  if ! shellcheck --severity=warning --format=tty "$script"; then
    FAILED=1
  fi
done

if [ "$FAILED" -eq 1 ]; then
  echo "[GATE] ShellCheck found warnings or errors. Build blocked." >&2
  exit 1
fi

echo "[GATE] All scripts passed ShellCheck."

SC2086 계열: 따옴표로 묶지 않은 변수 확장

SC2086은 ShellCheck에서 가장 흔히 발견되는 항목이며, 가장 많이 악용되는 셸 취약점 중 하나인 따옴표로 묶지 않은 변수 확장을 가리킵니다.

변수를 큰따옴표로 묶지 않으면 셸은 변수 값에 대해 단어 분할(IFS를 기준으로 분할)과 글로브 확장을 수행합니다. 공격자가 변수를 제어할 수 있으면 추가 인수를 삽입하거나, 파일 시스템 순회를 유발하거나, 명령에 예상하지 못한 피연산자를 전달할 수 있습니다.

대표적인 위험 패턴은 다음과 같습니다.

#!/usr/bin/env bash
# Attacker sets: FILENAME="important.txt /etc/passwd"
FILENAME="$1"

# UNSAFE — word splitting turns this into two args
rm $FILENAME

# SAFE — double quotes prevent splitting
rm "$FILENAME"

# Arrays are the right tool for lists
FILES=("$@")
rm -- "${FILES[@]}"

SC2046 및 SC2035로 명령 삽입 위험 감지하기

잘 알려지지는 않았지만 중요한 두 규칙은 서브셸 출력으로 인한 명령 삽입을 다룹니다.

SC2046 — $(…) 내부에서 단어 분할과 글로브를 방지하려면 여기에 따옴표를 사용하십시오. 서브셸의 출력을 따옴표 없이 사용하면 출력에 포함된 공백이나 글로브 문자가 셸 토큰이 됩니다.
SC2035 — 파일 이름이 -으로 시작할 때 옵션으로 해석되는 것을 방지하려면 *.sh 대신 ./*.sh를 사용하십시오. 이는 대표적인 인수 삽입 경로입니다.

구체적인 악용 시나리오와 수정 방법은 다음과 같습니다.

#!/usr/bin/env bash
# SC2046 example — output of find fed unquoted to chmod
# If a filename contains spaces, extra arguments appear

# UNSAFE
chmod 600 $(find /secrets -name '*.key')

# SAFE — use a while-read loop or xargs with -0
find /secrets -name '*.key' -print0 \
  | xargs -0 chmod 600

# SC2035 example
# UNSAFE — a file named '-rf' would be passed as an option
rm *.sh

# SAFE
rm -- ./*.sh

자동화를 위한 JSON 출력 형식 사용하기

ShellCheck는 --format을 통해 여러 출력 형식을 지원합니다.

tty(기본값) — 사람이 읽을 수 있는 터미널 출력
json — 기계 판독 가능 형식으로, 대시보드, 사용자 지정 차단 규칙 또는 SAST 플랫폼 업로드에 적합합니다.
gcc — GCC 오류 형식을 분석하는 도구(IDE, Vim/Emacs)와 호환됩니다.
checkstyle — Jenkins Checkstyle 플러그인이 사용하는 XML 형식입니다.

JSON 형식을 사용하면 특정 SC 코드만 차단하거나, 대규모 코드베이스 전체의 결과를 하나의 보안 보고서로 집계하는 등 자동화된 정책을 작성할 수 있습니다.

#!/usr/bin/env bash
# Emit JSON and filter for only error-severity findings using jq
shellcheck --format=json scripts/deploy.sh \
  | jq '[.[] | select(.level == "error")]'

# Count distinct SC codes across all scripts
find . -name '*.sh' -print0 \
  | xargs -0 shellcheck --format=json 2>/dev/null \
  | jq '[.[] | .code] | group_by(.) | map({code: .[0], count: length}) | sort_by(-.count)'

거짓 양성을 올바르게 억제하기

ShellCheck를 무차별적으로 비활성화하면 도구의 목적이 사라집니다. 올바른 방법은 결과가 실제로 적용되지 않는 정확한 줄이나 블록에만 영향을 주는 대상 지정 및 문서화된 억제입니다.

억제 방법은 세 가지입니다.

인라인 비활성화 — 문제가 있는 코드 바로 위 줄에 # shellcheck disable=SC2086을 작성합니다. 해당 줄에만 적용됩니다.
블록 비활성화/활성화 — # shellcheck disable=…과 # shellcheck enable=…으로 특정 구간을 감쌉니다.
파일 수준 지시문 — 파일 맨 위에 # shellcheck disable=…을 작성합니다(정당화하기 어려운 경우가 많으므로 이유를 문서화해야 합니다).

모든 억제에는 해당 결과가 거짓 양성인 이유를 설명하는 주석이 반드시 포함되어야 합니다.

#!/usr/bin/env bash
# deploy.sh

# Legitimate suppression: $DEPLOY_ARGS is intentionally word-split
# because it is a pre-validated list of flags from a trusted config file.
# shellcheck disable=SC2086
exec deploy-tool $DEPLOY_ARGS

# Block suppression for a section that generates dynamic code
# shellcheck disable=SC2016
VARS='$HOME $PATH $USER'
echo "Unexpanded vars: $VARS"
# shellcheck enable=SC2016

.shellcheckrc를 통한 ShellCheck 구성

프로젝트 전체 설정을 위해 ShellCheck는 스크립트가 있는 디렉터리에서 시작하여 /까지 상위 디렉터리를 검색하며 .shellcheckrc를 읽습니다. 이를 통해 호출할 때마다 플래그를 반복하지 않아도 되고, 관문 스크립트를 간단하게 유지할 수 있습니다.

.shellcheckrc에서 유용한 지시문은 다음과 같습니다.

shell=bash — 방언 자동 감지를 재정의합니다(셰뱅이 없는 파일에 유용).
enable=all — 선택적 검사를 활성화합니다(예: avoid-nullary-conditions, require-variable-braces).
disable=SC2059 — 정당한 예외에 대해 프로젝트 전체에서 억제합니다.
external-sources=true — source / . 지시문을 따라가며 검사합니다.

# .shellcheckrc — project root
shell=bash
enable=all
external-sources=true

# SC2312: consider invoking this command separately to avoid masking its
# return value — suppressed project-wide because we use set -e.
# Rationale: errexit already aborts on failure; masking risk is mitigated.
disable=SC2312

처음부터 끝까지 강화된 스크립트: 수정 전과 수정 후

ShellCheck 결과를 제대로 익히는 가장 효과적인 방법은 실제와 비슷한 스크립트를 검사 실패 상태에서 깨끗하고 강화된 상태로 리팩터링하는 것입니다. 아래 스크립트는 디렉터리를 백업하며, 보안을 고려하지 않고 작성되었습니다. 서로 다른 규칙을 최소 다섯 개 위반하여 ShellCheck 검사를 통과하지 못합니다.

두 버전을 모두 살펴보십시오. 수정 후 버전은 억제 지시문 없이 shellcheck --severity=warning을 통과하며, 공격자가 제어하는 입력에도 훨씬 안전합니다.

#!/usr/bin/env bash
# BEFORE — multiple ShellCheck violations
DEST=$1
SRC=$2
DATE=`date +%Y%m%d`

if [ ! -d $DEST ]; then
  mkdir $DEST
fi

cp -r $SRC $DEST/$DATE
echo Done


#!/usr/bin/env bash
# AFTER — ShellCheck-clean and hardened
set -euo pipefail

DEST="${1:?Usage: backup.sh <dest> <src>}"
SRC="${2:?Usage: backup.sh <dest> <src>}"
DATE=$(date +%Y%m%d)

if [ ! -d "$DEST" ]; then
  mkdir -p -- "$DEST"
fi

cp -r -- "$SRC" "$DEST/$DATE"
echo 'Done' >&2

지식 확인: 보안 관문의 ShellCheck

ShellCheck가 보안 관문으로서 어떤 역할을 하는지 얼마나 이해했는지 확인해 보십시오.

복습: 보안 관문으로서의 정적 분석

이 레슨에서는 Bash 작업 흐름에서 ShellCheck를 필수 보안 관문으로 만드는 방법을 배웠습니다.

ShellCheck는 스크립트를 실행하지 않고 정적 분석을 수행하여 실행 전에 따옴표 오류, 삽입 위험과 안전하지 않은 패턴을 찾아냅니다.
모든 결과에는 자세한 문서와 수정 지침으로 연결되는 SC 코드(예: SC2086)가 포함됩니다.
심각도 단계인 error, warning, info, style을 사용하면 관문을 조정할 수 있습니다. --severity=warning이 권장되는 보안 임계값입니다.
기계 판독 가능한 출력(--format=json)을 사용하여 보고, 추세 추적 및 SAST 통합을 자동화하십시오.
억제는 최소한으로 사용하십시오. 항상 한 줄만 대상으로 지정하고, 주석에 이유를 문서화하며, .shellcheckrc로 정당화되는 경우가 아니면 전역적으로 억제하지 마십시오.
심층 방어를 위해 ShellCheck를 set -euo pipefail, 명시적인 따옴표 사용, -- argument 종결자 및 입력 검증과 함께 사용하십시오.

ShellCheck를 통과한 스크립트가 자동으로 안전해지는 것은 아닙니다. 그러나 ShellCheck 검사에 실패한 스크립트는 절대로 프로덕션에 도달해서는 안 됩니다.

자주 묻는 질문