Dynamic Application Security Testing (DAST)

Tier: Ultimate Offering: GitLab.com, Self-관리, GitLab 전용

경고: DAST 프록시 기반 분석기가 폐기되었습니다 GitLab 16.9에서 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 프록시 기반 분석기. 프록시 기반 분석기는 자동으로 실행하거나 온디맨드로 실행할 수 있습니다.
  • 자바스크립트를 많이 사용하는 애플리케이션을 스캔하기 위한 DAST 브라우저 기반 분석기. 이는 싱글 페이지 웹 애플리케이션을 포함합니다.

API를 스캔하려면:

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

시작하기

전제 조건

  • arm64 아키텍처 지원은 GitLab 17.0에서 도입되었습니다.
  • Linux/amd64 또는 Linux/arm64에서 docker executor가 있는 GitLab Runner 사용 가능.
  • 대상 애플리케이션이 배포되어 있어야 합니다. 자세한 내용은 배포 옵션을 읽어보십시오.
  • CI/CD 파이프라인 정의에 dast 단계가 추가되어 있어야 합니다. 예를 들어 배포 단계 이후에 추가해야 합니다.

    stages:
      - build
      - test
      - deploy
      - dast
    

권장 항목

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

    dast:
      dependencies: []
    

분석기 구성

분석기별 구성 지침은 DAST 프록시 기반 분석기, DAST 브라우저 기반 분석기 또는 API 보안 테스트 분석기를 참조하십시오.

스캔 결과 보기

발견된 취약점은 병합 요청, 파이프라인 보안 탭, 및 취약점 보고서에 표시됩니다.

  1. 모든 발견된 취약점을 보려면 다음 중 하나를 선택하십시오:
    • 프로젝트에서 보안 및 준수를 선택한 다음 취약점 보고서를 선택합니다.
    • 파이프라인에서 보안 탭을 선택합니다.
    • 병합 요청에서 보안 스캔 위젯을 선택하고 전체 보고서 탭을 선택합니다.
  2. DAST 취약점 설명을 선택하십시오. 다음 필드는 DAST 분석기가 기본 원인을 조사하고 수정하는 데 도움을 주기 위해 생성할 수 있는 예시 필드입니다. 각 분석기는 다른 필드를 출력할 수 있습니다.

    필드 설명
    설명 취약점에 대한 설명입니다.
    증거 취약점을 확인하는 데 사용되는 데이터의 증거입니다. 종종 요청 또는 응답의 일부인 이것은 발견이 취약점인지 확인하는 데 도움이 될 수 있습니다.
    식별자 취약점 식별자입니다.
    링크 감지된 취약점의 자세한 내용에 대한 링크입니다.
    메소드 취약점을 감지하는 데 사용된 HTTP 메소드입니다.
    프로젝트 취약점이 감지된 네임스페이스 및 프로젝트입니다.
    요청 헤더 요청의 헤더입니다.
    응답 헤더 응용 프로그램에서 받은 응답의 헤더입니다.
    응답 상태 응용 프로그램에서 받은 응답 상태입니다.
    스캐너 유형 취약점 보고서 유형입니다.
    심각성 취약점의 심각성입니다.
    솔루션 취약점에 대한 권장 솔루션의 내용입니다.
    URL 취약점이 감지된 URL입니다.

참고: 파이프라인에는 SAST 및 DAST 스캔을 포함한 여러 작업이 포함될 수 있습니다. 어떤 이유로 인해 작업이 완료되지 않으면 보안 대시보드에 DAST 스캐너 출력이 표시되지 않습니다. 예를 들어, DAST 작업이 완료되었지만 SAST 작업이 실패하면 보안 대시보드에 DAST 결과가 표시되지 않습니다. 실패한 경우 분석기는 종료 코드를 출력합니다.

스캔된 URL 목록

DAST가 스캔을 완료하면 병합 요청 페이지에 스캔된 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