핵심 인사이트
- 본질: SAST (Static Application Security Testing)는 코드 실행 없이 소스를 분석하고, DAST (Dynamic Application Security Testing)는 실행 중인 애플리케이션에 실제 공격을 시도한다 — 두 방식은 상호 보완적이다.
- 가치: SAST는 오탐(False Positive)이 많고 DAST는 미탐(False Negative)이 많으므로, 두 도구를 DevSecOps 파이프라인에 조합하여 각자의 약점을 보완하는 것이 핵심 설계 원칙이다.
- 판단 포인트: 기술사 답안에서는 "SAST/DAST 비교 → 오탐·미탐 트레이드오프 → IAST/RASP 보완 방안 → DevSecOps CI/CD 통합 설계"를 논리적으로 전개하면 고득점이다.
Ⅰ. 개요 및 필요성
소프트웨어 보안 테스트는 개발 라이프사이클의 어느 단계에서, 어떤 방식으로 수행하느냐에 따라 크게 정적 분석과 동적 분석으로 나뉜다. 전통적으로 보안 테스트는 개발 완료 후 운영 배포 직전에 수행되었으나, 이 시점에서 발견된 취약점은 수정 비용이 매우 크다.
Shift-Left Security(보안 조기 적용) 원칙에 따라 SAST는 개발 단계(IDE 수준)부터 취약 코드 패턴을 탐지하고, DAST는 QA/스테이징 단계에서 실행 중 취약점을 검증한다. 두 방식을 CI/CD (Continuous Integration/Continuous Delivery) 파이프라인에 자동화 게이트로 통합하는 것이 DevSecOps의 핵심 실천이다.
SAST와 DAST 외에도 IAST (Interactive Application Security Testing)는 에이전트를 애플리케이션 내부에 삽입하여 실행 중 내부 데이터 흐름을 실시간 분석하는 하이브리드 방식이며, RASP (Runtime Application Self-Protection)는 공격 감지 시 애플리케이션 스스로 방어 동작을 수행하는 런타임 보호 기술이다.
📢 섹션 요약 비유: SAST는 출판 전 원고를 교정 편집자가 읽으며 문법 오류를 잡는 것이고, DAST는 출판된 책을 실제 독자에게 배포하고 독자 반응을 통해 오류를 발견하는 것이다.
Ⅱ. 아키텍처 및 핵심 원리
SAST/DAST DevSecOps 파이프라인 통합 구조
┌────────────────────────────────────────────────────────────────┐
│ DevSecOps 보안 테스트 파이프라인 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 개발자 IDE 코드 커밋 빌드/CI │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ SAST │──────▶│ SAST │─────▶│ SAST (전체 스캔) │ │
│ │ 플러그인 │ │ Pre-Hook │ │ + SCA (OSS 분석) │ │
│ │ (실시간) │ │ │ └────────┬─────────┘ │
│ └──────────┘ └──────────┘ │ │
│ ▼ │
│ 스테이징 배포 QA 테스트 │ │
│ ┌──────────────┐ ┌──────────────────────┐ │ │
│ │ DAST │◀───│ 배포 완료 │◀─┘ │
│ │ (자동화 스캔) │ └──────────────────────┘ │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 취약점 없음 │ │ 취약점 탐지 │ │ IAST (런타임 │ │
│ │ → 운영 배포 │ │ → 빌드 차단 │ │ 에이전트) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
└────────────────────────────────────────────────────────────────┘
SAST 주요 탐지 취약점 유형
| 취약점 유형 | 탐지 방법 | 대표 도구 규칙 |
|---|---|---|
| SQL 인젝션 | 사용자 입력이 쿼리에 직접 연결되는 데이터 흐름 분석(Taint Analysis) | SonarQube SQL Injection |
| XSS | 비정화 사용자 입력이 HTML 출력에 연결되는 흐름 | Checkmarx XSS Detection |
| 하드코딩 비밀번호 | 문자열 리터럴 패턴 매칭 | FindBugs HardCodedPassword |
| 취약 암호화 | 금지 알고리즘(MD5, DES, SHA-1) 호출 탐지 | SonarQube InsecureAlgorithm |
| 경로 순회 | 파일 경로 연결 시 입력값 미검증 | CodeQL PathInjection |
| SSRF | 외부 URL을 그대로 요청하는 패턴 | Semgrep SSRF Rules |
📢 섹션 요약 비유: SAST는 소스코드 속 지뢰를 지도를 보며 찾는 것이고, DAST는 실제 땅을 걸어보며 지뢰를 밟아 위치를 확인하는 것이다.
Ⅲ. 비교 및 연결
| 구분 | SAST | DAST | IAST | RASP |
|---|---|---|---|---|
| 분석 시점 | 코드 작성/빌드 단계 | 실행 중 (QA/운영) | 실행 중 (내부) | 런타임 (운영) |
| 접근 방식 | 화이트박스 (소스 접근) | 블랙박스 (외부 공격) | 그레이박스 (에이전트) | 인라인 방어 |
| 오탐(False Positive) | 높음 (15~40%) | 낮음 | 낮음 | 매우 낮음 |
| 미탐(False Negative) | 중간 | 높음 (실행 흐름 제한) | 낮음 | 낮음 |
| 언어 의존성 | 있음 (언어별 도구) | 없음 (프로토콜 수준) | 있음 (에이전트) | 있음 |
| 대표 도구 | SonarQube, Checkmarx, Veracode | OWASP ZAP, Burp Suite | Contrast Security | Sqreen, Imperva |
| 비용 | 라이선스 비용 | 환경 구성 비용 | 에이전트 비용 | 런타임 오버헤드 |
| CI/CD 통합 | 용이 (빌드 시간) | 스테이징 환경 필요 | 테스트 환경 필요 | 운영 환경 적용 |
오탐(False Positive)과 미탐(False Negative) 관리 전략
오탐(False Positive): SAST가 취약점이 아닌 것을 취약점으로 보고하는 경우. 개발팀의 경보 피로(Alert Fatigue)를 유발한다. 해결책은 룰셋(Ruleset) 튜닝, 컨텍스트 기반 억제(Suppression), 보안팀 리뷰 프로세스 수립이다.
미탐(False Negative): 실제 취약점을 탐지하지 못하는 경우. DAST는 테스트 시나리오 범위에 포함되지 않은 경로는 놓친다. IAST와의 조합으로 커버리지를 높인다.
📢 섹션 요약 비유: 오탐은 거짓 경보가 너무 많은 화재 감지기처럼 신뢰를 잃게 만들고, 미탐은 실제 불이 나도 울리지 않는 감지기처럼 치명적이다 — 둘 다 균형 있게 관리해야 한다.
Ⅳ. 실무 적용 및 기술사 판단
DevSecOps 보안 게이트 설계 원칙
① SAST는 PR (Pull Request) 생성 시마다 자동 실행하고, Critical/High 취약점 탐지 시 PR 머지를 차단한다.
② DAST는 스테이징 배포 후 자동 실행하며, OWASP ZAP 자동화 스캔 결과를 Jira 티켓으로 자동 생성한다.
③ SCA (Software Composition Analysis)를 SAST와 병행하여 OSS 컴포넌트의 알려진 CVE를 함께 탐지한다.
④ IAST 에이전트를 통합 테스트 환경에 배포하여 실제 테스트 트래픽 기반의 정밀 취약점 분석을 수행한다.
⑤ 보안 취약점 트래킹 DB를 구축하여 탐지→분류→수정→재검증의 생명주기를 관리한다.
도구 선정 기준
언어/프레임워크 지원 범위, 오탐률, CI/CD 통합 용이성, 라이선스 비용, 취약점 DB 갱신 주기를 종합 평가하여 선정한다. 중소기업에는 오픈소스 기반의 SonarQube Community + OWASP ZAP 조합이 현실적 출발점이다.
📢 섹션 요약 비유: DevSecOps 보안 게이트는 공항 보안 검색대처럼 — 탑승 전(SAST)에 짐을 검사하고, 게이트에서(DAST) 한 번 더 확인하여 이중으로 안전을 보장한다.
Ⅴ. 기대효과 및 결론
SAST/DAST를 CI/CD에 통합한 DevSecOps 체제는 보안 취약점을 개발 초기에 발견하여 수정 비용을 운영 단계 대비 30~100배 절감한다. 지속적 보안 스캐닝으로 코드 베이스의 보안 품질이 점진적으로 향상되고, 감사 추적 자동화로 컴플라이언스 증거 수집 부담도 경감된다.
미래 방향으로는 AI 기반 취약점 분류(Triage) 자동화가 오탐 처리 효율을 높이고, LLM 기반 코드 생성 취약점 분석 도구가 새로운 보안 패턴을 학습하여 미탐률을 낮추는 방향으로 발전하고 있다. 또한 API 퍼스트(API-First) 아키텍처 확산에 따라 API 전용 DAST 도구(42Crunch, APISec)의 중요성이 높아지고 있다.
📢 섹션 요약 비유: SAST/DAST 통합은 공장에서 제품이 나오기 전(SAST)과 출고 직전(DAST)에 두 번 품질 검사하는 이중 QC 체계와 같다 — 두 관문을 통과한 제품만 고객에게 전달된다.
📌 관련 개념 맵
| 개념 | 설명 | 연관 키워드 |
|---|---|---|
| SAST | 소스코드 정적 보안 분석 | SonarQube, Checkmarx, Taint Analysis |
| DAST | 실행 중 동적 보안 분석 | OWASP ZAP, Burp Suite, 블랙박스 |
| IAST | 에이전트 기반 하이브리드 보안 분석 | 그레이박스, Contrast Security |
| RASP | 런타임 자체 보호 메커니즘 | 인라인 방어, 운영 환경 |
| SCA | 오픈소스 컴포넌트 취약점 분석 | CVE, SBOM, OSS 컴플라이언스 |
👶 어린이를 위한 3줄 비유 설명
- SAST는 놀이공원 개장 전에 놀이기구 설계도를 꼼꼼히 검토해서 위험한 부분을 찾는 것이에요.
- DAST는 실제로 놀이기구를 타보면서 흔들리거나 위험한 곳을 직접 확인하는 것이에요.
- 두 가지를 모두 하면 더 안전한 놀이공원을 만들 수 있는 것처럼, SAST와 DAST를 함께 써야 소프트웨어가 진짜 안전해져요.