홈/보안/DevSecOps 파이프라인: CI/CD에 보안 게이트 넣기
보안DevSecOpsSAST

DevSecOps 파이프라인: CI/CD에 보안 게이트 넣기

SAST·SCA·IaC 스캔을 PR/머지 단계에 넣고, 차단 정책을 점진적으로 올리는 실무 가이드.

DevSecOps 파이프라인: CI/CD에 보안 게이트 넣기
목차
  1. DevSecOps란
  2. CI/CD 파이프라인 보안 통합 구조
  3. 1단계: SAST (정적 분석)
  4. 2단계: SCA (소프트웨어 구성 분석)
  5. 3단계: 컨테이너 이미지 스캔
  6. 4단계: Secrets 탐지
  7. 5단계: DAST (동적 분석)
  8. 보안 게이트 정책
  9. 코드만이 아니라 인프라(IaC)도 스캔하라
  10. 공급망까지 — 빌드 산출물 신뢰
  11. 보안 게이트, 현실적으로 운영하기
  12. 보안 게이트가 빌드를 막을 때: 원인 분류와 예외 처리
  13. 자주 묻는 질문 (FAQ)
  14. 에디터 노트 — 현장에서는
  15. 참고 자료
  16. 권장 게이트 배치
  17. 검증 환경·편집자 주
  18. 자주 묻는 질문 (FAQ) — 보강

DevSecOps란

DevSecOps는 개발(Dev), 보안(Sec), 운영(Ops)을 통합해 소프트웨어 개발 전 단계에 보안을 내재화하는 방법론입니다. "Shift Left Security"라고도 불립니다.

CI/CD 파이프라인 보안 통합 구조

CODE
코드 → SAST → SCA → 빌드 → 이미지 스캔 → DAST → 배포 → 런타임 모니터링

1단계: SAST (정적 분석)

YAML
name: Security Scan
on: [push, pull_request]

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten
      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: javascript, python
      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v3

2단계: SCA (소프트웨어 구성 분석)

YAML
  sca:
    steps:
      - name: Snyk Security Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

3단계: 컨테이너 이미지 스캔

YAML
      - name: Trivy 취약점 스캔
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: my-app:${{ github.sha }}
          exit-code: '1'
          severity: 'HIGH,CRITICAL'

4단계: Secrets 탐지

YAML
      - name: TruffleHog Secrets Scan
        uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          base: ${{ github.event.repository.default_branch }}

5단계: DAST (동적 분석)

YAML
      - name: OWASP ZAP Full Scan
        uses: zaproxy/action-full-scan@v0.10.0
        with:
          target: 'https://staging.myapp.com'
          fail_action: true

보안 게이트 정책

심각도조치
Critical배포 차단
High배포 차단
Medium경고
Low기록만

DevSecOps는 도구가 아닌 문화입니다. 개발팀과 보안팀의 협업 없이 파이프라인만 구축하면 형식적인 체크박스 보안에 그칩니다.

코드만이 아니라 인프라(IaC)도 스캔하라

요즘 사고의 상당수는 애플리케이션 코드가 아니라 잘못된 인프라 설정(공개 S3, 열린 보안그룹)에서 납니다. 파이프라인에 IaC 스캔을 추가하세요.

YAML
      - name: Checkov IaC Scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: ./terraform
          framework: terraform

tfsec, Terrascan도 같은 목적의 대안입니다.

공급망까지 — 빌드 산출물 신뢰

SAST/SCA로 끝이 아닙니다. 빌드마다 **SBOM(구성요소 목록)**을 생성하고 아티팩트에 서명(cosign)하면, 배포물이 변조되지 않았음을 검증할 수 있습니다.

보안 게이트, 현실적으로 운영하기

함정현실적 운영
Critical 전부 즉시 차단도입 초기엔 신규 취약점만 차단, 기존분은 기한 부여
예외 없음만료일 있는 예외(waiver) 절차로 빌드 마비 방지
알림 폭주High↑만 PR 코멘트, 나머지는 대시보드

처음부터 모든 게이트를 "차단"으로 켜면 개발팀이 우회로를 찾습니다. 점진 도입이 정착의 비결입니다.

보안 게이트가 빌드를 막을 때: 원인 분류와 예외 처리

게이트를 도입하면 첫 몇 주는 빌드 실패가 급증합니다. 이때 게이트를 끄는 대신 실패 원인을 분류해 처리하는 절차가 있어야 정착합니다.

원인 분류

  • 실제 취약점: 신규 코드에서 발생한 SQL 인젝션, 하드코딩된 비밀값 등
  • 기존 부채: 게이트 도입 전부터 있던 취약 의존성
  • 오탐: 테스트 코드의 더미 키, 도달 불가능한 코드 경로

재현과 확인 명령

Bash
# 로컬에서 CI와 같은 스캔 재현
semgrep ci --config auto               # SAST
trivy fs --severity HIGH,CRITICAL .    # 의존성·설정
gitleaks detect --source . --redact    # 비밀값
# 의존성 경고가 실제로 사용되는 패키지인지 확인
npm ls <package>    # 또는 pip show <package>

처리 규칙

  • 신규 코드의 실제 취약점: 머지 전 수정(게이트 유지)
  • 기존 부채: 기준선(baseline)으로 등록하고 신규 증가분만 차단, 부채는 별도 티켓과 기한으로 관리
  • 오탐: 도구의 예외 설정(.semgrepignore, .trivyignore, .gitleaksignore)에 사유와 만료일을 주석으로 남기고 리뷰를 거쳐 추가

재발 방지

  • 예외 파일 변경은 보안 담당자 승인(CODEOWNERS)을 필수로 합니다.
  • 만료일이 지난 예외를 찾는 작업을 주기적으로 실행해 예외가 영구화되지 않게 합니다.

자주 묻는 질문 (FAQ)

Q. SAST·SCA·DAST 중 하나만 한다면? 의존성 취약점이 사고의 큰 비중이라 SCA부터 시작하는 경우가 많습니다. 다만 셋은 보는 영역이 달라(코드/의존성/실행) 상호 보완적입니다.

Q. 스캔 때문에 빌드가 너무 느려집니다. 전체 스캔은 야간/머지 시점으로 돌리고, PR 단계에선 변경분 위주의 빠른 스캔(증분)만 돌리는 식으로 분리하면 개발 속도를 지킬 수 있습니다.

에디터 노트 — 현장에서는

보안 게이트를 처음부터 'Critical이면 무조건 차단'으로 켜면, 2주 안에 개발팀이 우회로를 찾습니다. 효과적이었던 건 정반대였습니다 — 처음엔 '신규 취약점만 차단, 기존분은 리포트만'으로 시작해 빌드를 안 막으면서 가시성을 확보하고, 팀이 익숙해진 뒤 게이트를 조였습니다. DevSecOps에서 가장 위험한 건 취약점이 아니라 '보안을 우회하고 싶게 만드는 프로세스'입니다.

참고 자료

권장 게이트 배치

단계스캔초기 모드
PRSCA(변경분), 시크릿 탐지warn → 이후 fail
mergeSAST High↑fail
nightly전체 SCA·IaC·컨테이너리포트+티켓
YAML
# 개념 예: PR에서 Trivy
- name: trivy fs
  run: trivy fs --exit-code 1 --severity HIGH,CRITICAL .

검증 환경·편집자 주

  • 2026-09 보강. 처음부터 Critical 전면 차단은 도입을 망칩니다.

자주 묻는 질문 (FAQ) — 보강

Q. 오픈소스 라이선스도 막아야 하나요?
정책(카피레프트 허용 여부)을 SCA 규칙에 포함하세요.

✦ ✦ ✦
출처·검증 안내

글마다 출처와 확인 범위가 다릅니다. 아래에 확인일·확인 범위·출처가 기록된 글만 그 범위에서 확인된 것입니다. 기록이 없는 글은 적용 전 사용 중인 버전의 공식 문서로 직접 확인하고, 오류는 이메일로 알려주세요. 편집 정책 · 이메일로 제보

이 글에는 사람이 확인한 날짜·범위 기록이 아직 없습니다.

발행 ·
주제 관련 공식 문서(자동 연결 · 문장별 근거 아님)OWASP 공식 문서 ↗

댓글

첫 번째 댓글을 남겨보세요.