CI/CD 파이프라인의 수문장: SAST와 DAST 완벽 가이드

최신 소프트웨어 개발의 핵심은 ‘속도’와 ‘안정성’입니다. 하루에도 몇 번씩 코드를 통합하고 배포하는 CI/CD(Continuous Integration/Continuous Delivery, 지속적 통합/지속적 제공) 환경에서 보안은 더 이상 개발 마지막 단계에 고려하는 대상이 아닙니다. 이제 보안은 개발의 모든 과정에 자연스럽게 녹아들어야 하는 필수 요소, 즉 ‘DevSecOps’의 시대가 되었습니다.

이 DevSecOps의 핵심적인 역할을 수행하는 두 가지 자동화된 보안 테스트 방법론이 바로 SAST와 DAST입니다. 이들은 CI/CD 파이프라인의 든든한 수문장이 되어 코드 변경 사항이 사용자에게 전달되기 전에 잠재적인 보안 위협을 탐지하고 차단합니다.

이번 블로그 포스팅에서는 SAST와 DAST가 각각 무엇인지, 어떤 차이점이 있으며 CI/CD 파이프라인에서 어떻게 활용되어 우리의 애플리케이션을 더 안전하게 만드는지 상세히 알아보겠습니다.

 

https://fadeevab.com/ci-cd-sast-challenges/

 

코드의 뼛속까지 들여다보는 정밀 검사: SAST (정적 애플리케이션 보안 테스팅)

SAST(Static Application Security Testing), 즉 정적 애플리케이션 보안 테스팅은 이름 그대로 애플리케이션을 실행하지 않은 정적인 상태에서 소스 코드 자체를 분석하여 보안 취약점을 찾아내는 '화이트박스 테스팅' 방법론입니다. 건축으로 비유하자면, 건물이 완공되기 전에 설계도를 꼼꼼히 검토하여 구조적인 결함이나 설계 오류를 미리 찾아내는 과정과 같습니다.

 

SAST는 어떻게 작동할까요?

SAST 도구는 소스 코드, 바이트 코드 또는 컴파일된 바이너리 코드를 한 줄 한 줄 분석합니다. 미리 정의된 보안 규칙(Rule Set)을 기반으로 코드의 흐름과 데이터의 흐름을 추적하며 다음과 같은 잠재적인 취약점을 탐지합니다.

• SQL 인젝션: 사용자의 입력값이 검증 없이 데이터베이스 쿼리에 그대로 사용되는 경우
• 크로스 사이트 스크립팅(XSS): 악의적인 스크립트가 웹 페이지에 삽입되어 다른 사용자의 브라우저에서 실행될 수 있는 경우
• 버퍼 오버플로우: 할당된 메모리 공간을 초과하는 데이터가 입력되어 시스템이 비정상적으로 동작할 수 있는 경우
• 코딩 표준 및 규정 준수 위반: 특정 보안 코딩 가이드라인을 따르지 않은 경우

CI/CD 파이프라인에서의 SAST

SAST는 개발 수명 주기(SDLC)의 가장 이른 단계에 통합되는 것이 이상적입니다.

• IDE 통합: 개발자가 코드를 작성하는 순간에 바로 피드백을 받을 수 있도록 IDE(통합 개발 환경) 플러그인 형태로 제공됩니다.
• 커밋(Commit) 단계: 개발자가 Git과 같은 버전 관리 시스템에 코드를 커밋할 때 자동으로 SAST 스캔을 트리거합니다.
• 빌드(Build) 단계: 소스 코드를 컴파일하고 빌드하는 과정에서 SAST를 실행하여, 취약점이 발견되면 빌드를 실패시키고 개발자에게 즉시 알립니다.

 

이를 통해 보안 취약점이 개발 초기 단계에서 발견되고 수정되므로, 나중에 수정하는 것보다 훨씬 적은 비용과 노력으로 높은 보안 품질을 유지할 수 있습니다. (Shift-Left 원칙)

 

장점:

• 개발 초기 단계에서 신속하게 취약점을 발견하고 수정할 수 있습니다.
• 소스 코드에 직접 접근하므로 취약점의 정확한 위치(파일 및 라인 번호)를 파악하기 쉽습니다.
• 런타임 환경 없이도 테스트가 가능합니다.

단점:

• 실행 환경의 설정 오류나 다른 시스템과의 상호작용에서 발생하는 취약점은 탐지할 수 없습니다.
• 컴파일된 라이브러리나 프레임워크 자체의 취약점 분석에는 한계가 있습니다.
• 미탐(False Negative)은 적지만, 실제로는 위협이 아닌 코드를 취약점으로 판단하는 오탐(False Positive)이 발생할 수 있습니다.

실제 공격자의 눈으로 애플리케이션을 시험하다: DAST (동적 애플리케이션 보안 테스팅)

DAST(Dynamic Application Security Testing), 즉 동적 애플리케이션 보안 테스팅은 SAST와 정반대의 접근 방식을 취합니다. 실행 중인 애플리케이션을 대상으로 외부에서 실제 공격과 유사한 요청을 보내고, 그 반응을 분석하여 보안 취약점을 찾아내는 '블랙박스 테스팅' 방법론입니다. 이는 건물이 완공된 후, 전문 안전 진단팀이 직접 건물을 방문하여 방화 시설, 비상 대피로, 내진 설계 등을 점검하고 모의 재난 상황을 연출하여 문제점을 찾는 것과 같습니다.

 

DAST는 어떻게 작동할까요?

DAST 도구는 애플리케이션의 내부 구조나 소스 코드를 전혀 알지 못한 상태에서 작동합니다. 웹 스캐너처럼 URL을 크롤링하며 애플리케이션의 모든 페이지와 기능을 탐색하고, 의도적으로 비정상적인 입력값이나 악의적인 스크립트를 포함한 HTTP 요청을 전송합니다. 그리고 서버의 응답을 분석하여 다음과 같은 취약점을 식별합니다.

• 서버 설정 및 구성 오류: 불필요한 포트가 열려 있거나, 디렉토리 리스팅이 활성화된 경우
• 인증 및 세션 관리 취약점: 로그아웃 후에도 세션이 유지되거나, 다른 사용자의 권한을 획득할 수 있는 경우
• 실행 환경에서만 발견 가능한 로직 오류
• SQL 인젝션, XSS 등 외부 입력을 통해 트리거될 수 있는 다양한 취약점

 

CI/CD 파이프라인에서의 DAST

DAST는 애플리케이션이 실제 구동되는 환경이 필요하므로, 일반적으로 CI/CD 파이프라인의 후반부에 위치합니다.

• 테스트/스테이징 환경 배포 후: 애플리케이션이 빌드되어 테스트 서버나 스테이징 환경에 배포된 직후, DAST 스캔을 자동으로 실행합니다.
• QA(품질 보증) 단계: 기능 테스트와 함께 보안 테스트를 병행하는 형태로 진행됩니다.
• 프로덕션 환경 모니터링: 이미 운영 중인 서비스에 대해 주기적으로 DAST 스캔을 수행하여 새로운 위협이나 설정 변경으로 인한 취약점을 탐지합니다.

장점:

• 실제 운영 환경과 유사한 상태에서 테스트하므로, 실제 공격에 노출될 가능성이 높은 취약점을 효과적으로 발견할 수 있습니다.
• 소스 코드에 접근할 필요가 없어 어떤 프로그래밍 언어나 프레임워크로 개발되었는지에 상관없이 테스트가 가능합니다.
• 오탐(False Positive)이 상대적으로 적습니다.

단점:

• 취약점이 발견되더라도 소스 코드의 정확한 위치를 알려주기 어렵습니다.
• 테스트 속도가 SAST에 비해 느리고, 전체 애플리케이션을 스캔하는 데 많은 시간이 소요될 수 있습니다.
• 개발 수명 주기 후반에 수행되므로, 취약점 수정 비용과 시간이 많이 들 수 있습니다.

 

SAST vs DAST: 우리는 둘 다 필요합니다

특징	SAST (정적 분석)	DAST (동적 분석)
분석 대상	소스 코드, 바이너리 (실행 전)	실행 중인 애플리케이션
테스팅 관점	화이트박스 (내부 구조 파악)	블랙박스 (외부에서 공격)
주요 CI/CD 단계	커밋, 빌드 (개발 초기)	테스트, 스테이징 (개발 후기)
발견 가능한 취약점	코드 레벨의 오류 (SQL 인젝션, 버퍼 오버플로우 등)	런타임/환경 설정 오류, 인증/세션 문제 등
피드백 속도	빠름	상대적으로 느림
취약점 위치 파악	용이 (파일, 라인 번호)	어려움
장점	조기 발견, 낮은 수정 비용	실제적인 위협 탐지, 낮은 오탐율

 

SAST와 DAST는 서로 경쟁하는 관계가 아니라, 각자의 장단점을 보완하며 애플리케이션의 보안을 다각도로 강화하는 상호 보완적인 관계입니다. 마치 건강검진 시 혈액검사(SAST)로 잠재적인 질병의 징후를 찾고, 내시경이나 CT 촬영(DAST)으로 실제 장기의 상태를 확인하는 것과 같습니다.

성숙한 DevSecOps 환경에서는 CI/CD 파이프라인의 초반에는 SAST를 통해 빠르게 코드 레벨의 실수를 바로잡고, 후반에는 DAST를 통해 실제 운영 환경에서 발생할 수 있는 위협을 꼼꼼하게 점검하는 다층적인 보안 전략을 구축합니다.

 

결론

CI/CD 환경에서의 자동화된 보안 테스트는 이제 선택이 아닌 필수입니다. SAST는 개발자에게 가장 가까운 곳에서 코드의 보안 품질을 책임지고, DAST는 사용자와 가장 가까운 곳에서 실제적인 공격 위협을 막아냅니다. 이 두 가지 강력한 도구를 CI/CD 파이프라인에 전략적으로 통합함으로써, 우리는 더 빠르고, 더 안정적이며, 무엇보다 더 안전한 소프트웨어를 지속적으로 제공할 수 있을 것입니다.