• 작업 정의
  • 이름
  • 이미지
  • 스크립트
  • 단계
  • 장애 안정
  • 아티팩트
  • 정책
    • 정책 확인 예시
• Docker 이미지
  • 이미지 크기
  • 이미지 태그
• 명령줄
  • 변수
    • SAST 및 의존성 스캔
    • 컨테이너 스캔
    • 구성 파일
  • 출력 파일
  • 종료 코드
  • 로깅
    • 로깅 레벨
    • 공통 logutil 패키지
• 보고서
  • 보고서 유효성 검사
    • 로컬에서 유효성 검사하기
  • 보고서 필드
    • 버전
    • 취약점
      • ID
      • 카테고리
      • 스캔
      • 스캔 주요 식별자
      • 이름, 메시지 및 설명
    • SAST
    • 취약점 추적 및 Merge
    • 심각도
    • 해결책
      • 요약
      • 수정된 취약점
      • 차이

보안 스캐너 통합

GitLab에 보안 스캐너를 통합하는 것은 엔드 사용자들이 자신들의 CI/CD 구성 파일에 추가할 수 있는 CI/CD 작업 정의를 제공하는 것으로 구성됩니다. 그렇게 하면 이 작업은 GitLab 프로젝트를 스캔하기 위한 결과를 GitLab 지정 형식으로 출력해야 합니다. 이후, 이러한 결과는 자동으로 GitLab의 여러 위치, 예를 들어 파이프라인 뷰, Merge Request 위젯 및 보안 대시보드에 표시됩니다.

스캔 작업은 일반적으로 스캐너와 해당 의존성을 모두 포함하는 도커 이미지를 기반으로 합니다.

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

작업 정의

이 섹션에서는 보안 스캐너의 작업 정의 파일에 추가해야 하는 몇 가지 중요한 필드에 대해 설명합니다. 이러한 및 다른 사용 가능한 필드에 대한 전체 설명서는 CI 문서에서 볼 수 있습니다.

이름

일관성을 유지하기 위해 스캔 작업은 소문자로 된 스캐너의 이름에 따라 명명되어야 합니다. 작업 이름은 스캔 유형 뒤에 접미사로 붙습니다:

• _dependency_scanning
• _container_scanning
• _dast
• _sast

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

이미지

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

스크립트

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

before_script는 작업 정의에서 사용해서는 안 되며, 사용자들이 스캔을 수행하기 전에 프로젝트를 준비하는 데 이에 의존할 수 있습니다. 예를 들어, 특정 프로젝트가 SAST 또는 의존성 스캐닝을 수행하기 전에 시스템 라이브러리를 설치하는 데 before_script를 사용하는 것은 흔한 관행입니다.

유사하게, after_script은 작업 정의에서 사용해서는 안 되며, 사용자들에 의해 덮어쓰일 수 있습니다.

단계

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

장애 안정

GitLab 보안 패러다임에 맞추기 위해, 스캔 작업은 실패할 경우 파이프라인을 차단해서는 안 되며, 따라서 allow_failure 매개변수는 true로 설정되어야 합니다.

아티팩트

스캔 작업은 수행하는 스캔 유형에 해당하는 보고서를 선언해야 하며, 이는 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은 예시 파일 경로이지만 다른 파일 이름을 사용할 수 있습니다. 또한, 이 파일이 SAST 보고서로 처리되는 것은 파일 이름 때문이 아니라 작업 정의의 reports: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'

사용자가 필요에 따라 사용자 지정 정책은 설정해야 합니다. 예를 들어, 미리 정의된 정책은 특정 브랜치에 대해 스캔 작업을 트리거하거나 특정 파일 세트가 변경될 때 스캔 작업을 트리거해선 안 되는 등이 있습니다.

Docker 이미지

Docker 이미지는 스캐너와 그 의존 라이브러리 및 도구들을 모두 결합한 독립된 환경입니다. 스캐너를 Docker 이미지로 패키징하면, 스캐너가 실행되는 개별 컴퓨터에 관계없이 항상 의존성과 구성이 갖춰져 있습니다.

이미지 크기

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

스캐너가 완전한 기능을 갖는 리눅스 환경이 필요한 경우, Debian의 “슬림” 배포판이나 Alpine Linux을 사용하는 것이 권장됩니다. 가능하다면 FROM scratch 지시문을 사용하여 이미지를 처음부터 빌드하고 필요한 모든 라이브러리로 스캐너를 컴파일하는 것이 권장됩니다. 다중 단계 빌드도 이미지 크기를 작게 유지하는 데 도움이 될 수 있습니다.

이미지 크기를 작게 유지하기 위해 dive를 사용하여 도커 이미지의 계층을 분석하여 추가적인 부피가 어디서 유래하는지를 확인할 수 있습니다.

경우에 따라, 이미지에서 파일을 제거하는 것이 어려울 수 있습니다. 이러한 경우, 파일이나 큰 디렉터리를 압축하기 위해 Zstandard를 사용하는 것을 고려해 보세요. Zstandard는 압축 수준이 여러 가지이며 압축 해제 속도에 매우 작은 영향을 미치는 많은 다른 압축 수준을 제공합니다. 이미지 크기를 크게 줄일 수 있습니다. 이미지가 시작될 때 압축된 디렉터리를 자동으로 자동으로 풀도록 만드는 것이 도움이 될 수 있습니다. 후자의 옵션을 선택한 경우, Docker 이미지의 진입점을 bash 로그인 쉘을 시작하도록 변경해야 합니다.

시작하려면 다음과 같은 예제들이 있습니다:

• 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 공식 이미지 프로젝트에서 문서화되었듯이, 특정 시리즈의 “가장 최근” 릴리스를 사용자가 쉽게 참조할 수 있도록 버전 번호 태그에 별칭을 지정하는 것이 권장됩니다. 또한 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/CD 변수의 조합인 $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG로 기본 설정되어야 합니다. 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에 업로드되는 모든 artifact와 마찬가지로, 스캐너에 의해 생성된 보안 보고서는 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에서 수용되지 않습니다. 작업이 실패를 허용한다 해도 그렇습니다. 그러나 보고서 artifact는 여전히 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 레벨을 사용해야합니다. 만일 커맨드 라인이 실패하면, 해당 것을 error 로깅해야합니다. 이렇게 함으로써 디버깅하거나 문제를 해결할 때 debug 레벨로 변경하고 스캔 작업을 재실행할 필요 없이 문제를 해결할 수 있습니다.

공통 logutil 패키지

만일 go 및 common을 사용하고 있다면, Logrus와 common의 ‘logutil’ 패키지를 구성하는 데 Logrus를 사용하는 것이 좋습니다. logutil README를 참조하세요.

보고서

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

이 문서는 통합자가 필드를 설정하는 데 도움을 주는 보고서 JSON 형식, 권고 및 예제에 대한 개요를 제공합니다. 형식은 SAST, DAST, 의존성 스캐닝 및 컨테이너 스캐닝의 문서에서 상세히 설명되어 있습니다.

이러한 스캐너의 스키마를 여기에서 찾을 수 있습니다:

• 컨테이너 스캐닝
• Coverage Fuzzing
• DAST
• 의존성 스캐닝
• SAST
• Secret Detection

보고서 유효성 검사

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

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

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

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

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

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

보고서 유효성 검사에 대한 지속적인 개선 사항은 이 Epic에서 추적됩니다. 한편, 현재 지원되는 버전은 소스 코드에서 확인할 수 있습니다. 해당 인스턴스에 맞는 올바른 버전을 선택해야 합니다. 예를 들어, 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 validate.rb container-scanning-format_15-0-6.json gl-container-scanning-report.json.
   2. 도커 사용: 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이 보고서를 수용할 수 있습니다.

보고서 필드

버전

이 필드는 사용 중인 보안 보고서 스키마 버전을 나타냅니다. 사용할 버전에 대한 정보는 릴리스를 참조하세요.

GitLab 14.10 이후에는 GitLab이이 값으로 지정된 스키마 버전을 기준으로 보고서를 유효성 검사합니다. GitLab이 지원하는 버전은 gitlab/ee/lib/ee/gitlab/ci/parsers/security/validators/schemas에서 찾을 수 있습니다.

취약점

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

ID

id 필드는 취약점의 고유 식별자입니다. 이를 사용하여 보완 개체에서 고정된 취약점을 참조합니다. 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는 위치를 반복할 수 있습니다.

시각적으로 예를 들어, 다음 스크린샷은 취약점을 보는 데 사용되는 경우 이러한 필드가 어디에 사용되는지 강조합니다.

예를 들어 Dependency Scanning으로 보고된 취약점의 message는 취약한 의존성에 대한 정보를 제공하지만, 이는 취약점의 location 필드와 중복되는 정보이며 name 필드가 우선되지만 컨텍스트/위치를 취약점 제목에서 제거할 수 없을 때 message 필드가 사용됩니다.

예를 들어, Dependency Scanning 스캐너에 의해 보고된 취약점 객체의 예는 다음과 같습니다. 여기서 message가 location 필드를 반복합니다:

{
    "location": {
        "dependency": {
            "package": {
            "name": "debug"
          }
        }
    },
    "name": "정규 표현식 거부 서비스",
    "message": "debug에서 정규 표현식 거부 서비스",
    "description": "debug 모듈은 신뢰할 수 없는 사용자 입력이 `o` 포맷터로 전달될 때 정규 표현식 거부 서비스에 노출됩니다.
        2초 동안 50,000자의 문자를 블록하는 데 약 2초가 걸리므로 이것은 낮은 심각도의 문제입니다."
}

`description`은 취약점의 작동 방식을 설명하거나 exploit에 대한 컨텍스트를 제공할 수 있습니다. 
취약점 객체의 다른 필드를 반복해서는 안 됩니다. 특히 `description`은 `location`(영향을 받는 항목)이나 `solution`(위험 완화 방법)을 반복해서는 안 됩니다.

##### 해결책

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

##### 식별자

`identifiers` 배열은 감지된 취약점을 설명합니다. 식별자 객체의 `type` 및 `value` 필드는 [두 식별자가 동일한지](../../user/application_security/vulnerability_report/pipeline.md#deduplication-process)를 알려주는 데 사용됩니다.
사용자 인터페이스는 객체의 `name` 및 `url` 필드를 사용하여 식별자를 표시합니다.

GitLab 스캐너가 이미 정의하는 식별자를 사용하는 것이 좋습니다.
예를 들어:

| 식별자 | 유형 | 예시 값 |
|------------|------|---------------|
| [CVE](https://cve.mitre.org/cve/) | `cve` | CVE-2019-10086 |
| [CWE](https://cwe.mitre.org/data/index.html) | `cwe` | CWE-1026 |
| [ELSA](https://linux.oracle.com/security/) | `elsa` | ELSA-2020-0085 |
| [OSVD](https://cve.mitre.org/data/refs/refmap/source-OSVDB.html) | `osvdb` | OSVDB-113928 |
| [OWASP](https://owasp.org/Top10/) | `owasp` | A01:2021–Broken Access Control Design |
| [RHSA](https://access.redhat.com/errata-search/#/) | `rhsa` | RHSA-2020:0111 |
| [USN](https://ubuntu.com/security/notices) | `usn` | USN-4234-1 |
| [WASC](http://projects.webappsec.org/Threat-Classification-Reference-Grid)  | `wasc` | WASC-19 |

위의 일반 식별자는 GitLab이 유지 관리하는 분석기 중 일부에서 사용되는 [공통 라이브러리](https://gitlab.com/gitlab-org/security-products/analyzers/common)에 정의되어 있습니다. 필요한 경우
새로운 일반 식별자를 [기여](https://gitlab.com/gitlab-org/security-products/analyzers/common/blob/master/issue/identifier.go)할 수 있습니다. 
분석기는 또한 벤더별이나 제품별 식별자를 생성할 수 있으며 이러한 식별자는 [공통 라이브러리](https://gitlab.com/gitlab-org/security-products/analyzers/common)에 속하지 않습니다.

`identifiers` 배열의 첫 번째 항목을 [기본 식별자](../../user/application_security/terminology/index.md#primary-identifier)라고 하며 이는 새로운 커밋이 리포지터리로 푸시됨에 따라
[취약점을 추적](#tracking-and-merging-vulnerabilities)하는 데 사용됩니다.

모든 취약점에는 CVE가 없을 수 있으며, CVE는 여러 번 식별될 수 있습니다. 결과적으로, CVE는 안정적인 식별자가 아니며 취약점을 추적할 때 이를 가정해서는 안 됩니다.

취약점의 식별자 최대 수는 20으로 설정됩니다. 취약점이 20개 이상의 식별자를 가진 경우 시스템은 처음 20개만 저장합니다. 
[파이프라인 보안](../../user/application_security/vulnerability_report/pipeline.md#view-vulnerabilities-in-a-pipeline) 탭의 취약점은 이 제한을 강제하지 않고 보고서 artifact에 있는 모든 식별자를 표시합니다.

#### 세부정보

`details` 필드는 취약점 정보를 보는 데 사용되는 여러 다른 콘텐츠 요소를 지원하는 객체입니다. 
여러 데이터 요소의 예시는 [security-reports 리포지터리](https://gitlab.com/gitlab-examples/security/security-reports/-/tree/master/samples/details-example)에서 볼 수 있습니다.

#### 위치

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

내부적으로 GitLab은 `location`의 일부 속성을 추출하여 **위치 fingerprint**을 생성하며, 이는 새로운 커밋이 리포지터리로 푸시됨에 따라 취약점을 추적하는 데 사용됩니다.
위치 fingerprint를 생성하기 위해 사용되는 속성도 스캔 유형에 따라 달라집니다.

의존성 스캐닝

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

예를 들어, npm 패키지 [`handlebars`](https://www.npmjs.com/package/handlebars)의 버전 `4.0.11`에 영향을받는 취약점의 `location` 객체는 다음과 같습니다:

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

이 영향을 받는 의존성은 npm이나 yarn으로 처리하는 `client/package.json`에 나열되어 있습니다.
의존성 스캐닝 취약점의 위치 fingerprint는 `file`과 패키지 `name`을 결합하므로 이러한 속성이 필수입니다. 
다른 모든 속성은 선택 사항입니다.

#### 컨테이너 스캐닝

의존성 스캐닝과 유사하게, 컨테이너 스캐닝 취약점의 `위치`에는 `의존성`과 `파일`이 있습니다. 또한 `operating_system` 필드가 있습니다.

예를 들어, Debian 패키지 `glib2.0`의 버전 `2.50.3-2+deb9u1`에 영향을 주는 취약점의 `위치` 객체는 다음과 같습니다:

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

취약한 패키지는 Docker 이미지 registry.gitlab.com/example/app:latest를 스캔할 때 발견됩니다. 해당 Docker 이미지는 debian:9 (Debian Stretch)를 기반으로 합니다.

컨테이너 스캐닝 취약점의 위치 지문은 operating_system과 패키지 name을 결합하므로 이러한 속성들은 필수입니다. image 또한 필수입니다. 다른 모든 속성들은 선택 사항입니다.

SAST

SAST 취약점의 위치에는 영향을 받는 파일의 경로를 나타내는 file과 영향을 받는 줄 번호를 제공하는 start_line 필드가 있어야 합니다. 또한 end_line, class, 그리고 method가 있을 수 있습니다.

예를 들어, generateSecretToken 메서드에 있는 com.gitlab.security_products.tests.App Java 클래스의 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 취약점의 위치 지문은 file, start_line, end_line을 결합하므로 이러한 속성들이 필수입니다. 다른 모든 속성들은 선택 사항입니다.

취약점 추적 및 Merge

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

• If doesn’t apply to their projects, they may dismiss a vulnerability
• If there’s a possible threat, they may create an issue for a vulnerability

GitLab은 사용자 피드백이 리포지터리에 새로운 Git 커밋이 푸시될 때 유실되지 않도록 취약점을 추적합니다. 취약점은 다음 네 가지 속성의 SHA-1 해시로 생성된 UUIDv5 다이제스트를 사용하여 추적됩니다.

• Report type
• Primary identifier
• Location fingerprint
• Project ID

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

또한 중복 처리 프로세스를 참조하십시오.

심각도

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

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

Unknown 값은 이 값을 결정하는 데 필요한 데이터를 사용할 수 없다는 것을 의미합니다. 따라서 이 값은 High, Medium, 또는 Low일 수 있으며 조사가 필요합니다. 현재 사용 가능한 SAST Analyzers와 해당 데이터에 대한 표를 제공했습니다.

해결책

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

다음은 remediations을 포함하는 보고서의 예시입니다.

{
    "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 필드는 remediation에 의해 수정된 취약점을 참조하는 객체의 배열입니다. fixes[].id에는 수정된 취약점의 고유 식별자가 포함됩니다. 이 필드는 필수입니다.

차이

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