Brain정적 분석과 동적 분석 (SAST & DAST)
핵심 인사이트 (3줄 요약)
- 본질: SAST(Static Application Security Testing)는 코드를 실행하지 않고 소스 코드/바이너리를 분석하여 취약점을 탐지하고, DAST(Dynamic Application Security Testing)는 애플리케이션을 실행한 상태에서 실제 공격 시뮬레이션을 수행하여 취약점을 탐지하는 보안 테스팅 방법론이다.
- 가치: SAST와 DAST를 함께 사용하면 코드 레벨과 런타임 레벨의 취약점을 모두 탐지할 수 있어, 개발 단계에서 보안 결함을 조기에 발견하고 수정 비용을 줄일 수 있다. Gartner에 따르면 SAST/DAST 도입으로 보안 결함 수정 비용이 50~70% 절감 가능하다.
- 융합: SAST/DAST는 컴파일러 기술(데이터 흐름 분석, 콘볼루션널 분석), 크롤링/파징 기술, CI/CD 파이프라인, 그리고 DevSecOps 문화와 깊이 결합한다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
SAST(Static Application Security Testing)는 소프트웨어를 실행하지 않고 소스 코드, 바이트 코드, 또는 바이너리를 분석하여 보안 취약점, 코드 결함, 그리고コーディング 규칙 위반을 탐지하는 테스팅 방법론이다. SAST는 컴파일러의 구문 분석(파싱), 데이터 흐름 분석(Data Flow Analysis), 제어 흐름 분석(Control Flow Analysis), 패턴 매칭(Pattern Matching) 등의 기법을 활용하여 코드의脆弱점를 탐지한다.
DAST(Dynamic Application Security Testing)는 이미 컴파일되거나 배포된 애플리케이션을 실행 상태에서 테스트하는 방법으로, 테스트 도구가 실제 HTTP 요청을 생성하여 애플리케이션에 전송하고, 응답을 분석하여 취약점을 탐지한다. DAST는 블랙박스(Black-box) 테스트로, 테스트 대상의 내부 구현을 몰라도 테스트가 가능하며, 실제 공격과 유사한 방식으로 동작한다.
필요성
보안 취약점은 개발 단계에서 도입되고, 테스트/운영 단계에서 발견되는 경우가 많다. 개발 단계에서 발견되면 수정 비용이 낮지만, 테스트 단계에서 발견되면 아키텍처 변경 없이 코드 수준에서 수정이 가능하고, 운영 단계에서 발견되면 대규모 패치가 필요하며, 사용자에게 영향을 미치기 시작한 후에 발견되면 신뢰도 손실과 함께 대규모 incident 대응이 필요하다. SAST와 DAST를 CI/CD 파이프라인에 통합하면, 개발 단계에서 보안 결함을 조기에 발견하여 수정 비용을 최소화할 수 있다.
💡 비유
SAST는 건축 설계도를 검토하는 구조 엔지니어와 같다. 건물을 짓기 전에 설계도(소스 코드)를 보고 "여기 기둥이 부족하네요", "이 부분 내진 설계가 안 됐네요" 등의 구조적 문제를 찾아낸다. DAST는 완공된 건물에서 실제 흔들림 테스트(지진 시뮬레이션)을 해보는 것과 같다. 건물이 완성된 후(애플리케이션 실행) 실제 하중을 가해서(공격 시뮬레이션) 어디가 취약한지 측정한다. 설계도 검토(SAST)와 실제 테스트(DAST)를 함께 하면 가장 효과적으로 구조적弱点を찾을 수 있다.
등장 배경 및 발전 과정
SAST의 개념은 1990년대 컴파일러 기술의 일종으로 거슬러 올라간다. 2000년대初頭 Fortify, Ounce Labs 등이 상용 SAST 도구를 출시하기 시작했다. 2010년경 SonarQube(开源)가 등장하여 정적 분석의普及을 이끌었다. DAST는 1990년대 말 웹 애플리케이션 보안 테스팅에서 시작되었으며, 2005년 OWASP Top 10의 등장으로 웹 애플리케이션 보안 테스트의 중요성이 부각되면서 발전했다. 2010년대에는 Burp Suite, OWASP ZAP 등 DAST 도구가开源화되었으며, 현재는 DevSecOps와 함께 SAST/DAST가 CI/CD 파이프라인에 통합되어 자동화된 보안 테스팅이 일반화되고 있다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
SAST 동작 원리
SAST는 컴파일러의 분석 기술을 활용하여 코드를 분석한다. 주요 분석 기법으로는 구문 분석(Syntax Analysis), 의미 분석(Semantic Analysis), 데이터 흐름 분석(Data Flow Analysis), 제어 흐름 분석(Control Flow Analysis), 패턴 매칭(Pattern Matching)이 있다.
┌─────────────────────────────────────────────────────────────────────┐
│ SAST 분석 엔진 동작 원리 │
├─────────────────────────────────────────────────────────────────────┤
│
│ [1. 소스 코드 파싱 (Parsing)] │
│
│ 소스 코드 ──▶ Lexer ──▶ Token Stream ──▶ Parser ──▶ AST │
│ │ │ │
│ 토큰화(어휘 분석) 파스 트리(구문 분석) │
│
│ [2. 중간 표현 변환 (IR Generation)] │
│
│ AST ──▶ 중간 표현(IR) ──▶ 제어 흐름 그래프(CFG) │
│ │ │
│ 데이터 흐름 그래프(DFF) │
│
│ [3. 분석 엔진 (Analysis Engine)] │
│
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ [데이터 흐름 분석] │ │
│ │ 변수 정의 ──▶ 전파 ──▶ 도달 가능 분석 │ │
│ │ 예: getParameter("id") ──▶ 문자열 연결 ──▶ SQL query │ │
│ │ ──▶ SQL 주입 취약점 경고! │ │
│ │ │ │
│ │ [패턴 매칭] │ │
│ │ 코드 패턴 vs 취약점 패턴 데이터베이스 │ │
│ │ 예: gets(), strcpy() → 버퍼 오버플로우 패턴 │ │
│ │ │ │
│ │ [제어 흐름 분석] │ │
│ │ 분기, 반복, 예외 처리 경로 추적 │ │
│ │ 예: if(auth) { admin_panel(); } → 권한 검증 경로 분석 │ │
│ └──────────────────────────────────────────────────────────────┘ │
│
│ [4. 결과 생성] │
│
│ 취약점 경고 ──▶ 정렬 ──▶ CVSS 점수 ──▶ 보고서 생성 │
│
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] SAST의 첫 단계는 소스 코드를 파싱하여 AST(Abstract Syntax Tree)를 구성하는 것이다. Lexer가 코드를 토큰화하고, Parser가 토큰열을 AST로 변환한다. 그 다음 AST를 중간 표현(IR)로 변환하여 CFG(Control Flow Graph)와 DFG(Data Flow Graph)를 구성한다. 분석 엔진은 CFG와 DFG를 활용하여 데이터 흐름 분석, 패턴 매칭, 제어 흐름 분석을 수행한다. 예를 들어, getParameter("id")로 사용자 입력을 가져와서 문자열 연결로 SQL 쿼리를 구성하면, 데이터 흐름 분석이 이를 탐지하여 "SQL 주입 취약점"으로 경고한다. 이 과정이 완료되면 발견된 취약점이 CVSS 점수와 함께 보고서로 정리된다.
DAST 동작 원리
DAST는 실행 중인 애플리케이션에 HTTP 요청을 보내고 응답을 분석하여 취약점을 탐지한다. 블랙박스 테스트이므로 내부 구현을 몰라도 테스트가 가능하며, 실제 공격과 유사한 방식으로 동작한다.
┌─────────────────────────────────────────────────────────────────────┐
│ DAST 분석 엔진 동작 원리 │
├─────────────────────────────────────────────────────────────────────┤
│
│ [1. 웹 크롤링 (Crawling)] │
│
│ Spider ──▶ 발견된 URL ──▶ 링크 추출 ──▶ 재귀적 크롤링 │
│ │ │
│ └── 발견된 폼: 로그인, 검색, 등록 등 │
│
│ [2. 공격 시뮬레이션 (Attack Simulation)] │
│
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 테스트 케이스 생성: │ │
│ │ - XSS: <script>alert('XSS')</script> │ │
│ │ - SQL Injection: ' OR '1'='1 │ │
│ │ - Path Traversal: ../../etc/passwd │ │
│ │ - Command Injection: ; ls -la │ │
│ │ │ │
│ │ 각 케이스별 요청 생성 및 전송 │ │
│ └──────────────────────────────────────────────────────────────┘ │
│
│ [3. 응답 분석 (Response Analysis)] │
│
│ 응답 ──▶ 패턴 탐지 ──▶ 취약점 확인 │
│ │ │
│ ├── XSS: 스크립트 태그 응답 내 존재? │
│ ├── SQL 주입: 오류 메시지 또는 비정상적 데이터 반환? │
│ └── Path Traversal: 파일 내용 또는 디렉토리 리스트 반환? │
│
│ [4. 리포트 생성] │
│
│ 취약점 발견 ──▶ URL, 파라미터, 공격 페이로드 ──▶ 보고서 │
│
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] DAST의 첫 단계는 웹 크롤러로 애플리케이션의 모든 URL과 폼을 발견하는 것이다. Spider가 시작 페이지에서 링크를 따라가며 재귀적으로 모든 페이지를 탐색하고, 발견된 폼(입력 필드)을 기록한다. 두 번째 단계에서 DAST 도구는 XSS, SQL 주입, 경로 탐색, 명령어 주입 등의 테스트 케이스를 생성하여 각 입력 필드에 대해 공격 페이로드를 전송한다. 세 번째 단계에서 도구는 응답을 분석하여 공격이 성공했는지 확인한다. 예를 들어 XSS 테스트에서는 스크립트 태그가 응답에 그대로 반영되면 취약점이 확인되고, SQL 주입 테스트에서는 SQL 오류 메시지나 OR '1'='1' 조건에 따른 비정상적 데이터 반환으로 취약점이 확인된다. 발견된 취약점은 URL, 파라미터, 공격 페이로드와 함께 보고서로 정리된다.
SAST vs DAST 비교
SAST와 DAST는 서로 다른 특성을 가지고 있으며, 함께 사용될 때 가장 효과적이다.
| 비교 항목 | SAST | DAST |
|---|---|---|
| 분석 시점 | 코드 작성/컴파일 시 (Shift Left) | 애플리케이션 실행 시 |
| 테스트 방식 | 화이트박스 (코드 접근) | 블랙박스 (코드 접근 불필요) |
| 발견 취약점 | 코드 패턴 기반 (취약한 함수 사용 등) | 런타임 동작 기반 (입력/출력 검증) |
| 장점 | 조기 발견, 코드 라인 직접 제시, CI/CD 친화 | 실제 공격 유사, FP 낮음, 구현 언어 무관 |
| 한계 | FP 높음, 실행 환경 분석 불가 | 내부 코드 경로 일부만 테스트, 느림 |
| 주요 탐지 | 버퍼 오버플로우, SQL 주입 패턴, 하드코딩 | XSS, SQL 주입(런타임), CSRF, 인증 문제 |
- 📢 섹션 요약 비유: SAST는 건축 설계도(코드)를 보면서 구조적弱点を찾는 것과 같고, DAST는 완공된 건물(실행 중인 앱)을 흔들어보며弱点を测试하는 것과 같다. 설계도 검토(SAST)만으로는 실제 건물이风吹에 어떻게 흔들리는지 알 수 없고, 실제 테스트(DAST)만으로는弱点を구조적으로理解하기 어려우므로, 둘 다 함께 하는 것이 가장 효과적이다.
Ⅲ. 융합 비교 및 다각도 분석
CI/CD 파이프라인 통합
SAST와 DAST는 DevSecOps의 핵심 요소로 CI/CD 파이프라인에 통합되어自动化된다. 각 단계에서 적절한 보안 게이트가 적용되어, 보안 결함이 일정 수준 이상이면 빌드 또는 배포가 실패한다.
┌─────────────────────────────────────────────────────────────────────┐
│ DevSecOps 파이프라인에서의 SAST/DAST 배치 │
├─────────────────────────────────────────────────────────────────────┤
│
│ [Build Stage] │
│ - SAST (IDE 플러그인, 커밋 시): 개발자가 코딩 시 실시간 경고 │
│ - SAST (CI/CD 빌드 시): 전체 코드베이스 스캔, Critical/High Blocking │
│
│ [Test Stage] │
│ - DAST (스테이징): 실행 중인 애플리케이션 스캔 │
│ - Interactive AST (IAST): 런타임에 에이전트로 섀도잉하여 탐지 │
│
│ [Deploy Stage] │
│ - DAST (프로덕션 전): 마지막 스캔으로 프로덕션 직전 최종 확인 │
│ - CSPM (클라우드): 클라우드 설정 검증 │
│
│ [Monitor Stage] │
│ - RASP (Runtime Application Self-Protection): 런타임 방어 │
│ - CWPP (Cloud Workload Protection): 프로덕션 워크로드 모니터링 │
│
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] IDE 플러그인 형태의 SAST는 개발자가 코드를 작성하는 시점에 실시간으로 보안 경고를 제공하여, 취약점이 코딩 단계에서바로修正되도록 한다. CI/CD 빌드 시에는 전체 코드베이스를 대상으로 SAST를 수행하여 Critical/High 수준의 취약점이 발견되면 빌드를 실패시킨다. Test Stage에서 DAST는 스테이징 환경에 배포된 실행 중인 애플리케이션을 대상으로 스캔을 수행한다. IAST(Interactive AST)는 런타임 에이전트를 통해 애플리케이션의 실제 실행을 섀도잉하면서 취약점을 탐지하며, SAST와 DAST의 중간적 특성을 가진다. Deploy Stage에서는 프로덕션 배포 직전에 DAST를 마지막으로 수행하여 프로덕션 환경에서도 취약점이 없도록 확인한다.
과목 융합 관점
- 소프트웨어 공학: SAST/DAST는 Agile/DevOps 환경의 CI/CD 파이프라인에 자연스럽게 통합되어, 보안을 개발 속도와 분리하지 않는 DevSecOps 실천의核心技术이다.
- 컴플라이언스: PCI DSS 6.6, HIPAA 45 CFR 164.308(a)(1), GDPR 등의 규제에서 정기적인 애플리케이션 보안 테스트를 요구하며, SAST/DAST가 이를 충족하는 수단이다.
- 컴퓨터 과학: SAST는 컴파일러 기술(파싱, 데이터 흐름 분석)에 기반하므로, 최신 프로그래밍 언어와 프레임워크 지원을 위해서는 분석 엔진의 지속적인 업데이트가 필요하다.
Ⅳ. 실무 적용 및 기술사적 판단
실무 시나리오
-
시나리오 — SonarQube 기반 SAST 도입: Spring Boot 기반 마이크로서비스에 SonarQube를 도입하여 GitLab CI/CD에 통합하고, 코드 커밋 시 SonarQube 스캔을 실행하여 Critical/High 취약점 발견 시 빌드를 실패시키고, 개발자들이 취약점 dashboard에서 직접 이슈를 할당받아修正하는 프로세스 구축.
-
시나리오 — OWASP ZAP 기반 DAST 도입: Kubernetes에 배포된 API 서비스에 OWASP ZAP을 통합하여, 프로덕션 전 스캔을自動 실행하고, 发现된 취약점을 Jira 티켓으로 생성하여 보안 팀이 triage하는workflow 구축.
도입 체크리스트
- 기술적: SAST 도구가 CI/CD 파이프라인에 통합되어 있는가? DAST가 스테이징 환경에서 정기적으로 실행되고 있는가?
- 조직적: SAST/DAST 경보에 대한 triage 프로세스가 수립되어 있는가?
안티패턴
-
SAST 경고 과다: 규칙을 세밀하게 tuning하지 않으면 수천 개의 FP(가양성) 경고가 발생하여 개발자들이警鐘疲劳에 걸린다.
-
빌드 실패 없는 SAST: SAST에서 Critical 취약점을 발견해도 빌드가 계속되면, 개발자들이警鐘을 무시하게 된다.
-
DAST 속도 문제: DAST는 스캔 시간이 길어 CI/CD 파이프라인의 병목이 될 수 있으므로, 목표 지정을 통해 효율적으로 운영해야 한다.
-
📢 섹션 요약 비유: SAST/DAST의 CI/CD 통합은 공장의 품질 관리 라인과 같다. 제품이 생산 라인에 들어가기 전(SAST)에는 설계도를 보고 문제가 있으면 바로 잡고, 제품이 완성되어 출고되기 전(DAST)에는 실제 작동 테스트를 해서弱점을 잡는다. 어느 한 단계라도 통과하지 못하면 제품이 출고되지 않아 소비자(사용자)에게 문제가 가는 것을 방지한다.
Ⅴ. 기대효과 및 결론
정량/정성 기대효과
| 구분 | SAST/DAST 미도입 | SAST/DAST 도입 | 개선 효과 |
|---|---|---|---|
| 정량 | 취약점 발견/수정 비용 $1M | $300K | 70% 절감 |
| 정량 | 프로덕션 취약점 20개 | 3개 | 85% 감소 |
| 정성 | 보안 테스트 수동, 지연 | 자동화, 개발 초 기 대응 | 개발 속도 저하 없이 보안 확보 |
미래 전망
AI/ML 기반 SAST/DAST 정확도 향상과, SAST, DAST, IAST, RASP를 통합한 AST(Application Security Testing) 플랫폼의 등장이 예상된다. 또한 GitHub Advanced Security, Snyk, Veracode 등의 클라우드 기반 Application Security Platform이 SaaS 형태로 보편화되어, 조직 내 Application SecurityProgram를 효율적으로管理할 수 있을 것으로 전망된다.
📌 관련 개념 맵 (Knowledge Graph)
| 개념 명칭 | 관계 및 시너지 설명 |
|---|---|
| SAST | 소스 코드 레벨에서 취약점을 탐지하며, CI/CD에 통합되어 Shift Left 보안实践의核心技术이다. |
| DAST | 실행 중인 애플리케이션에 실제 공격을 시뮬레이션하여 취약점을 탐지하며, SAST를補完한다. |
| IAST | 런타임 에이전트로 애플리케이션 실행을 섀도잉하며, SAST와 DAST의 중간적 특성을 가진다. |
| RASP | 프로덕션 환경에서 런타임에 공격을 탐지하고 차단하는 방어 기술으로, DAST를補完한다. |
| DevSecOps | 보안을 Agile/DevOps에 통합하는 실천으로, SAST/DAST의 CI/CD 파이프라인 통합을 통해 실현된다. |
👶 어린이를 위한 3줄 비유 설명
-
SAST는 **장난감 설명서를 보면서"여기 부분은 부러질 수 있겠군"이라고 미리 问题를 알아내는 것과 같아요. 설명서를 세밀히 보면 어떤 连接가 취약한지 코딩 단계에서 알 수 있어요.
-
DAST는 **완성된 장난감으로 직접 놀아보면서"이 부분이 자주 부서지네"라고 问题를 찾아내는 것과 같아요. 실제로 움직여보면서弱点を발견해요.
-
컴퓨터 앱도 마찬가지예요. 앱을 만들기 전에コード(설계도)를 보고 SAST로弱점을찾고, 앱을 만들어서 실제로 작동시켜보면서 DAST로弱점을찾으면,完成된 앱에 문제가 있을 가능성을 크게 줄일 수 있어요.