개념
사람이 다 못 보는 것을 도구가 메운다
레슨 5에서 배운 OWASP Top 10 같은 취약점을, 사람이 코드를 한 줄씩 읽으며 다 찾아내는 건 비현실적이다. 세 가지 자동화된 보안 검사 도구가 이 부담을 나눠서 진다 — 이름이 비슷해 보이지만 검사 대상과 시점이 완전히 다르다.
SAST(Static Application Security Testing) — 정적 분석
애플리케이션을 실행하지 않고, 소스 코드 자체를 분석해서 취약할 수 있는 패턴을 찾는다.
검사 시점: 코드 작성 직후, 실행 전(모듈 14의 CI 파이프라인 초반)
검사 대상: 소스 코드 그 자체
찾는 것: "이 코드 패턴은 SQL 인젝션(레슨 5)에 취약할 수 있다" 같은
잠재적 위험 패턴SAST는 모듈 9(레슨 1)에서 배운 코드 읽기를 기계가 대신해주는 셈이다 — 다만 사람보다 훨씬 빠르고 놓치지 않는다는 장점과, 실제로 악용 가능한지는 판단하지 못하고 "위험해 보이는 패턴"을 넓게 잡아낸다는 한계가 함께 있다.
DAST(Dynamic Application Security Testing) — 동적 분석
실제로 애플리케이션을 실행한 상태에서, 외부에서 공격하듯 요청을 보내며 취약점을 찾는다.
검사 시점: 애플리케이션이 실제로 돌아가는 스테이징 환경(모듈 7 레슨 3)
검사 대상: 실행 중인 애플리케이션의 실제 응답
찾는 것: "이 입력을 보냈더니 실제로 에러 메시지에 시스템 정보가
노출됐다"처럼 실제로 확인된 문제DAST는 모듈 12에서 배운 API 테스트와 비슷한 방식으로 동작하지만, 목적이 기능 검증이 아니라 공격 시도에 대한 실제 반응을 확인하는 것이다. SAST보다 "실제로 문제가 있는지" 더 확실하지만, 코드 내부 구조는 못 보므로 SAST가 잡는 일부 잠재 위험은 놓칠 수 있다.
SCA(Software Composition Analysis) — 구성 요소 분석
모듈 15(레슨 1)에서 다룬 것과 달리, 우리가 직접 짠 코드가 아니라 우리가 가져다 쓰는 외부 라이브러리·패키지에 알려진 취약점이 있는지 검사한다.
검사 시점: 의존성을 설치하거나 업데이트할 때(모듈 14의 CI 초반)
검사 대상: package.json 같은 의존성 목록
찾는 것: "이 라이브러리 버전은 이미 공개적으로 알려진 심각한
취약점이 있다"레슨 5에서 배운 "취약하고 오래된 컴포넌트 사용"이 바로 SCA가 겨냥하는 문제다. 우리 코드가 완벽해도, 가져다 쓰는 라이브러리 하나에 구멍이 있으면 그게 전체 시스템의 약점이 된다.
세 도구를 CI/CD에 배치하기
모듈 14(레슨 4)에서 배운 품질 게이트에 이 세 도구를 자연스럽게 연결할 수 있다.
1. 코드 작성 → SAST 검사 (가장 빠르고 이르게)
2. 의존성 설치 → SCA 검사
3. 스테이징 배포 → DAST 검사 (가장 늦지만 가장 현실적인 검증)이 순서는 모듈 11(레슨 1)에서 배운 피라미드 순서(빠르고 저렴한 것 먼저)와 같은 논리를 따른다.
QA의 역할 — 결과를 읽고 우선순위를 매기는 것
이 도구들이 자동으로 결과를 쏟아내지만, 모든 결과가 실제 위험은 아니다(레슨 5의 SAST 한계처럼 "잠재적" 경고가 많이 섞여 있다). QA는 모듈 6(레슨 1)에서 배운 심각도 판단 원칙으로, 쏟아지는 경고 중 진짜 위험한 것과 무시해도 되는 것을 가려내는 역할을 할 수 있다.
그 가려내는 절차 — 허가 확인, 4단계 트리아지, 오탐 분류, CVSS 재평가, 개발팀에 넘길 티켓 형태 — 는 모듈 23(레슨 3) 에서 자세히 다룬다. 최근 늘고 있는 AI 기반 스캐너는 오탐에도 그럴듯한 설명이 붙어 걸러내기가 오히려 더 어려워졌다.
실무에서 왜 필요한가
전담 보안팀이 없는 조직에서는, SAST·DAST·SCA를 CI 파이프라인에 연결해두는 것만으로도 상당한 보안 안전망이 생긴다. QA가 이 도구들의 역할 차이를 이해하고 있으면, "SCA에서 발견된 이 취약점이 실제 심각한지" 판단하거나, "이 기능은 아직 DAST 스캔 대상에 포함이 안 됐다"처럼 빈틈을 짚어낼 수 있다.