• 작업 정의
  • 이름
  • 이미지
  • 스크립트
  • 스테이지
  • Fail-safe
  • Artifact
  • 정책
    • 정책 확인 예시
• 도커 이미지
  • 이미지 크기
  • 이미지 태그
• 명령줄
  • 변수
    • SAST 및 의존성 스캔
    • 컨테이너 스캔
    • 설정 파일
  • 출력 파일
  • 종료 코드
  • 로깅
    • 로깅 레벨
    • 공통 logutil 패키지
• 보고서
  • 보고서 유효성 검사
    • 로컬에서 유효성 검사
  • 보고서 필드
    • 버전
    • 취약점
      • ID
      • 카테고리
      • 스캔
      • 스캔 주요 식별자
      • 이름, 메시지 및 설명
      • 솔루션
      • 식별자
    • 세부 정보
    • 위치
      • 의존성 스캔
      • 컨테이너 스캔
      • SAST
    • 취약점 추적과 병합
      • 심각도
    • 치료
      • 요약
      • 해결된 취약점
      • Diff

보안 스캐너 통합

GitLab에 보안 스캐너를 통합하는 것은 사용자가 CI/CD 구성 파일에 추가할 수 있는 CI/CD 작업 정의를 제공하는 것으로 이루어집니다. 이를 통해 사용자는 자신들의 GitLab 프로젝트를 스캔하기 위한 작업을 추가할 수 있습니다. 그런 다음 이 작업은 GitLab에서 지정한 형식으로 결과를 출력해야 합니다. 이러한 결과는 이후에 자동으로 GitLab의 여러 위치(예: 파이프라인 뷰, 병합 요청 위젯, 보안 대시보드)에 표시됩니다.

스캐닝 작업은 보통 스캐너와 해당 종속 항목을 모두 포함하는 도커 이미지를 기반으로 합니다.

이 페이지에서는 보안 스캐너를 구현하는 CI/CD 작업을 작성하는 데 필요한 요구 사항과 지침, 그리고 도커 이미지에 대한 요구 사항과 지침을 기술합니다.

작업 정의

이 섹션에서는 보안 스캐너의 작업 정의 파일에 추가해야 하는 중요한 여러 필드를 설명합니다. 이와 관련된 자세한 내용 및 다른 사용 가능한 필드에 대한 전체 설명은 CI 문서에서 확인할 수 있습니다.

이름

일관성을 위해 스캐닝 작업은 스캐너의 이름을 소문자로 작성해야 합니다. 작업 이름은 스캔 유형 뒤에 접미사로 붙여야 합니다:

• _dependency_scanning
• _container_scanning
• _dast
• _sast

예를 들어, “MySec” 스캐너를 기반으로 한 의존성 스캐닝 작업의 이름은 mysec_dependency_scanning이어야 합니다.

이미지

image 키워드는 보안 스캐너를 포함하는 도커 이미지를 지정하는 데 사용됩니다.

스크립트

script 키워드는 스캐너를 실행하는 명령을 지정하는 데 사용됩니다. script 항목이 비워 둘 수 없으므로 스캔을 수행하는 명령으로 설정해야 합니다. 도커 이미지의 미리 정의된 ENTRYPOINT 및 CMD를 전달하지 않고 자동으로 스캔을 수행하는 것은 불가능합니다.

before_script는 사용자가 스캔을 수행하기 전에 프로젝트를 준비하는 데 이를 의존할 수 있기 때문에 작업 정의에서 사용해서는 안 됩니다. 예를 들어, SAST나 의존성 스캔을 수행하기 전에 특정 프로젝트가 필요로 하는 시스템 라이브러리를 설치하는 데 before_script를 사용하는 것은 흔한 실천 방법입니다.

마찬가지로, 작업 정의에서는 after_script를 사용해서는 안 됩니다. 왜냐하면 이것은 사용자에 의해 재정의될 수 있기 때문입니다.

스테이지

일관성을 위해, 스캔 작업은 가능한 경우 test 단계에 속해야 합니다. stage 키워드는 test가 기본 값이므로 생략될 수 있습니다.

Fail-safe

기본적으로 스캔 작업은 실패할 때 파이프라인을 차단하지 않으므로 allow_failure 매개 변수를 true로 설정해야 합니다.

Artifact

스캔 작업은 수행하는 스캔 유형에 해당하는 보고서를 선언해야 하며, artifacts:reports 키워드를 사용해야 합니다. 유효한 보고서는 다음과 같습니다:

• dependency_scanning
• container_scanning
• dast
• api_fuzzing
• coverage_fuzzing
• sast

예를 들어, gl-sast-report.json이라는 파일을 생성하고 SAST 보고서로 업로드하는 SAST 작업 정의의 예시는 다음과 같습니다.

mysec_sast:
  image: registry.gitlab.com/secure/mysec
  artifacts:
    reports:
      sast: gl-sast-report.json

gl-sast-report.json은 예시 파일 경로이지만 다른 파일 이름을 사용할 수 있습니다. 파일 이름 때문이 아니라 작업 정의에서 reports:sast 키 하에 선언되었기 때문에 SAST 보고서로 처리됩니다.

정책

AutoDevOps와 같은 특정 GitLab 워크플로우는 주어진 스캔을 비활성화해야 하는 것을 나타내는 CI/CD 변수를 정의합니다. 이를 확인하기 위해 다음과 같은 변수를 확인할 수 있습니다:

• DEPENDENCY_SCANNING_DISABLED
• CONTAINER_SCANNING_DISABLED
• SAST_DISABLED
• DAST_DISABLED

스캐너 유형에 따라 적합한 경우 사용자 지정 스캐너 실행을 비활성화해야 합니다.

또한 GitLab은 CI_PROJECT_REPOSITORY_LANGUAGES 변수를 정의하여 저장소의 언어 목록을 제공합니다. 이 값을 기준으로 스캐너가 다르게 동작할 수도 있고 그렇지 않을 수도 있습니다. 현재 언어 감지는 linguist Ruby gem에 의존합니다. 미리 정의된 CI/CD 변수를 확인하세요.

정책 확인 예시

다음 예시는 프로젝트 저장소에 Java 소스 코드가 포함되어 있고 dependency_scanning 기능이 활성화되어 있는 경우에만 사용자 정의 의존성 스캐닝 작업 mysec_dependency_scanning을 건너뛰는 방법을 보여줍니다.

mysec_dependency_scanning:
  rules:
    - if: $DEPENDENCY_SCANNING_DISABLED == 'true'
      when: never
    - if: $GITLAB_FEATURES =~ /\bdependency_scanning\b/
      exists:
        - '**/*.java'

그외의 작업 정책은 사용자가 필요에 따라 구성해야 합니다. 예를 들어, 미리 정의된 정책은 특정 브랜치에 대해 스캔 작업을 트리거하거나 특정 파일 세트가 변경될 때 스캔 작업을 트리거하게 해서는 안 됩니다.

도커 이미지

도커 이미지는 스캐너와 그 의존성을 모두 포함하는 자체 포괄적인 환경입니다. 스캐너를 도커 이미지로 패키징하면 해당 스캐너가 실행되는 개별 머신에 관계없이 의존성과 구성이 항상 존재하게 됩니다.

이미지 크기

CI 인프라에 따라 CI가 작업을 실행할 때마다 Docker 이미지를 가져와야 할 수도 있습니다. 스캔 작업이 빠르게 실행되고 대역폭 낭비를 피하기 위해 Docker 이미지는 가능한 작아야 합니다. 이미지 크기를 50MB 이하로 유지해야 합니다. 그렇게 할 수 없는 경우 DVD-ROM의 크기인 1.46GB 미만으로 유지해야 합니다.

스캐너가 완전히 기능하는 Linux 환경을 필요로 하는 경우에는 Debian “slim” 배포판 또는 Alpine Linux를 사용하는 것이 좋습니다. 가능하다면 FROM scratch 명령을 사용하여 이미지를 처음부터 빌드하고 필요한 라이브러리를 모두 포함하여 스캐너를 컴파일하는 것이 좋습니다. 다중 단계 빌드도 이미지를 작게 유지하는 데 도움이 될 수 있습니다.

이미지 크기를 작게 유지하려면 dive를 사용하여 Docker 이미지의 레이어를 분석하여 추가적인 불필요한 것이 어디에서 왔는지 확인하는 것이 좋습니다.

일부 경우에는 이미지에서 파일을 제거하기 어려울 수 있습니다. 이 경우에는 Zstandard를 사용하여 파일이나 큰 디렉터리를 압축하는 것을 고려하십시오. Zstandard는 압축 속도에 매우 적은 영향을 줄 수 있는 많은 다양한 압축 레벨을 제공합니다. 이미지 크기를 줄이는 데 도움이 됩니다. 압축된 디렉터리가 이미지가 시작될 때 자동으로 압축 해제되도록 하는 것이 도움이 됩니다. 후자를 선택한 경우 특정 사용자의 $HOME/.bashrc 또는 도커 이미지의 /etc/bashrc에 단계를 추가하는 것이 가능합니다. 후자의 경우에는 로그인 셸을 실행하기 위한 진입점을 변경해야 합니다.

다음은 시작 지점을 설정하는 몇 가지 예시입니다:

• https://gitlab.com/gitlab-org/security-products/license-management/-/blob/0b976fcffe0a9b8e80587adb076bcdf279c9331c/config/install.sh#L168-170
• https://gitlab.com/gitlab-org/security-products/license-management/-/blob/0b976fcffe0a9b8e80587adb076bcdf279c9331c/config/.bashrc#L49

이미지 태그

Docker Official Images 프로젝트에 기술된 바에 따르면, 특정 시리즈의 “가장 최근” 릴리즈를 쉽게 참조할 수 있도록 버전 번호 태그에 별칭을 지정하는 것이 강력히 권장됩니다. 또한 Docker 태깅: Docker 이미지의 태깅 및 버전 관리에 대한 모베스트(모베스트는 숧스자 이스레아코타니 타 굿레이브 아이도모카)도 참조하십시오.

명령줄

스캐너는 환경 변수를 입력으로 사용하고, 작업 정의에 따라 보고서로 업로드되는 파일을 생성하는 명령줄 도구입니다. 또한 표준 출력 및 표준 에러 스트림에서 텍스트 출력을 생성하며, 상태 코드로 종료합니다.

변수

모든 CI/CD 변수는 환경 변수로 스캐너로 전달됩니다. 스캔된 프로젝트는 사전 정의된 CI/CD 변수에 의해 설명됩니다.

SAST 및 의존성 스캔

SAST 및 의존성 스캔 스캐너는 CI_PROJECT_DIR CI/CD 변수에 의해 제공된 프로젝트 디렉토리의 파일을 스캔해야 합니다.

컨테이너 스캔

공식 GitLab용 컨테이너 스캐닝과 일관성을 유지하기 위해, 스캐너는 CI_APPLICATION_REPOSITORY 및 CI_APPLICATION_TAG에 의해 지정된 Docker 이미지를 스캔해야 합니다. DOCKER_IMAGE CI/CD 변수가 제공된 경우 CI_APPLICATION_REPOSITORY 및 CI_APPLICATION_TAG 변수는 무시되고 대신 DOCKER_IMAGE 변수에 지정된 이미지가 스캔됩니다.

만약 제공되지 않았다면, CI_APPLICATION_REPOSITORY는 $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG로 기본값을 가져야 합니다. 이는 사전 정의된 CI/CD 변수의 조합입니다. CI_APPLICATION_TAG는 CI_COMMIT_SHA로 기본값을 가져야 합니다.

스캐너는 Docker 레지스트리에 서명해야 합니다. 이를 위해 DOCKER_USER 및 DOCKER_PASSWORD 변수를 사용해야 합니다. 이러한 값이 정의되어 있지 않다면, 기본값으로 CI_REGISTRY_USER 및 CI_REGISTRY_PASSWORD를 사용해야 합니다.

설정 파일

스캐너는 CI_PROJECT_DIR를 사용하여 특정 구성 파일을로드할 수 있으나, 파일이 아닌 CI/CD 변수로 구성을 노출하는 것이 좋습니다.

출력 파일

GitLab CI/CD에 업로드되는 모든 아티팩트와 마찬가지로, 스캐너에 의해 생성된 Secure 보고서는 CI_PROJECT_DIR CI/CD 변수가 지정하는 프로젝트 디렉토리에 작성되어야 합니다.

스캔 유형에 따라 출력 파일 이름을 붙이고, 접두어로 gl-을 사용하는 것이 좋습니다. 모든 Secure 보고서가 JSON 파일이므로 파일 확장자로 .json을 사용하는 것이 좋습니다. 예를 들어, 의존성 스캔 보고서의 제안 파일 이름은 gl-dependency-scanning.json입니다.

작업 정의의 artifacts:reports 키워드는 보안 보고서가 작성된 파일 경로와 일관성을 유지해야 합니다. 예를 들어, 의존성 스캐닝 분석기가 보고서를 CI 프로젝트 디렉토리에 작성하고, 이 보고서 파일 이름이 depscan.json인 경우, artifacts:reports:dependency_scanning를 depscan.json로 설정해야 합니다.

종료 코드

POSIX 종료 코드 표준에 따라 스캐너는 성공의 경우 0 또는 실패의 경우 1로 종료합니다. 성공은 취약성을 발견한 경우도 포함됩니다.

CI 작업이 실패하는 경우 GitLab에 의해 보안 보고서 결과가 수집되지 않습니다. 실패를 허용하더라도, 작업에서 보고서 아티팩트가 여전히 GitLab에 업로드되어 있으며, 파이프라인 보안 탭에서 다운로드할 수 있습니다.

로깅

스캐너는 사용자가 CI 스캔 작업 로그를 확인하여 구성 오류 및 통합 문제를 쉽게 조사할 수 있도록 오류 메시지와 경고를 기록해야 합니다.

스캐너는 ANSI 이스케이프 코드를 사용하여 Unix 표준 출력 및 표준 에러 스트림에 쓰는 메시지에 색을 입힐 수 있습니다. 오류에는 빨간색, 경고에는 노란색, 알림에는 녹색을 사용하는 것이 좋습니다. 또한, 오류 메시지에는 [ERRO], 경고에는 [WARN], 알림에는 [INFO]를 접두어로 사용하는 것이 좋습니다.

로깅 레벨

스캐너는 로그 레벨이 SECURE_LOG_LEVEL CI/CD 변수에서 설정된 로그 메시지를 필터링해야 합니다. 예를 들어, info 및 warn 메시지는 SECURE_LOG_LEVEL이 error로 설정된 경우에는 건너뛰어야 합니다. 수신되는 값은 다음과 같습니다에 따라서 출력되며, 가장 높은 것부터 가장 낮은 것까지 나열됩니다:

• fatal
• error
• warn
• info
• debug

디버깅에 유용한 상세 로깅에 대해 debug 레벨을 사용하는 것이 좋습니다. SECURE_LOG_LEVEL의 기본값은 info로 설정하는 것이 좋습니다.

명령줄을 실행하는 경우, 명령 줄과 그 출력을 로깅하는 데 debug 레벨을 사용해야 합니다. 명령줄이 실패하는 경우, 문제를 디버깅하고 debug 로그 수준으로 변경하지 않고 스캔 작업을 다시 실행할 수 있는 부분에 에러 로그 레벨로 작성해야 합니다.

공통 logutil 패키지

만약 go와 common을 사용하고 있다면, Logrus 및 공통의 logutil 패키지를 구성하기 위해 Logrus의 포맷터를 사용하는 것이 좋습니다. logutil README를 확인하십시오.

보고서

보고서는 취약성과 가능한 권고 사항을 결합한 JSON 문서입니다.

이 문서에서는 보고서 JSON 형식, 권고 사항 및 설정 필드 도움말을 제공하여 통합자가 필드를 설정하는 데 도움이 되는 개요를 제공합니다. 형식은 SAST, DAST, 의존성 스캔, 그리고 컨테이너 스캔의 문서에서 상세하게 설명되어 있습니다.

해당 스캐너의 스키마는 여기서 찾을 수 있습니다:

• 컨테이너 스캔
• 커버리지 퍼징
• DAST
• 의존성 스캔
• SAST
• 시크릿 탐지

보고서 유효성 검사

• GitLab 15.0에 도입되었습니다.

스캐너에서 생성된 보고서가 선언된 스키마 버전에 대한 유효성을 통과해야 합니다. 유효성 검사를 통과하지 못한 보고서는 GitLab에서 수용되지 않으며 해당 파이프라인에 오류 메시지가 표시됩니다.

보안 보고서 스키마의 사용이 중단된 버전을 사용하는 보고서는 허용되지만 해당 파이프라인에 경고 메시지가 표시됩니다. 이 경고를 보면 최신 사용 가능한 스키마를 사용하도록 분석기를 업데이트해야 합니다.

스키마 버전에 대한 사용 중단 기간이 지난 후 파일이 GitLab에서 제거됩니다. 제거된 버전을 선언하는 보고서는 거부되며 해당 파이프라인에 오류 메시지가 표시됩니다.

보고서가 벤더가 지정한 스키마 버전과 일치하지 않는 PATCH 버전을 사용하는 경우, 해당 보고서는 최신 벤더 PATCH 버전과 일치하도록 유효성이 검사됩니다. 예를 들어, 보고서 버전이 15.0.23이고 최신 벤더 버전이 15.0.6이면 보고서는 15.0.6 버전에 대해 유효성이 검사됩니다.

GitLab은 유효성 검사를 수행하기 위해 json_schemer 젬을 사용합니다.

보고서 유효성 검사에 대한 계속적인 향상 사항은 이 에픽에서 추적됩니다. 한편, 지원되는 버전은 소스 코드에서 확인할 수 있습니다. 인스턴스에 적합한 올바른 버전을 선택해야 합니다. 예를 들어 v15.7.3-ee와 같은 버전입니다.

로컬에서 유효성 검사

GitLab에서 분석기를 실행하기 전에 분석기가 생성한 보고서가 선언된 스키마 버전을 준수하는지 확인하기 위해 보고서를 유효성 검사해야 합니다.

아래 스크립트를 사용하여 주어진 스키마에 대해 JSON 파일을 유효성을 검사하세요.

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'json_schemer'
end

require 'json'
require 'pathname'

raise 'Usage: ruby script.rb <security schema filename> <report filename>' unless ARGV.size == 2

schema = JSONSchemer.schema(Pathname.new(ARGV[0]))
report = JSON.parse(File.open(ARGV[1]).read)
schema_validation_errors = schema.validate(report).map { |error| JSONSchemer::Errors.pretty(error) }
puts(schema_validation_errors)

1. 보고서 유형과 선언된 버전과 일치하는 적절한 스키마를 다운로드하세요. 예를 들어, container_scanning 보고서 스키마의 버전 15.0.6은 다음에서 찾을 수 있습니다: https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/raw/v15.0.6/dist/container-scanning-report-format.json?inline=false.
2. 위의 루비 스크립트를 validate.rb와 같은 파일에 저장하세요.
3. 순서에 따라 스크립트를 실행하고 스키마와 보고서 파일 이름을 전달하여 스크립트를 실행하세요. 예를 들어:
   1. 로컬 Ruby 인터프리터 사용: ruby validate.rb container-scanning-format_15-0-6.json gl-container-scanning-report.json.
   2. Docker 사용: docker run -it --rm -v $(pwd):/ci ruby:3 ruby /ci/validate.rb /ci/container-scanning-format_15-0-6.json /ci/gl-container-scanning-report.json
4. 검증 오류가 화면에 표시됩니다. GitLab이 보고서를 수용하기 위해 이러한 오류를 해결해야 합니다.

보고서 필드

버전

이 필드는 사용 중인 Security Report Schemas 버전을 지정합니다. 사용할 버전에 대한 정보는 릴리스를 참조하세요.

GitLab은 이 값으로 지정된 스키마 버전에 대해 보고서를 유효성 검사합니다. GitLab에서 지원하는 버전은 gitlab/ee/lib/ee/gitlab/ci/parsers/security/validators/schemas에서 확인할 수 있습니다.

취약점

보고서의 vulnerabilities 필드는 취약점 객체의 배열입니다.

ID

id 필드는 취약점의 고유 식별자입니다. remediation objects에서 수정된 취약점을 참조하는 데 사용됩니다. UUID를 생성하고 id 필드의 값으로 사용하는 것이 좋습니다.

카테고리

category 필드의 값은 보고서 유형과 일치합니다:

• dependency_scanning
• container_scanning
• sast
• dast

스캔

scan 필드는 스캔 자체에 대한 메타 정보를 포함하는 객체입니다: 스캔을 실행한 analyzer 및 scanner, 스캔이 실행된 start_time 및 end_time, 스캔의 status(“success” 또는 “failure”).

analyzer 및 scanner 필드 모두에는 사람이 읽을 수 있는 name 및 기술적인 id가 포함되어야 합니다. id는 다른 통합자가 제공할 수 있는 다른 분석기 또는 스캐너와 충돌하면 안 됩니다.

스캔 주요 식별자

scan.primary_identifiers 필드는 분석기가 스캔을 실행한 주요 식별자)의 배열을 포함하는 선택적인 필드입니다. 이는 분석기가 실행한 규칙 세트의 모든 목록입니다.

특정 스캔에 대한 Vulnerabilities 배열이 비어 있더라도 이 선택적인 필드에는 실행된 규칙의 완전한 목록이 포함되어야 합니다. 이를 통해 Rails 애플리케이션에 이전에 감지된 취약점을 자동으로 해결할 때 이전에 감지된 취약점을 자동으로 해결할 수 있습니다.

완료된 경우, Rails 애플리케이션은 이전에 감지된 취약점을 자동으로 해결할 수 있습니다의 배열이 비어 있을 때 해당 배열이 비어 있으면 이전에 발견된 취약점을 자동으로 해결할 수 있습니다.

이름, 메시지 및 설명

name 및 message 필드에는 취약점에 대한 간단한 설명이 포함되어 있습니다. description 필드는 더 자세한 내용을 제공합니다.

name 필드는 컨텍스트 없이 있으며 취약점이 발견된 위치에 대한 정보가 포함되어 있지 않습니다. 반면 message는 위치를 반복할 수 있습니다.

시각적으로 다음 스크린샷은 파이프라인 보기의 일환으로 취약점을 볼 때 이러한 필드가 사용되는 경우를 보여줍니다.

예를 들어, 의존성 스캐닝에서 보고된 취약점의 message는 취약한 종속성에 대한 정보를 제공하지만 취약점의 location 필드와 유사한 정보를 반복합니다. name 필드가 선호되지만 컨텍스트/위치를 제목에서 제거할 수 없을 때 message 필드가 사용됩니다.

다음은 의존성 스캐닝 스캔기로 보고된 취약점 객체의 예시이며 message가 location을 반복하는 경우입니다.

{
    "location": {
        "dependency": {
            "package": {
            "name": "debug"
          }
        }
    },
    "name": "정규 표현식 거부 서비스",
    "message": "debug에서 정규 표현식 거부 서비스",
    "description": "이 디버그 모듈은 신뢰할 수 없는 사용자 입력이 `o` 포맷터로 전달될 때 정규 표현식 거부 서비스에 취약합니다.
        2초 동안 블록되기 위해 약 5만 글자가 소요되어 이는 낮은 심각도 문제입니다."
}

description은 취약점이 작동하는 방식이나 취약점에 대한 추가 정보를 설명해야 합니다. 특히 description은 취약점 객체의 다른 필드(어떤 영향을 받는지, 위험을 어떻게 완화하는지)을 반복해서는 안 됩니다.

솔루션

solution 필드를 사용하여 식별된 취약점을 수정하거나 위험을 완화하는 방법을 사용자에게 안내할 수 있습니다. 종단 사용자는 이 필드와 상호 작용하며, GitLab은 자동으로 remediations 객체를 처리합니다.

식별자

identifiers 배열은 감지된 취약점을 설명합니다. 식별자 객체의 type 및 value 필드는 두 개의 식별자가 동일한지 여부를 알려줍니다. 사용자 인터페이스는 객체의 name 및 url 필드를 사용하여 식별자를 표시합니다.

우리는 GitLab 스캐너에서 이미 정의한 식별자를 사용하는 것을 권장합니다.:

위에 나열된 일반적인 식별자들은 몇 가지 GitLab이 유지하는 분석기들 중 일부에서 공유되는 공통 라이브러리에 정의되어 있습니다. 필요한 경우 새로운 일반적인 식별자를 기여하실 수 있습니다. 분석기는 벤더별 또는 제품별 식별자도 생성할 수 있지만, 이러한 것들은 공통 라이브러리에 속하지 않습니다.

identifiers 배열의 첫 번째 항목을 주 식별자라고 부르며, 새로운 커밋이 저장소에 푸시됨에 따라 취약점을 추적하는 데 사용됩니다.

모든 취약점에는 CVE가 있는 것은 아니며, CVE는 여러 번 식별될 수 있습니다. 따라서 CVE는 안정적인 식별자가 아니며 취약점을 추적할 때 그렇게 가정해서는 안 됩니다.

취약점의 최대 식별자 수는 20으로 설정되어 있습니다. 취약점에 식별자가 20개 이상인 경우 시스템은 그 중 처음 20개만 저장합니다. 파이프라인 보안 탭의 취약점은 이 한도를 적용하지 않으며, 보고서 아티팩트에 있는 모든 식별자가 표시됩니다.

세부 정보

details 필드는 취약점 정보를 보는 동안 표시되는 여러 가지 콘텐츠 요소를 지원하는 객체입니다. 다양한 데이터 요소의 예시는 security-reports repository에서 확인할 수 있습니다.

위치

location은 취약점이 감지된 위치를 나타냅니다. 위치의 형식은 스캔 유형에 따라 다릅니다.

내부적으로 GitLab은 location의 일부 속성을 추출하여 위치 지문을 생성하며, 이는 새로운 커밋이 저장소에 푸시됨에 따라 취약점을 추적하는 데 사용됩니다. 위치 지문을 생성하는 데 사용되는 속성도 스캔 유형에 따라 다릅니다.

의존성 스캔

의존성 스캔 취약점의 location은 dependency와 file로 구성됩니다. dependency 객체는 영향을 받는 package와 의존성 version을 설명합니다. package는 영향을 받는 라이브러리/모듈의 name을 삽입합니다. file은 영향을 받는 의존성을 선언하는 의존성 파일의 경로입니다.

예를 들어, 다음은 npm 패키지 handlebars의 버전 4.0.11에 영향을 주는 취약점을 위한 location 객체입니다.

{
    "file": "client/package.json",
    "dependency": {
        "package": {
            "name": "handlebars"
        },
        "version": "4.0.11"
    }
}

이 영향을 받는 의존성은 npm 또는 yarn에서 처리되는 client/package.json에 나열되어 있습니다.

의존성 스캔 취약점의 위치 지문은 file과 패키지 name을 결합합니다. 따라서 이러한 속성은 필수입니다. 다른 모든 속성은 선택사항입니다.

컨테이너 스캔

의존성 스캔과 유사하게, 컨테이너 스캔 취약점의 location은 dependency와 file를 가지고 있습니다. 또한 operating_system 필드도 포함되어 있습니다.

예를 들어, 다음은 데비안 패키지 glib2.0 버전 2.50.3-2+deb9u1에 영향을 주는 취약점을 위한 location 객체입니다.

{
    "dependency": {
        "package": {
            "name": "glib2.0"
        },
    },
    "version": "2.50.3-2+deb9u1",
    "operating_system": "debian:9",
    "image": "registry.gitlab.com/example/app:latest"
}

영향을 받는 패키지는 registry.gitlab.com/example/app:latest에서 스캔되었습니다. Docker 이미지는 debian:9 (Debian Stretch)를 기반으로 합니다.

컨테이너 스캔 취약점의 위치 지문은 operating_system과 패키지 name을 결합합니다. 따라서 이러한 속성은 필수입니다. image 역시 필수입니다. 다른 모든 속성은 선택사항입니다.

SAST

SAST 취약점의 위치는 영향받은 파일의 경로를 제공하는 file와 start_line 필드로 이루어져 있어야 합니다. 또한 end_line, class, 그리고 method를 가질 수도 있습니다.

예를 들어, 다음은 location 객체로 Java 클래스 com.gitlab.security_products.tests.App의 generateSecretToken 메서드에서 발견된 src/main/java/com/gitlab/example/App.java 파일의 41번 라인에 있는 보안 결함입니다:

{
    "file": "src/main/java/com/gitlab/example/App.java",
    "start_line": 41,
    "end_line": 41,
    "class": "com.gitlab.security_products.tests.App",
    "method": "generateSecretToken1"
}

SAST 취약점의 위치 의 fingerprints는 file, start_line, end_line을 결합한 것이므로, 이러한 속성들은 필수적입니다. 다른 모든 속성들은 선택적입니다.

취약점 추적과 병합

사용자들은 취약점에 대한 피드백을 제공할 수 있습니다:

• 프로젝트에 해당하지 않는 취약점이라면 해당 취약점을 무시할 수 있습니다
• 가능한 위협이 있는 경우 취약점에 대한 이슈를 작성할 수 있습니다

GitLab은 사용자 피드백이 저장소로 새로운 Git 커밋이 푸시되어도 유실되지 않도록 취약점을 추적합니다. 취약점은 UUIDv5 다이제스트를 사용하여 추적되는데, 이는 네 가지 속성의 SHA-1 해시로 생성됩니다:

• 보고서 유형
• 기본 식별자
• 위치 fingerprint
• 프로젝트 ID

현재 GitLab은 새로운 Git 커밋이 푸시되면 위치가 변경되는 취약점을 추적할 수 없으며, 이로 인해 사용자 피드백이 유실됩니다. 예를 들어, 영향 받은 파일의 이름이 변경되거나, 영향 받은 라인이 이동하면 SAST 취약점에 대한 사용자 피드백이 손실됩니다. 이는 이슈 #7586에서 다루어지고 있습니다.

또한 중복 제거 프로세스를 참조하세요.

심각도

severity 필드는 취약점이 소프트웨어에 미치는 영향의 심각성을 설명합니다. 심각성은 보안 대시보드에서 취약점을 정렬하는 데 사용됩니다.

심각성은 Info에서 Critical까지 범위를 가지지만, Unknown일 수도 있습니다. 유효한 값은: Unknown, Info, Low, Medium, High, 또는 Critical입니다.

Unknown 값은 데이터가 없어 실제 값이 결정할 수 없다는 것을 의미합니다. 따라서 이것은 높음, 중간, 또는 낮음이 될 수 있으며 조사해야 합니다.

치료

보고서의 치료 필드는 치료 객체의 배열입니다. 각 치료는 취약점 해결을 위해 적용할 수 있는 패치를 설명합니다.

다음은 치료가 포함된 보고서의 예시입니다.

{
    "vulnerabilities": [
        {
            "category": "dependency_scanning",
            "name": "Regular Expression Denial of Service",
            "id": "123e4567-e89b-12d3-a456-426655440000",
            "solution": "Upgrade to new versions.",
            "scanner": {
                "id": "gemnasium",
                "name": "Gemnasium"
            },
            "identifiers": [
                {
                  "type": "gemnasium",
                  "name": "Gemnasium-642735a5-1425-428d-8d4e-3c854885a3c9",
                  "value": "642735a5-1425-428d-8d4e-3c854885a3c9"
                }
            ]
        }
    ],
    "remediations": [
        {
            "fixes": [
                {
                    "id": "123e4567-e89b-12d3-a456-426655440000"
                }
            ],
            "summary": "Upgrade to new version",
            "diff": "ZGlmZiAtLWdpdCBhL3lhcm4ubG9jayBiL3lhcm4ubG9jawppbmRleCAwZWNjOTJmLi43ZmE0NTU0IDEwMDY0NAotLS0gYS95Y=="
        }
    ]
}

요약

summary 필드는 취약점을 어떻게 수정할 수 있는지에 대한 개요입니다. 이 필드는 필수입니다.

해결된 취약점

fixes 필드는 치료에 의해 해결된 취약점을 참조하는 객체의 배열입니다. fixes[].id는 해결된 취약점의 고유 식별자를 포함합니다. 이 필드는 필수입니다.

Diff

diff 필드는 git apply와 호환되는 base64로 인코딩된 치료 코드 차이입니다. 이 필드는 필수입니다.