보안

CI/CD 파이프라인에 SAST, DAST 통합: 개발 단계 보안 자동화 실전 가이드

강코의 코딩 일기 2026. 6. 12. 18:15
반응형

개발 단계부터 보안을 강화하고 싶다면? CI/CD 파이프라인에 SAST, DAST를 통합하여 취약점을 자동으로 찾아내는 실무 경험과 노하우를 공유합니다.

안녕하세요! 개발과 보안 사이에서 오늘도 고군분투하는 모든 분들께, 저희 팀이 CI/CD 파이프라인에 SAST와 DAST를 통합하면서 겪었던 실질적인 경험과 노하우를 공유하고자 합니다. 개발 속도는 점점 빨라지는데, 보안 취약점은 늘 골칫덩어리죠. 혹시 "개발 다 끝나고 배포 직전에야 보안 검토를 시작해서 문제 생기면 어쩌지?"라는 걱정을 해본 적 있으신가요? 저희도 그랬습니다. 하지만 개발 단계부터 보안을 자동화하면서 이런 걱정을 크게 덜어낼 수 있었습니다. 이 글이 여러분의 개발 보안 여정에 작은 도움이 되기를 바랍니다.

대부분의 개발 팀은 기능 구현과 성능 개선에 집중하느라 보안을 뒷전으로 미루기 쉽습니다. 하지만 아시다시피, 취약점은 개발 초기 단계에서 발견할수록 수정 비용이 기하급수적으로 줄어듭니다. 프로젝트 막바지에 중대한 보안 결함이 발견되면, 배포 일정이 틀어지는 것은 물론이고 재작업에 엄청난 리소스가 소모되죠. 그래서 저희는 "Shift Left Security" 원칙을 도입, CI/CD 파이프라인에 보안 취약점 분석 도구들을 적극적으로 통합하기로 결정했습니다. 직접 적용해 본 결과, 초기 투자 비용과 학습 곡선은 있었지만, 장기적으로는 훨씬 효율적이고 안전한 개발 프로세스를 구축할 수 있었습니다.

📑 목차

왜 CI/CD에 보안을 통합해야 하는가? 개발 초기 단계의 중요성

소프트웨어 개발 생명 주기(SDLC)에서 보안 취약점을 가능한 한 일찍 발견하고 수정하는 것은 매우 중요합니다. 이를 "Shift Left Security"라고 부르죠. 왜 그럴까요? 간단한 예를 들어보겠습니다.

  • 코딩 단계에서 발견된 취약점: 개발자가 즉시 수정 가능. 시간/비용 거의 없음.
  • 테스트 단계에서 발견된 취약점: 기능 수정 및 재테스트 필요. 시간/비용 중간.
  • 운영 환경에서 발견된 취약점: 긴급 패치, 서비스 중단 위험, 고객 신뢰 손상. 시간/비용 막대함.

실제로 한 연구에 따르면, 개발 초기 단계에서 취약점을 발견하고 수정하는 비용은 운영 단계에 비해 최대 100배 이상 저렴하다고 합니다. 저희 팀의 경우에도, 과거에는 QA나 보안팀의 최종 검수 단계에서 SQL 인젝션이나 XSS 같은 중대한 취약점이 발견되어 배포가 지연되거나, 심지어는 이미 배포된 서비스에서 긴급 패치를 해야 했던 아찔한 경험들이 있었습니다. 이런 경험을 통해 개발 초기부터 보안을 자동화하는 것이 필수적이라는 것을 깨달았습니다.

CI/CD 파이프라인은 코드 변경이 발생할 때마다 자동으로 빌드, 테스트, 배포를 수행하는 프로세스입니다. 여기에 보안 취약점 분석 도구를 통합하면, 개발자가 코드를 커밋할 때마다, 혹은 정기적인 빌드 시마다 자동으로 보안 검사를 수행할 수 있게 됩니다. 이는 개발자가 미처 인지하지 못했던 잠재적인 보안 위험을 빠르게 감지하고, 수정할 기회를 제공합니다. 결과적으로 보안 결함이 없는 깨끗한 코드를 유지하고, 안전한 소프트웨어를 더 빠르게 시장에 출시할 수 있게 되는 것이죠.

SAST와 DAST, 무엇이 다르고 어떻게 활용해야 할까?

CI/CD에 보안 취약점 분석을 통합할 때 가장 먼저 고려하는 것이 바로 SAST(Static Application Security Testing)와 DAST(Dynamic Application Security Testing)입니다. 이 두 가지는 서로 다른 접근 방식으로 취약점을 찾아내며, 상호 보완적으로 사용될 때 가장 큰 효과를 발휘합니다.

SAST: 코드 속 잠재적 취약점 발견

SAST는 정적 애플리케이션 보안 테스팅의 약자로, 애플리케이션이 실행되지 않은 상태에서 소스 코드, 바이너리 코드 또는 바이트 코드를 분석하여 보안 취약점을 찾아냅니다. 쉽게 말해, 코드 자체의 논리적인 오류나 보안 약점을 검사하는 방식입니다. 컴파일 타임에 주로 수행되며, 개발 초기 단계에서 빠르게 피드백을 받을 수 있다는 장점이 있습니다.

  • 장점: 개발 초기 단계에서 취약점 발견 가능, 코드의 특정 위치를 정확히 지목 가능, OWASP Top 10 같은 알려진 취약점 유형에 강함.
  • 단점: 실제 실행 환경의 취약점(환경 설정 오류 등)은 감지하기 어려움, 오탐(False Positive) 발생 가능성 존재.
  • 주요 도구: SonarQube, Checkmarx, Fortify SCA, Coverity 등.

DAST: 실행 중인 애플리케이션의 취약점 발견

DAST는 동적 애플리케이션 보안 테스팅의 약자로, 실제로 실행 중인 애플리케이션을 대상으로 외부에서 공격을 시도하는 방식으로 취약점을 찾아냅니다. 웹 크롤링을 통해 애플리케이션의 모든 경로를 탐색하고, 다양한 공격 패턴을 주입하여 응답을 분석합니다. 이는 실제 공격자가 활용할 수 있는 취약점을 발견하는 데 특화되어 있습니다.

  • 장점: 실제 운영 환경에서의 취약점 발견 가능, 환경 설정 오류나 라이브러리 취약점 등 실제 공격에 노출될 수 있는 문제점 파악, 오탐이 상대적으로 적음.
  • 단점: 애플리케이션이 실행 가능한 상태여야 함, 테스트 완료까지 시간이 오래 걸릴 수 있음, 코드의 특정 위치를 정확히 지목하기 어려움.
  • 주요 도구: OWASP ZAP, Burp Suite, Acunetix, Tenable.io Web Application Scanner 등.

두 방식의 차이를 표로 정리하면 다음과 같습니다.

구분 SAST (정적 분석) DAST (동적 분석)
분석 시점 컴파일 전/중 (코드 작성 단계) 런타임 (애플리케이션 실행 단계)
분석 대상 소스 코드, 바이너리 코드 실행 중인 애플리케이션 (URL)
취약점 유형 코드 설계 오류, SQL Injection, XSS, 하드코딩된 비밀번호 등 인증/인가 오류, 세션 관리 취약점, 설정 오류, OWASP Top 10 등
장점 개발 초기 발견, 코드 위치 특정, 전체 코드 커버리지 실제 공격 시나리오 반영, 운영 환경 취약점 발견, 낮은 오탐율
단점 오탐 가능성, 실행 환경 취약점 감지 어려움 애플리케이션 실행 필수, 분석 시간 소요, 코드 위치 특정 어려움

저희 팀에서는 SAST로 개발 초기 단계의 코드 취약점을 빠르게 걸러내고, DAST로 배포 직전의 실제 서비스 환경에서의 취약점을 최종 검증하는 전략을 사용합니다. 이렇게 함으로써 "깊이 있는 방어(Defense in Depth)" 전략을 효과적으로 구현할 수 있었습니다.

CI/CD 파이프라인에 SAST 통합하기 (실전 경험)

저희는 SAST를 CI/CD 파이프라인의 빌드 단계에 통합하여, 코드가 빌드될 때마다 자동으로 보안 검사가 수행되도록 했습니다. 주요 스텝은 다음과 같습니다.

1. SAST 도구 선정 및 연동

저희는 초기에는 오픈소스인 SonarQube를 사용했고, 이후에는 상용 솔루션인 Checkmarx를 도입했습니다. SonarQube는 설치와 관리가 비교적 쉽고 다양한 언어를 지원하여 시작하기 좋았지만, 대규모 프로젝트에서는 분석 속도나 오탐 관리, 고급 리포팅 기능에서 한계를 느끼기도 했습니다. Checkmarx는 더욱 정밀한 분석과 낮은 오탐율, 그리고 개발자 친화적인 인터페이스로 보안 전문가가 아닌 개발자들도 쉽게 결과를 이해하고 조치할 수 있도록 도와주었습니다.

2. CI/CD 파이프라인 연동 설정

저희는 Jenkins를 CI/CD 툴로 사용하고 있습니다. Jenkinsfile에 SonarQube 스캔을 위한 단계를 추가하는 것은 어렵지 않았습니다. 대략적인 스크립트는 다음과 같습니다.


pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git branch: 'main', url: 'https://github.com/your-org/your-repo.git'
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean install -DskipTests' // 예시: Maven 프로젝트 빌드
            }
        }
        stage('SAST Scan with SonarQube') {
            steps {
                withSonarQubeEnv('SonarQubeServer') { // Jenkins에 설정된 SonarQube 서버 이름
                    sh "mvn sonar:sonar \
                        -Dsonar.projectKey=my-java-app \
                        -Dsonar.host.url=$SONAR_HOST_URL \
                        -Dsonar.login=$SONAR_AUTH_TOKEN"
                }
            }
        }
        stage('Quality Gate Check') {
            steps {
                timeout(time: 5, unit: 'MINUTES') {
                    waitForQualityGate abortPipeline: true
                }
            }
        }
        // ... 나머지 테스트 및 배포 단계 ...
    }
}

위 스크립트는 Maven 프로젝트를 SonarQube로 분석하는 예시입니다. `waitForQualityGate`를 통해 SonarQube의 품질 게이트(Quality Gate) 기준을 통과하지 못하면 파이프라인이 중단되도록 설정했습니다. 이 부분이 핵심입니다. 보안 취약점이 일정 수준 이상으로 발견되면 다음 단계로 넘어가지 못하도록 강제함으로써, 개발자들이 보안 이슈를 간과하지 않도록 유도했습니다.

3. 오탐(False Positive) 관리 및 정책 수립

SAST는 종종 오탐을 발생시킵니다. 실제 취약점이 아님에도 불구하고 도구가 경고를 띄우는 경우죠. 초기에는 이 오탐 때문에 개발자들이 불만을 표하기도 했습니다. 저희는 이를 해결하기 위해 다음의 방법을 사용했습니다.

  • 정기적인 오탐 분석 및 제외: 보안팀과 개발팀이 협력하여 오탐을 분석하고, 필요 없는 규칙은 비활성화하거나 예외 처리했습니다.
  • 커스텀 규칙 생성: 프로젝트 특성에 맞는 보안 규칙을 직접 정의하여 불필요한 경고를 줄였습니다.
  • 베이스라인 설정: 기존 코드의 취약점은 베이스라인으로 설정하고, 이후 새로 발생하는 취약점에만 집중하도록 했습니다.

이러한 노력을 통해 SAST의 신뢰도를 높이고 개발자들의 피로도를 줄일 수 있었습니다. 실제로 SAST 통합 후, 개발 초기 단계에서 발견되는 중대 보안 취약점의 수가 약 40% 감소했습니다.

CI/CD 파이프라인에 DAST 통합하기 (실전 경험)

DAST는 애플리케이션이 실제로 실행되는 환경에서 동작해야 하므로, 주로 스테이징(Staging) 환경이나 테스트 환경에 배포된 후에 수행하도록 파이프라인을 구성했습니다.

1. DAST 도구 선정 및 환경 구축

저희는 오픈소스인 OWASP ZAP과 상용 솔루션인 Acunetix를 검토했습니다. OWASP ZAP은 강력한 기능을 제공하지만, CI/CD 연동 및 대규모 스캔 관리에는 추가적인 스크립트 작업이 많이 필요했습니다. Acunetix는 REST API를 통해 CI/CD 툴과 쉽게 연동할 수 있었고, 스캔 결과를 통합 대시보드에서 관리할 수 있다는 점이 매력적이었습니다. 저희는 테스트 환경에 배포가 완료된 후 Acunetix API를 호출하여 스캔을 시작하도록 했습니다.

2. CI/CD 파이프라인 연동 설정

Jenkinsfile에서 DAST 스캔을 트리거하는 예시는 다음과 같습니다. 이 단계는 SAST 이후, 통합 테스트와 함께 진행되거나 그 직후에 진행됩니다.


pipeline {
    agent any
    stages {
        // ... SAST 및 다른 테스트 단계 ...

        stage('Deploy to Staging') {
            steps {
                sh 'kubectl apply -f k8s/staging-deployment.yaml' // 예시: Kubernetes 배포
                sh 'sleep 60' // 서비스가 완전히 구동될 때까지 대기
            }
        }
        stage('DAST Scan with Acunetix') {
            steps {
                withCredentials([string(credentialsId: 'ACUNETIX_API_KEY', variable: 'ACUNETIX_API_KEY')]) {
                    sh "curl -X POST \
                        -H 'X-Auth: $ACUNETIX_API_KEY' \
                        -H 'Content-Type: application/json' \
                        -d '{\"target_id\": \"your-acunetix-target-id\", \"profile_id\": \"your-acunetix-scan-profile-id\"}' \
                        https://your-acunetix-instance.com/api/v1/scans"
                    
                    // 스캔 완료 대기 및 결과 확인 로직 (Acunetix API를 통해 구현)
                    // 예: 주기적으로 GET /api/v1/scans/{scan_id} 호출하여 상태 확인
                    // 취약점 발견 시 파이프라인 실패 처리
                }
            }
        }
        // ... 나머지 배포 단계 ...
    }
}

위 예시에서는 Acunetix의 REST API를 사용하여 스캔을 시작하는 간단한 `curl` 명령어를 보여줍니다. 실제 파이프라인에서는 스캔이 완료될 때까지 대기하고, 스캔 결과에서 중요도 높은 취약점(Critical, High)이 발견되면 파이프라인을 실패 처리하도록 로직을 추가했습니다. 이는 취약점이 있는 상태로 운영 환경에 배포되는 것을 방지하는 중요한 안전장치입니다.

3. 스캔 환경 및 데이터 관리

DAST의 경우, 실제 사용자와 유사한 환경에서 스캔을 수행하는 것이 중요합니다. 저희는 다음과 같은 점들을 고려했습니다.

  • 전용 테스트 환경: DAST 스캔을 위한 독립적인 스테이징 환경을 구축하여 운영 환경에 영향을 주지 않도록 했습니다.
  • 인증 스캔: 로그인 기능이 있는 애플리케이션의 경우, DAST 도구가 인증 과정을 거쳐 내부 페이지까지 스캔할 수 있도록 계정 정보를 설정했습니다.
  • 테스트 데이터: 스캔 중 데이터베이스에 불필요한 데이터가 쌓이거나, 중요한 테스트 데이터가 손상되지 않도록 적절한 테스트 데이터를 준비했습니다.

DAST 통합 후, 실제 운영 환경에서 발생할 수 있는 인증/인가 관련 취약점이나 서버 설정 오류와 같은 문제들을 배포 전에 찾아낼 수 있었고, 이는 서비스의 안정성과 보안 수준을 크게 향상시켰습니다.

SAST와 DAST 통합의 실제 효과와 고려사항

SAST와 DAST를 CI/CD 파이프라인에 통합한 결과, 저희 팀은 여러 가지 긍정적인 변화를 경험했습니다. 하지만 몇 가지 고려해야 할 점도 있었습니다.

실제 효과

  1. 취약점 발견율 및 수정 효율성 증대: 개발 초기 단계에서 SAST가 코드 취약점을 빠르게 발견하고, DAST가 실제 동작 환경의 취약점을 검증함으로써 전반적인 취약점 발견율이 30% 이상 증가했습니다. 또한, 문제 발생 시 수정까지 걸리는 시간(MTTR, Mean Time To Repair)이 크게 단축되어 수정 비용이 절반 이상 절감되었습니다.
  2. 개발자들의 보안 인식 향상: 파이프라인에서 보안 검사가 자동으로 수행되고, 품질 게이트를 통과하지 못하면 다음 단계로 넘어갈 수 없게 되면서 개발자들은 자연스럽게 보안 코딩 습관을 기르게 되었습니다. 직접 취약점 리포트를 확인하고 수정하는 과정에서 보안에 대한 이해도가 높아졌습니다.
  3. 규제 준수 및 컴플라이언스 강화: ISO 27001, GDPR 등 다양한 보안 규제 및 컴플라이언스 요구사항을 충족하는 데 필요한 증적 자료를 자동으로 생성할 수 있어, 보안 감사 대응에도 큰 도움이 되었습니다.
  4. DevSecOps 문화 정착: 개발(Dev), 보안(Sec), 운영(Ops) 팀이 협력하여 보안을 개발 프로세스의 일부로 녹여내는 DevSecOps 문화를 효과적으로 정착시킬 수 있었습니다.

고려사항 및 도전 과제

  1. 초기 설정 및 유지보수 비용: SAST/DAST 도구 도입 및 CI/CD 파이프라인 연동에는 초기 설정 비용과 전문가의 도움이 필요할 수 있습니다. 또한, 도구 업데이트, 규칙 관리, 오탐 처리 등 지속적인 유지보수 노력도 중요합니다.
  2. 분석 시간 및 성능 저하: 특히 대규모 프로젝트의 경우, SAST/DAST 스캔에 상당한 시간이 소요되어 CI/CD 파이프라인의 전체 실행 시간이 길어질 수 있습니다. 이를 최적화하기 위해 증분 스캔(Incremental Scan) 활용, 스캔 대상 범위 조정, 병렬 처리 등을 고려해야 합니다.
  3. 오탐(False Positive) 관리: SAST는 특히 오탐이 발생하기 쉽습니다. 오탐을 적절히 관리하지 않으면 개발자들의 불신을 초래하고 생산성을 저해할 수 있습니다. 보안팀과 개발팀 간의 긴밀한 협의와 지속적인 규칙 튜닝이 필수적입니다.
  4. 개발자 교육 및 문화 정착: 단순히 도구를 도입하는 것을 넘어, 개발자들이 보안 취약점을 이해하고 스스로 해결할 수 있도록 지속적인 보안 교육과 문화적인 지원이 필요합니다. "보안은 개발자의 책임"이라는 인식을 심어주는 것이 중요합니다.

성공적인 DevSecOps를 위한 추가 팁

저희 팀이 SAST와 DAST 통합을 성공적으로 이끌 수 있었던 몇 가지 추가적인 팁을 공유합니다.

  • 위협 모델링(Threat Modeling) 도입: 개발 초기 단계에서 애플리케이션의 잠재적인 위협 요소를 식별하고 분석하는 위협 모델링을 도입했습니다. 이는 SAST/DAST가 발견하지 못하는 비즈니스 로직 취약점이나 설계상 보안 결함을 찾아내는 데 큰 도움이 됩니다.
  • 소프트웨어 구성 분석(SCA) 활용: SAST/DAST 외에도, 프로젝트에 사용되는 오픈소스 라이브러리의 취약점을 검사하는 SCA(Software Composition Analysis) 도구를 함께 활용했습니다. 의존성 취약점은 전체 취약점의 상당 부분을 차지하며, 이를 자동화된 방식으로 관리하는 것이 중요합니다.
  • 정책 코드로 관리(Policy as Code): 보안 정책을 코드로 정의하고 버전 관리 시스템에 통합하여, 모든 팀원이 동일한 보안 기준을 따르도록 했습니다. 이는 보안 정책의 일관성을 유지하고, 자동화된 검증을 가능하게 합니다.
  • 보안 챔피언 프로그램: 각 개발 팀 내에서 보안에 관심이 많고 전문 지식을 가진 개발자를 '보안 챔피언'으로 지정하여, 팀 내 보안 문제 해결을 돕고 보안 문화를 전파하는 역할을 맡겼습니다. 이는 보안팀의 부담을 줄이고 개발자들의 자발적인 참여를 이끌어내는 데 효과적이었습니다.
  • 지속적인 모니터링 및 개선: 한 번 구축했다고 끝이 아닙니다. 파이프라인의 보안 도구들이 제대로 작동하는지 지속적으로 모니터링하고, 새로운 취약점 유형이나 공격 트렌드에 맞춰 규칙과 정책을 업데이트해야 합니다. 저희는 주기적인 회고를 통해 파이프라인과 보안 프로세스를 개선해 나갔습니다.

마무리: 개발 보안, 이제 선택이 아닌 필수

개발 속도가 비즈니스의 성패를 좌우하는 시대에, 보안을 단순히 개발 이후의 '추가 작업'으로 여기는 것은 더 이상 통하지 않습니다. CI/CD 파이프라인에 SAST와 DAST를 통합하는 것은 개발 초기부터 보안을 내재화하고, 안전한 소프트웨어를 빠르고 효율적으로 제공하기 위한 핵심 전략입니다.

저희 팀의 경험을 통해 SAST와 DAST의 상호 보완적인 역할과 CI/CD 파이프라인 통합의 실제적인 방법, 그리고 성공적인 DevSecOps 문화 구축을 위한 팁을 이해하는 데 도움이 되었기를 바랍니다. 초기에는 시행착오도 겪었지만, 장기적으로는 개발 생산성 향상과 보안 강화라는 두 마리 토끼를 모두 잡을 수 있었습니다.

물론 모든 환경에 100% 동일하게 적용될 수는 없겠지만, 이 글이 여러분의 팀에서 개발 단계 보안 자동화를 고민하고 있다면 좋은 시작점이 될 것이라고 확신합니다. 혹시 여러분의 팀에서는 어떤 방식으로 CI/CD 보안을 구현하고 계신가요? 혹은 SAST/DAST 통합 과정에서 겪었던 특별한 경험이 있으신가요? 댓글로 자유롭게 의견을 공유해 주시면 감사하겠습니다!

📌 함께 읽으면 좋은 글

  • [보안] 시크릿 관리 솔루션 비교: Vault, Kubernetes Secrets, AWS Secrets Manager 활용 가이드
  • [개발 책 리뷰] 클린 아키텍처 완전 분석: 견고한 소프트웨어 설계를 위한 필독서 리뷰
  • [이슈 분석] 개발자 생산성 측정 논란: 효율적인 소프트웨어 개발의 함정과 진실

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.

반응형

'보안' 카테고리의 다른 글

오픈소스 라이브러리 보안 취약점 관리와 소프트웨어 공급망 보안 강화 전략 비교 분석  (0) 2026.06.14
OAuth 2.0과 OpenID Connect로 안전하고 유연한 인증/인가 시스템 구축 실전 가이드  (0) 2026.06.13
시크릿 관리 솔루션 비교: Vault, Kubernetes Secrets, AWS Secrets Manager 활용 가이드  (0) 2026.06.12
OWASP Top 10 기반 웹 애플리케이션 보안 취약점 진단 및 방어 실전 가이드  (0) 2026.06.11
OAuth 2.0과 OpenID Connect로 견고한 사용자 인증 시스템 설계 및 구현 전략  (0) 2026.06.08

'보안'의 다른글

  • 현재글CI/CD 파이프라인에 SAST, DAST 통합: 개발 단계 보안 자동화 실전 가이드

관련글

티스토리툴바