Dynamic Application Security Testing (DAST)

Tier: Ultimate Offering: GitLab.com, 자체관리, GitLab Dedicated
caution
DAST 프록시 기반 분석기는 GitLab 16.9에서 사용되지 않게 되었으며 GitLab 17.0에서 DAST 버전 5로 교체되었습니다. 이 변경 사항은 파괴적인 변경 사항입니다. DAST 프록시 기반 분석기에서 DAST 버전 5로 마이그레이션하는 방법에 대한 지침은 프록시 기반 마이그레이션 가이드를 참조하십시오. 또한, DAST 버전 4 브라우저 기반 분석기에서 DAST 버전 5로 마이그레이션하는 방법에 대한 지침은 브라우저 기반 마이그레이션 가이드를 참조하십시오.

Dynamic Application Security Testing (DAST)는 웹 애플리케이션 및 API에서 취약점을 찾기 위해 자동으로 침투 테스트를 실행합니다. DAST는 해커의 접근 방식을 자동화하고, 실제 공격을 시뮬레이션하여 크로스 사이트 스크립팅 (XSS), SQL 인젝션 (SQLi), 크로스 사이트 요청 위조 (CSRF)와 같은 중요한 위협에 대해 취약점 및 잘못된 구성을 발견합니다. DAST는 완전히 언어에 중립적이며, 애플리케이션을 외부에서 내부로 조사합니다. 실행 중인 애플리케이션을 테스트 환경에서 실행하는 경우, DAST 스캔을 CI/CD 파이프라인에서 자동화하거나, 일정에 따라 자동으로 실행하거나, 필요할 때 독립적으로 실행할 수 있습니다. 소프트웨어 개발 수명주기 동안 DAST를 사용하면 애플리케이션이 제품화되기 전에 취약점을 발견할 수 있습니다. DAST는 소프트웨어 보안의 기초적인 컴포넌트이며, SAST, 의존성 및 라이선스 스캔, 비밀 감지와 함께 사용하여 애플리케이션의 포괄적인 보안 평가를 제공해야 합니다.

GitLab의 브라우저 기반 DAST와 DAST API는 현대 웹 애플리케이션과 API에 대한 포괄적인 보안을 제공하는 독점적인 런타임 도구입니다.

Dynamic Application Security Testing (DAST)에서 개요를 확인하세요.

GitLab DAST

GitLab은 다음과 같은 DAST 분석기를 제공하며, 테스트하는 애플리케이션의 종류에 따라 하나 이상이 유용할 수 있습니다.

웹 사이트를 스캔하려면 다음 중 하나를 사용하세요:

  • 단순한 HTML을 제공하는 전통적인 애플리케이션을 스캔하기 위한 DAST 프록시 기반 분석기. 프록시 기반 분석기는 자동으로 실행하거나 필요할 때 실행할 수 있습니다.
  • JavaScript를 많이 사용하는 애플리케이션을 스캔하기 위한 DAST 브라우저 기반 분석기. 이는 싱글 페이지 웹 애플리케이션도 포함합니다.

API를 스캔하려면:

  • 웹 API 기술인 GraphQL, REST 및 SOAP을 지원하는 DAST API 분석기를 사용하세요.

분석기는 애플리케이션 보안에서 설명된 아키텍처 패턴을 따릅니다. 각 분석기는 파이프라인에서 CI 템플릿을 사용하여 구성할 수 있으며, 스캔은 Docker 컨테이너에서 실행됩니다. 스캔은 스캔 결과의 차이를 기반으로 GitLab이 발견한 취약점을 결정하는 DAST 보고서 artifact를 출력합니다.

시작하기

사전 요구 사항

  • Linux/amd64 또는 Linux/arm64에 대한 docker executor가 있는 GitLab Runner가 사용 가능해야 합니다.
  • 대상 애플리케이션을 배포해야 합니다. 자세한 내용은 배포 옵션을 참조하세요.
  • CI/CD 파이프라인 정의에 dast 스테이지가 있어야 합니다. 이는 배포 단계 이후에 추가되어야 합니다. 예:

    stages:
      - build
      - test
      - deploy
      - dast
    

권장 사항

  • 파이프라인이 각 실행에서 동일한 웹 서버에 배포되도록 구성된 경우 주의하여야 합니다. 서버가 업데이트되는 동안 DAST 스캔을 실행하면 부정확하고 결정론적이지 않은 결과가 됩니다.
  • 분석기의 최신 버전을 실행하도록 러너를 항상 풀 정책으로 구성하세요.
  • 기본적으로 DAST는 파이프라인의 이전 작업에서 정의된 모든 artifact를 다운로드합니다. 만약 DAST 작업이 environment_url.txt를 사용하여 테스트 중인 URL이나 이전 작업에서 생성된 다른 파일에 의존하지 않는다면, artifact를 다운로드하지 않도록 권장합니다. Artifact를 다운로드하지 않도록 하려면, 분석기 CI/CD 작업을 다음과 같이 의존성이 없음을 지정하도록 확장하세요. 예를 들어, DAST 프록시 기반 분석기의 경우 .gitlab-ci.yml 파일에 다음을 추가하세요:

    dast:
      dependencies: []
    

분석기 구성

분석기별 구성 지침은 DAST 프록시 기반 분석기, DAST 브라우저 기반 분석기 또는 DAST API 분석기를 참조하세요.

스캔 결과 보기

검출된 취약점은 Merge Request, 파이프라인 보안 탭, 및 취약점 보고서에 나타납니다.

  1. 검출된 모든 취약점을 볼려면, 다음 중 하나를 선택하세요:
    • 프로젝트에서 보안 및 규정을 선택한 다음 취약점 보고서를 선택합니다.
    • 파이프라인에서 보안 탭을 선택합니다.
    • Merge Request에서 보안 스캔 위젯을 선택하고 전체 보고서 탭을 선택합니다.
  2. DAST 취약점의 설명을 선택합니다. 다음은 DAST 분석기가 조사와 원인 해결을 돕기 위해 생성할 수 있는 예시 필드입니다. 각 분석기마다 다른 필드를 출력할 수 있습니다.

    필드 설명
    설명 취약점에 대한 설명입니다.
    증거 취약점을 확인하는 데 사용된 데이터입니다. 종종 요청 또는 응답의 일부 스니펫으로, 이를 사용하여 발견 항목이 취약점인지 확인할 수 있습니다.
    식별자 취약점의 식별자입니다.
    링크 검출된 취약점에 대한 자세한 정보로 연결됩니다.
    메소드 취약점을 탐지하는 데 사용된 HTTP 메서드입니다.
    프로젝트 취약점이 검출된 네임스페이스와 프로젝트입니다.
    요청 헤더 요청의 헤더입니다.
    응답 헤더 애플리케이션으로부터 받은 응답의 헤더입니다.
    응답 상태 애플리케이션으로부터 받은 응답 상태입니다.
    스캐너 유형 취약점 보고서의 유형입니다.
    심각도 취약점의 심각도입니다.
    솔루션 취약점에 대한 권장 솔루션의 세부 정보입니다.
    URL 취약점이 검출된 URL입니다.
note
하나의 파이프라인은 SAST 및 DAST 스캔을 포함한 여러 작업으로 구성될 수 있습니다. 만약 어떠한 이유로 인해 작업 중단되면, 보안 대시보드에 DAST 스캐너 출력이 나타나지 않습니다. 예를 들어, DAST 작업이 완료되었지만 SAST 작업이 실패하는 경우, 보안 대시보드에 DAST 결과가 표시되지 않습니다. 실패 시 분석기는 종료 코드를 출력합니다.

스캔한 URL 디렉터리 보기

DAST 스캔이 완료되면 Merge Request 페이지에 스캔한 URL 수가 표시됩니다. 웹 콘솔 출력을 보려면 세부 정보 보기를 선택하세요. 여기에는 스캔한 URL 디렉터리과 함께 다른 정보가 포함됩니다.

DAST 위젯

애플리케이션 배포 옵션

DAST는 스캔할 수 있는 배포된 애플리케이션을 요구합니다.

대상 애플리케이션의 복잡성에 따라 DAST 템플릿을 배포하고 구성하는 몇 가지 옵션이 있습니다. 일련의 예제 애플리케이션과 그 구성이 DAST 데모 프로젝트에 제공되었습니다.

리뷰 앱

리뷰 앱은 DAST 대상 애플리케이션을 배포하는 가장 복잡한 방법입니다. 이 프로세스를 지원하기 위해 Google Kubernetes Engine (GKE)를 사용하여 리뷰 앱 배포를 생성했습니다. 이 예제는 리뷰 앱 - GKE 프로젝트에서 찾을 수 있으며, DAST를 위해 리뷰 앱을 구성하는 자세한 지침은 README.md에서 확인할 수 있습니다.

도커 서비스

애플리케이션이 Docker 컨테이너를 사용하는 경우, DAST와 함께 배포하고 스캔하는 또 다른 옵션이 있습니다. Docker 빌드 작업이 완료되고 이미지가 컨테이너 레지스트리에 추가된 후, 이 이미지를 서비스로 사용할 수 있습니다.

.gitlab-ci.yml에서 서비스 정의를 사용하여 DAST 분석기로 서비스를 스캔할 수 있습니다.

작업에 services 섹션을 추가할 때, alias는 서비스에 액세스하는 데 사용되는 호스트명을 정의하는 데 사용됩니다. 다음 예에서 dast 작업 정의의 alias: yourapp 부분은 배포된 애플리케이션의 URL이 호스트명으로 yourapp을 사용한다는 것을 의미합니다 (https://yourapp/).

stages:
  - build
  - dast

include:
  - template: DAST.gitlab-ci.yml

# 컨테이너를 GitLab 컨테이너 레지스트리에 배포
deploy:
  services:
  - name: docker:dind
    alias: dind
  image: docker:20.10.16
  stage: build
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - docker build --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --tag $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

dast:
  services: # 서비스를 사용하여 앱 컨테이너를 DAST 작업에 연결합니다
    - name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      alias: yourapp

variables:
  DAST_WEBSITE: https://yourapp
  DAST_FULL_SCAN_ENABLED: "true" # 전체 스캔 수행
  DAST_BROWSER_SCAN: "true" # 브라우저 기반 GitLab DAST 크롤러 사용

대부분의 애플리케이션은 데이터베이스나 캐싱 서비스와 같은 여러 서비스에 의존합니다. 기본적으로 서비스 필드에서 정의된 서비스는 서로 통신할 수 없습니다. 서비스 간 통신을 허용하려면 FF_NETWORK_PER_BUILD 피처 플래그를 활성화하세요.

variables:
  FF_NETWORK_PER_BUILD: "true" # 모든 서비스가 동일한 네트워크에서 통신하도록 네트워크 당 빌드 활성화

services: # 컨테이너를 DAST 작업에 연결하기 위해 서비스를 사용합니다
  - name: mongo:latest
    alias: mongo
  - name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    alias: yourapp