SAST 스캔
종속성 감사는 가져온 코드를 검사하는 반면, SAST는 직접 작성한 코드를 검사합니다. 패턴 매칭(그리고 테인트 모드를 통한 데이터 흐름 추적)을 통해 명령어/SQL 인젝션, 경로 탐색, 안전하지 않은 역직렬화, 신뢰할 수 없는 입력에 대한 eval/동적 실행, 하드코딩된 암호화, 누락된 인증 검사 등 전형적인 결함을 찾아냅니다. 높은 오탐률은 본질적인 특성이며, 중요한 것은 무시하는 것이 아니라 도달 가능성에 따라 분류하는 것입니다.
실행 시점
- 릴리스 전, diff 또는 전체 트리를 대상으로.
- 신뢰할 수 없는 입력을 처리하는 코드(새로운 도구, 엔드포인트, 파서, 쉘 호출)를 추가할 때.
- PR에 대한 CI에서(diff 범위로 제한되어 빠르며 새로운 문제만 찾아냅니다).
실행 방법
# semgrep — 보안 규칙 세트. `auto`는 감지된 언어에 따라 규칙을 선택합니다.
semgrep scan --config auto --error .
# 집중된, 더 높은 신호 규칙 세트(auto보다 노이즈가 적습니다):
semgrep scan --config p/security-audit --config p/secrets --config p/command-injection .
# Diff만(PR의 CI — 빠르고, 새로운 발견만):
semgrep scan --config auto --baseline-commit origin/main .
더 깊은 데이터 흐름(신뢰할 수 없는 입력이 실제로 싱크에 도달하는가?)을 위해서는 CodeQL이 더 강력하지만 무겁습니다:
codeql database create db --language=javascript # 또는 rust, python, …
codeql database analyze db --format=sarif-latest --output=results.sarif \
codeql/javascript-queries:codeql-suites/javascript-security-extended.qls
분류 — 무시하지 말고 추적하세요
각 발견에 대해 소스 → 싱크 경로를 추적하십시오:
- 입력이 공격자에 의해 제어됩니까? 하드코딩된 상수에 대한
child_process.exec는 괜찮습니다. 요청 매개변수에 대한 것은 명령 인젝션 버그입니다. semgrep은 싱크를 표시합니다. 여러분이 소스를 확인하세요. - 그 사이에 살균 장치가 있습니까? 값이 싱크에 도달하기 전에 검증/이스케이프되었다면(zod 스키마, 허용 목록, 매개변수화된 쿼리) 오탐입니다.
# nosemgrep: <규칙-id>로 표시하되 이유를 한 줄로 작성하고, 단순히 무시하지 마세요. - 실제 문제인가요? 소스(입력 검증/이스케이프) 또는 싱크(매개변수화, 안전한 API 사용)에서 수정하고, 경고를 억제하지 마세요.
문제를 없애기 위해 규칙을 일괄 비활성화하지 마십시오. 그러면 노이즈 속에 있는 실제 문제 하나까지 억제하게 됩니다. 줄 단위로, 이유와 함께 억제하세요.
실제로 수정할 사항(가치가 높은 순서)
- 인젝션(명령어/SQL/템플릿) — 사용자 도달 가능한 경로에서 가장 심각하고 가장 많이 악용되는 부류입니다.
- 경로 탐색 — 검증되지 않은 경로가 파일 읽기/쓰기에 도달하는 경우(파일을 쓰는 에이전트는 정확히 이 위험이 있습니다. 범위 검사를 게이트로 사용하세요).
- 동적 문자열의 안전하지 않은 exec/eval.
- 보안 컨텍스트에서의 하드코딩된 암호화 / 취약한 난수성.
경계
SAST는 한 저장소의 소스를 정적으로만 봅니다. 런타임 구성, 환경 변수에 따른 코드 경로, 서비스 경계를 넘어서만 나타나는 결함을 볼 수 없습니다. 이는 실제 위협 모델 및 [[dependency-audit]]을 보완할 뿐 대체하지 않습니다. 에이전트/도구 런타임의 경우 가장 강력한 제어는 종종 코드 한 줄보다는 아키텍처(모든 동작을 게이트하는 커널)에 있습니다. SAST는 그 경계 주변의 코드를 검증합니다. [[security-preflight]]에 통합하세요.