보안 사고의 상당수는 코드 자체의 결함이나 취약한 외부 라이브러리에서 시작됩니다. DevSecOps 파이프라인에는 이러한 취약점을 자동으로 찾아내기 위한 세 가지 핵심 스캔 체계가 필요합니다. 각 도구가 무엇을 보는지, 어떤 시점에 실행해야 하는지 정리해요
3대 스캔 체계 비교
보안 스캔은 대상과 방식에 따라 SAST, SCA, DAST로 나뉩니다
| 종류 | 대상 | 시점 | 특징 | 도구 예시 |
|---|---|---|---|---|
| SAST | 소스 코드 | 코드 작성/PR | 코드 내부의 보안 결함 탐지 (정적 분석) | Semgrep, SonarQube |
| SCA | 오픈소스 의존성 | 빌드/CI | 취약한 라이브러리 및 라이선스 위반 탐지 | Trivy, Snyk |
| DAST | 구동 중인 앱 | 배포 후/Staging | 실제 실행 환경의 보안 구멍 탐지 (동적 분석) | OWASP ZAP, StackHawk |
정적 분석 (SAST): 코드의 질을 높이다
SAST(Static Application Security Testing)는 코드를 실행하지 않고 텍스트 그대로 분석합니다. “SQL 인젝션 위험이 있는 쿼리”, “하드코딩된 패스워드” 등을 잡아내는 데 탁월합니다
- 장점: 개발 초기 단계에서 수정 가이드를 줄 수 있어 비용이 매우 저렴합니다
- 단점: 실제로 작동하지 않는 경로에 대해서도 ‘오탐(False Positive)’을 낼 가능성이 있습니다
의존성 스캔 (SCA): 거인의 어깨를 보호하다
현대 애플리케이션의 80% 이상은 오픈소스 라이브러리로 이루어져 있습니다. SCA(Software Composition Analysis)는 우리가 가져다 쓰는 라이브러리(npm, pip, maven 등)에 알려진 취약점(CVE)이 있는지 확인합니다
- SCA의 핵심: 단순히 찾는 것을 넘어, “패치를 위해 버전을 몇으로 올려야 하는가”를 제시하는 것이 중요합니다
- 라이선스 체크: 상업적 이용이 제한된 라이선스가 포함되지 않았는지도 함께 검증합니다
동적 분석 (DAST): 해커의 눈으로 보다
DAST(Dynamic Application Security Testing)는 실제로 배포된 애플리케이션에 해킹 시도와 유사한 요청을 던져 반응을 봅니다
- 검증 대상: 인증 우회, 세션 관리 취약점, 잘못된 HTTP 헤더 설정 등 런타임에만 알 수 있는 문제를 잡습니다
- 통합: 주로 배포 후 Staging 환경에서 자동화된 스크립트로 실행됩니다
핵심 인사이트: 결과보다 '대응'이 중요합니다
스캔 도구를 도입하는 것보다 어려운 것은 "발견된 수많은 취약점을 누가, 언제 고칠 것인가"에 대한 규칙을 세우는 것입니다. 위험도에 따라 수정 기한(SLA)을 정하고, 이를 개발 팀의 작업 백로그에 자연스럽게 포함시키는 프로세스가 DevSecOps의 핵심입니다
파이프라인 통합 전략
모든 스캔을 매번 PR마다 돌리면 개발 속도가 느려집니다. 효율적인 배치는 다음과 같습니다
- IDE/Local: 가벼운 SAST 룰셋으로 실시간 체크
- PR/CI: 필수적인 SAST 및 SCA (Critical/High 취약점 발견 시 빌드 실패)
- Daily Build: 전체 소스에 대한 정밀 스캔 및 DAST 수행
- Production: 배포된 환경에 대한 정기적인 침투 테스트(Pen-test)
정리
- SAST는 코드 내부 결함을, SCA는 외부 의존성 취약점을 잡습니다
- DAST는 실제 구동 환경에서 해커의 관점으로 취약점을 찾습니다
- 취약점 발견보다 수정 프로세스를 자동화하고 제도화하는 것이 더 중요합니다
- 각 단계에 맞는 도구를 적절히 배치하여 보안 피드백 루프를 완성해야 합니다
다음 글에서는 민감한 데이터를 보호하고 보안 정책을 코드화하는 Secrets 관리와 정책 자동화를 다뤄요