보안 테스트 체계: CI/CD에서 취약점과 접근 통제를 검증하는 방법

배포 판단에 보안 검증을 넣는 방식

애플리케이션, API, 데이터가 맞물린 서비스에서는 취약점 탐지 결과만으로 보안 상태를 판단하기 어렵다. OWASP Top 10을 기준으로 취약점, 인증·인가, 데이터 보호를 함께 검증하고, 개발부터 배포까지의 흐름에 보안 게이트를 연결해야 한다.

보안 테스트는 소프트웨어와 인프라가 보안 요구를 충족하는지 확인하는 절차와 프로세스의 묶음이다. 위협 모델과 정책을 기준으로 취약점, 인증·인가 흐름, 데이터 보호 상태를 검증한다.

검증 범위에는 코드의 SAST, 런타임의 DAST·IAST, 의존성의 SCA, 컨테이너·IaC, 비즈니스 로직 취약점인 BOLA/IDOR와 권한 오남용, 비밀정보 유출이 포함된다. OWASP Top 10, ASVS, MASVS, NIST SSDF 등을 참조하고 최신 목록과 매핑해 테스트 케이스를 유지 관리할 필요가 있다.

위험 기준을 먼저 정한다

테스트 결과를 배포 의사결정으로 연결하려면 자산 분류와 위협 모델링을 바탕으로 위험을 점수화하고, 허용 기준을 정해야 한다. 등급별 게이트 조건을 두면 어떤 결과를 자동 승인하거나 차단할지 일관되게 판단할 수 있다.

OWASP Top 10의 분류는 내부 규정과 매핑할 수 있으며, 개인정보 보호법이나 ISO 27001 같은 규정 준수 요구와도 연결된다.

서로 다른 관점의 테스트를 결합한다

SAST는 코드를 정적으로 분석하므로 조기 탐지에 적합하며, 커밋 훅이나 PR 단위 실행에 맞는다. DAST와 IAST는 실행 환경에서 각각 동적·인스트루먼트 기반으로 동작하므로 인증 흐름, 권한 검증, 입력 검증 우회 확인에 활용한다.

SCA는 라이브러리, 컨테이너, 패키지 의존성의 CVE와 라이선스를 검증한다. 공급망 보안 관점에서 핵심적인 검사다. 각 방식은 검사 대상과 시점이 다르므로 어느 하나로 다른 방식을 대체하기보다 상보적으로 결합한다.

인증 흐름과 리소스 권한을 검증한다

인증에서는 OIDC/OAuth2, MFA, 패스워드 정책, 계정 잠금·복구 흐름을 확인한다. 토큰의 수명과 서명, 리플레이 방지도 검증 대상이다.

인가는 역할·권한 매트릭스를 기준으로 수평·수직 권한 상승과 IDOR/BOLA를 점검한다. APIscope·object-level 수준의 리소스 접근 통제가 기대한 대로 적용되는지도 확인해야 한다. 세션에서는 세션 고정 방지, SameSite/HttpOnly/Secure 플래그, CSRF 토큰 유효성을 함께 검증한다.

Web/API 테스트를 준비할 때는 엔드포인트-권한 매트릭스, 테스트 계정과 토큰 세트, 트러스트 바운더리를 먼저 정리한다. 정상 플로우(Positive)와 우회 시도(Negative)를 함께 실행하고, ID 바꿔치기, 필드 변조, 속성 기반 접근(ABAC) 조건 변경을 시나리오에 포함한다. 이때 401/403 구분, 과도한 오류 메시지 노출 방지, 오디트 로그 생성, 토큰 스코프 적용의 일관성을 확인한다.

저장·전송·로그에 남는 데이터를 확인한다

저장 데이터는 암호화 알고리즘과 키 관리(KMS/암호 수명주기), DB 컬럼 암호화, 백업·스냅샷 보호를 점검한다. 샘플 민감 데이터를 삽입한 뒤 DB 덤프와 백업 파일에서 평문 노출 여부를 확인하고, KMS 키 로테이션도 테스트한다.

전송 구간에서는 TLS 설정의 프로토콜과 암호군, 모바일의 인증서 핀닝, 중간자 공격 방어를 검증한다. TLS 스캐너로 약한 스위트와 프로토콜을 찾아 제거하고 인증서 만료 경보를 설정한다.

로그와 비밀정보는 PII 마스킹, 토큰·비밀번호 미출력, Secrets 스캐닝과 회전 절차를 대상으로 한다. 소스, 이미지, IaC를 스캔하고 발견 경로를 차단한 뒤 자동 회전 플레이북을 실행한다.

보안 게이트를 파이프라인에 연결한다

파이프라인 단계별로 스캔을 실행하고 위험 임계치에 따라 승인 또는 차단을 자동화할 수 있다. 실패 결과는 티켓으로 발급하고 SLA에 따라 처리한다. 오탐은 만료 기한을 둔 억제, 근거 링크, 리뷰 이력으로 관리하며 기술 부채 대시보드에 반영한다.

PR → SAST/SCA → 빌드 → 컨테이너 스캔 → 스테이징 배포 → 인증 세션으로 DAST → 리포트 병합 → 위험 점수화 → 게이트 판정의 흐름으로 구성할 수 있다. 임계치 예시는 Critical=0, High≤2, Medium≤10, 라이선스 위반=0이며, 이를 넘으면 파이프라인을 실패 처리하고 티켓을 자동 발행한다.

초기에는 오탐 관리 비용이 늘 수 있지만 조기 결함 제거로 릴리즈 안정성이 높아진다. 스캔 시간 증가는 캐시와 증분 스캔으로 완화한다.

간단한 GitHub Actions 예시(최신 액션 버전 확인 필요)

전제조건: 퍼블릭 스테이징 URL, 서비스 계정/시크릿 등록, 러너 메모리 4GB 이상 권장.

name: security-pipeline

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  sast_semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: p/owasp-top-ten

  sca_dependency_review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4

  zap_baseline_dast:
    needs: [sast_semgrep, sca_dependency_review]
    runs-on: ubuntu-latest
    steps:
      - name: Run ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0 # 최신 정보 확인 필요
        with:
          target: https://staging.example.com
          rules_file_name: .zap/rules.tsv
          cmd_options: -a -m 5

스캐너별 운영 특성

구분	성능(빌드/런타임 부담)	확장성	일관성(오탐/미탐)	안정성(파이프라인 영향)	운영 편의
SAST	낮음(코드 기준)	높음	오탐 다소 높음, 미탐 낮음	높음	규칙 튜닝 필요, PR 게이트 적합
DAST	중간~높음(런타임)	중간	미탐 가능(커버리지 의존)	중간	인증 세션·크롤링 설정 필수
IAST	중간(에이전트)	중간	정확도 높음(컨텍스트)	중간	에이전트 삽입·성능 영향 고려
SCA	낮음	매우 높음	정확도 높음(CVE DB)	매우 높음	정책·자동 업데이트 편리

차단·재검토·수정이 이어지는 흐름

⤢✕

측정할 수 있는 변화

위험 감소 목표는 분기당 Critical=0, High 80% 이상 감소, 평균 발견지연(MTTD) 50% 단축으로 둘 수 있다. 설계·코드 단계의 수정 비용은 운영 단계 수정 비용과 비교해 10~30배 절감되며, 초기 탐지율이 높아질수록 결함 누수율도 낮아진다.

보안 게이트 자동화는 릴리스 리드타임 영향을 최소화하는 방향으로 운영한다. 증분 스캔과 캐시를 적용하면 파이프라인 시간을 10~30% 절감할 수 있고, 컴플라이언스 감사 대응 시간도 줄일 수 있다.