위험 기반 보안 테스트와 SDLC 품질 게이트 운영

개발과 테스트 단계에서 놓친 결함은 이후 보안 사고로 이어질 수 있다. 보안 테스트는 출시 직전의 일회성 점검이 아니라, SDLC 전반에서 위험을 식별하고 검증하며 완화하는 품질 활동으로 다뤄야 한다.

보안 테스트를 품질 활동으로 다루는 방식

보안 테스트는 자산, 위협, 취약점 관점에서 시스템의 기밀성·무결성·가용성을 위협하는 요소를 찾아 검증하고 완화하는 활동의 집합이다. 기능 테스트와 다른 별도 절차로 분리하기보다 테스트 계획, 케이스, 데이터, 환경, 자동화 파이프라인, 품질 게이트를 갖춘 체계로 운영한다.

대상은 코드의 SAST, 오픈소스 종속성의 SCA, 런타임과 엔드포인트의 DAST·IAST뿐 아니라 인프라, 컨테이너, IaC, API, 모바일, 클라우드 구성, 서플라이 체인과 SBOM까지 이어진다.

위험이 큰 경로부터 검증 범위를 정한다

테스트 우선순위는 데이터 민감도와 비즈니스 영향으로 판단한 자산 중요도, 그리고 STRIDE·OWASP Top 10·OWASP API Top 10 같은 위협 시나리오를 함께 기준으로 삼는다.

릴리스나 스프린트 단위의 커버리지 목표도 이 기준에 맞춰 세운다. 예를 들어 신규 API 100%, 핵심 경로 회귀 100%, 저위험 경로 샘플링 20%처럼 범위를 구분할 수 있다. 모든 항목을 동일한 밀도로 검사하는 방식보다, 위험과 변경 영향이 큰 지점에 검증 역량을 집중하기 쉽다.

자동 검사와 심층 검증을 연결한다

정적 분석과 시크릿 스캔(SAST), 종속성 취약점 및 라이선스 점검(SCA), 동적 분석과 퍼징(DAST), 인스트루먼트 분석(IAST), 런타임 보호(RASP)는 서로 다른 위치에서 취약점을 포착한다. Terraform·Kubernetes 같은 IaC의 정적 정책 검사와 컨테이너 이미지 취약점 스캔도 이 체계에 포함한다.

PR, 브랜치, 릴리스, 프로덕션 전 단계마다 게이트 기준을 달리 둘 수 있다. High/Critical은 차단하고 Medium은 경고로 처리하는 식이다. 자동화 결과만으로 끝내지 않고 침투 테스트 같은 수동 검증을 결합하며, 예외 승인과 만료(waiver with expiry) 절차도 표준화한다.

취약점 조치와 증거를 같은 흐름으로 관리한다

취약점은 발견, 분석, 우선순위 결정, 치유, 재테스트, 종결까지 생명주기로 관리한다. 이때 CVSS, CWE, EPSS와 자산 태깅을 적용하고, 이슈 트래커·커밋·배포 버전을 연결해 추적성을 확보한다.

SBOM은 생성 후 보관하며 소프트웨어 변경관리와 연결한다. CI/CD에서는 동시성 및 증분 스캔을 최적화하고, 캐시·샌드박스·테스트 데이터·시크릿을 분리한다. 오탐 조정, 규칙셋 관리, 규정 준수 정책 템플릿 역시 도구 체인의 신뢰성을 유지하는 운영 항목이다.

배포 흐름에서 게이트를 배치하는 예

웹·모바일 서비스에서는 PR에서 SAST와 시크릿 스캔을 실행하고, 머지 전에 SCA와 컨테이너 스캔을 통과시킨다. 이후 스테이징에서 DAST와 API 보안 테스트를 수행하고 침투 테스트를 샘플링한 뒤 Go/No-Go를 판단한다. High/Critical이 발견되면 자동으로 차단하며, 예외는 CISO 승인과 만료일을 요구한다. MTTR SLA는 Critical 3영업일처럼 설정할 수 있다.

클라우드와 IaC 영역에서는 Terraform·Helm 정책 검사로 공개 스토리지와 퍼블릭 SG를 차단하고, 이미지 취약점을 스캔한 다음 배포 전에 CSPM Drift를 감지한다. 스캔 실패 시 1회 재시도하고 계속 실패하면 배포를 보류하며 환경을 격리한다.

API는 Contract에서 Fuzz로 이어지는 스키마 기반 테스트를 적용하고, 수평·수직 권한 상승을 포함한 인증·인가 경로를 집중 점검한다. 데이터 민감도에 따라 Rate와 Injection도 검사한다. 신규·변경 API는 100% 자동화하고, 고위험 엔드포인트에는 수동 검증을 병행한다.

PCI DSS와 ISMS-P 대응에서는 정기적인 취약점 진단 및 침투 테스트 일정을 운영하고, 리포트·스크린샷·로그를 중앙에 저장한다. SBOM과 SCA 결과를 변경관리와 연결하면 심사 증적을 정리하기 수월하다.

보안 테스트 체계를 운영하면 High/Critical의 프로덕션 유출은 전·후 결함 밀도 비교를 기준으로 조직 성숙도에 따라 60~~80% 감소할 수 있다. 개발 단계의 조기 검출과 재현성 높은 증거 제공은 MTTR을 30~~50% 단축하는 데 연결된다. 정책 튜닝과 샘플링 침투 테스트를 병행하면 릴리스 차단률은 3~7% 수준으로 유지할 수 있으며, Shift-left에 따른 결함 수정 비용 곡선 효과로 수정 단가는 30%+ 절감될 수 있다. SBOM과 대시보드는 자산과 위험의 실시간 가시성, 감사 대응 리드타임 단축에도 활용된다.

릴리스 판단까지 이어지는 보안 테스트 흐름

⤢✕

기법별 운영 특성

기법	성능(속도/리소스)	확장성	일관성	안정성(오탐/미탐)	운영 편의
SAST	빠름, 빌드 시간 영향 낮음	매우 높음(코드베이스 확대 용이)	높음(규칙셋 고정)	오탐 중간, 미탐 존재	CI 통합 용이, 규칙 관리 필요
SCA/SBOM	매우 빠름	매우 높음	높음	오탐 낮음, 미탐 패키지 DB 의존	라이선스·취약점 동시 관리 용이
DAST	중간~느림(동적 환경 의존)	중간(환경 준비 필요)	중간(상태·데이터 의존)	오탐 중간, 논리 취약점 미탐 가능	스테이징 URL 필요, 튜닝 필요
IAST	중간(에이전트 오버헤드)	중간	높음(실행 경로 기반)	오탐 낮음, 미탐 낮음	런타임 에이전트 관리 필요
침투 테스트	느림(수동)	낮음	전문가 역량 의존	오탐 낮음, 미탐 낮음(시나리오 기반)	주기·샘플링 운영, 비용 높음

게이트 정책과 예외 처리 기준

PR 단계에서는 시크릿 누설을 발견하면 즉시 Fail 처리하고 SAST는 High 이상을 차단한다. 머지 전에는 SCA의 High/Critical과 라이선스 정책 위반을 차단하며, 사전 배포에서는 컨테이너·IaC 및 DAST의 High 이상을 막는다.

예외 승인은 만료일과 보상통제를 반드시 포함하고, 재평가 주기는 30일로 둔다. 도구 실패나 타임아웃이 발생하면 1차 재시도(지수 백오프), 격리, 담당자 알림, 릴리스 보류 순서로 처리한다.

테스트 계획의 입력은 자산 분류, 아키텍처 다이어그램, 위협 모델, 컴플라이언스 요구다. 여기서 테스트 범위와 깊이, 도구와 버전, 환경·데이터, 게이트 기준, 롤백 전략을 산출한다. 실행 중에는 병렬 스캔, 변경 영향도 기반 증분 스캔, 취약점 자동 triage 규칙을 적용한다.

발견 수와 중대도, MTTR, 재개방률, 유출 결함률, 게이트 차단률을 운영 지표로 삼고, 취약점과 코드 커밋 및 릴리스 버전을 연결한다. SBOM도 버전 관리 대상이다.

CI/CD에 넣는 최소 보안 테스트 파이프라인

전제조건: GitHub Actions, Docker 사용 가능, 애플리케이션 프리뷰 URL 제공 가능(DAST 타깃).

name: security-tests
on:
  pull_request:
  workflow_dispatch:

jobs:
  sast-secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Semgrep SAST
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/owasp-top-ten
          generateSarif: true
          auditOn: push
      - name: TruffleHog Secrets Scan
        uses: trufflesecurity/trufflehog@v3
        with:
          path: .
          base: ${{ github.event.pull_request.base.sha }}
          head: ${{ github.event.pull_request.head.sha }}

  sbom-sca:
    runs-on: ubuntu-latest
    needs: sast-secrets
    steps:
      - uses: actions/checkout@v4
      - name: Build container
        run: docker build -t app:ci .
      - name: Generate SBOM (Syft)
        uses: anchore/syft-action@v0
        with:
          image: app:ci
          format: spdx-json
          output: sbom.spdx.json
      - name: Scan SBOM (Trivy)
        uses: aquasecurity/trivy-action@0.21.0
        with:
          scan-type: sbom
          input: sbom.spdx.json
          severity: CRITICAL,HIGH
          exit-code: 1

  dast:
    runs-on: ubuntu-latest
    needs: sbom-sca
    steps:
      - name: OWASP ZAP Baseline
        uses: zaproxy/action-baseline@v0.10.0
        with:
          target: ${{ secrets.STAGING_URL }}
          rules_file_name: .zap/rules.tsv
          cmd_options: -m 5 -t ${{ secrets.STAGING_URL }}

ZAP rules.tsv에서는 False Positive 규칙을 완화하되 High 이상 차단은 유지한다. SBOM은 아티팩트로 보존해 릴리스 버전과 연결한다. 장기적으로는 IAST와 퍼징을 추가하고, 테스트 데이터와 시크릿은 전용 Vault로 격리한다.