보안 스캐너 통합

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 항목은 비워둘 수 없으므로 스캔을 수행하는 명령으로 설정해야 합니다. 스캔을 수행하기 위해 미리 정의된 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은 예시 파일 경로입니다. 다른 파일 이름을 사용할 수도 있습니다. 이는 작업 정의의 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 변수를 확인하세요.

정책 확인 예시

다음은 프로젝트 리포지터리에 자바 소스 코드가 포함되어 있고 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 이하로 유지해야 합니다. 그렇게 할 수 없는 경우에는 DVD-ROM 크기인 1.46GB 이하로 유지해야 합니다.

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

이미지 크기를 작게 유지하려면 dive를 사용하여 Docker 이미지의 레이어를 분석하여 추가 비효율을 식별할 수 있습니다.

일부 경우에는 이미지에서 파일을 제거하기 어려울 수 있습니다. 이런 경우에는 Zstandard를 사용하여 파일이나 큰 디렉터리를 압축하는 것을 고려해야 합니다. Zstandard는 압축 수준의 선택지를 많이 제공하여 압축 해제 속도에 거의 영향을 미치지 않으면서 이미지 크기를 감소시킬 수 있습니다. 이미지를 시작하자마자 모든 압축된 디렉터리를 자동으로 해제하는 것이 유용할 수 있습니다. 이 경우 Docker 이미지의 /etc/bashrc나 특정 사용자의 $HOME/.bashrc에 단계를 추가해야 할 수 있습니다. 만약 후자의 옵션을 선택한다면 bash 로그인 셸을 시작하도록 진입점을 변경해야 합니다.

다음은 시작을 빠르게 하기 위한 몇 가지 예시입니다:

이미지 태그

Docker Official Images 프로젝트의 문서에 따르면, 특정 버전 번호 태그에 별칭을 지정하는 것이 강력히 권장되며, 이를 통해 사용자가 “가장 최근” 릴리스를 쉽게 참조할 수 있게 됩니다. 또한, 도커 태깅: 도커 이미지에 대한 최선의 태깅 및 버전 관리 사례도 참조하세요.

명령줄

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

변수

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

SAST 및 의존성 스캔

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

컨테이너 스캔

공식 Container Scanning for 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와 마찬가지로, 스캐너가 생성한 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에 흡수되지 않습니다. 그러나 보고서 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 로그 레벨로 기록해야 합니다.

공통 `logutil` 패키지

만약 Go 및 공통을 사용 중이라면, Logrus 및 공통 ‘logutil’ 패키지를 구성하기 위해 Logrus의 포매터로 우리는 logutil README를 사용하는 것이 권장됩니다.

보고서

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

이 설명서에는 보고서 JSON 형식, 권장 사항 및 예제를 통해 통합자가 필드를 설정하는 데 도움을 주기 위해 보고서가 상세하게 설명되어 있습니다. 형식은 SAST, DAST, Dependency Scanning 및 Container Scanning의 문서에서 자세히 설명되어 있습니다.

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

보고서 유효성 검사

GitLab 15.0에서 소개.

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

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

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

스키마 버전 선언 시 PATCH 버전이 제공되지 않는 경우, 가장 최신의 PATCH 버전에 대해 검증합니다. 예를 들어, 보고서 버전이 15.0.23이고 최신의 vendored 버전이 15.0.6인 경우, 해당 보고서는 버전 15.0.6에 대해 검증됩니다.

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

보고서 검증에 대한 지속적인 개선은 이 에픽에서 추적됩니다. 그 동안, 지원되는 버전을 확인할 수 있습니다. 소스 코드에서 올바른 버전을 선택하세요. 예를 들어 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)

보고서 유형과 선언된 버전과 일치하는 적절한 스키마를 다운로드하세요. 예를 들어, 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.
위의 루비 스크립트를 validate.rb와 같이 파일에 저장하세요.
순서대로 스키마 및 보고서 파일 이름을 인수로 사용하여 스크립트를 실행하세요. 예를 들어:
1. 로컬 루비 인터프리터를 사용하는 경우: 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
유효성 오류가 화면에 표시됩니다. GitLab이 보고서를 처리하기 전에 이러한 오류를 해결해야 합니다.

보고서 필드

버전

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

GitLab은 이 값을 통해 보고서의 유효성을 지원되는 스키마 버전에 대해 확인합니다. GitLab에서 지원하는 버전은 gitlab/ee/lib/ee/gitlab/ci/parsers/security/validators/schemas에서 찾을 수 있습니다.

취약점

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

ID

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

스캔

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

분석기 및 스캐너 필드는 사람이 읽을 수 있는 이름과 기술적인 id를 포함하는 객체입니다. id는 다른 통합자가 제공하는 분석기나 스캐너와 충돌하지 않아야 합니다.

스캔 기본 식별자

scan.primary_identifiers 필드는 스캔이 수행한 기본 식별자(primary identifiers)의 배열을 포함하는 선택적인 필드입니다. 이 필드는 분석기가 실행한 모든 ruleset의 완전한 디렉터리입니다.

특정 스캔의 취약점 배열이 비어 있더라도 이 선택적인 필드에는 이전에 감지된 취약성을 자동으로 해결하는 데 필요한 모든 식별자의 완전한 디렉터리이 포함되어야 합니다.

이 필드가 채워진 경우, Rails 애플리케이션은 해당 기본 식별자가 포함되지 않은 경우 이전에 감지된 취약성을 자동으로 해결할 수 있습니다.

이름, 메시지 및 설명

name 및 message 필드는 취약점에 대한 간략한 설명을 포함합니다. description 필드는 더 많은 세부 정보를 제공합니다.

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

시각적인 예로, 이 스크린샷은 파이프라인 뷰의 일환으로 취약점을 볼 때 이러한 필드가 사용된 위치를 강조하고 있습니다.

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

다음은 Dependency Scanning 스캐너가 보고한 예시 취약점 객체이며, message가 location 필드를 반복하는 경우입니다.

{
    "location": {
        "dependency": {
            "package": {
            "name": "debug"
          }
        }
    },
    "name": "Regular Expression Denial of Service",
    "message": "Regular Expression Denial of Service in debug",
    "description": "The debug module is vulnerable to regular expression denial of service
        when untrusted user input is passed into the `o` formatter.
        It takes around 50k characters to block for 2 seconds making this a low severity issue."
}

description은 취약점이 작동하는 방법이나 취약점에 대한 컨텍스트 등을 설명할 수 있습니다. 특히, description은 취약점 객체의 다른 필드들(영향을 받는 위치 또는 위험 완화 방법 등)을 반복해서는 안 됩니다.

해결 방법

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

식별자

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

GitLab 스캐너에서 이미 정의된 식별자를 사용하는 것이 좋습니다:

식별자	유형	예시 값
CVE	`cve`	CVE-2019-10086
CWE	`cwe`	CWE-1026
ELSA	`elsa`	ELSA-2020-0085
OSVD	`osvdb`	OSVDB-113928
OWASP	`owasp`	A01:2021–Broken Access Control Design
RHSA	`rhsa`	RHSA-2020:0111
USN	`usn`	USN-4234-1
WASC	`wasc`	WASC-19

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

identifiers 배열의 첫 번째 항목을 기본 식별자라고 하며, 이는 새로운 커밋이 리포지터리에 푸시됨에 따라 취약점을 추적하는 데 사용됩니다.

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

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

상세정보

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

위치

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

내부적으로 GitLab은 location의 일부 속성을 추출하여 위치 지문을 생성하여, 리포지터리로 새로운 커밋이 푸시될 때 취약점을 추적하는 데 사용합니다. 위치 지문을 생성하는 데 사용되는 속성은 스캔 유형에 따라 다릅니다.

디펜던시 스캔

디펜던시 스캔 취약점의 location은 dependency와 file으로 구성됩니다. dependency 객체는 영향을 받는 패키지와 의존성 버전을 설명합니다. package는 영향을 받는 라이브러리/모듈의 이름을 내장합니다. file은 영향을 받는 의존성을 선언하는 의존성 파일의 경로입니다.

예를 들어, 여기에 있는 npm 패키지 handlebars의 버전 4.0.11에 영향을 주는 취약성의 location 객체는 다음과 같습니다.

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

이 영향을 받는 의존성은 client/package.json에 나열되어 있으며, 이는 npm 또는 yarn에 의해 처리되는 의존성 파일입니다.

디펜던시 스캔 취약점의 위치 지문은 file과 패키지 name을 결합하므로 이러한 속성은 필수입니다. 다른 모든 속성은 선택 사항입니다.

컨테이너 스캔

디펜던시 스캔과 유사하게 컨테이너 스캔 취약점의 location은 dependency와 file을 포함합니다. 또한 operating_system 필드가 있습니다.

예를 들어, Debian 패키지 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 이미지를 스캔할 때 찾습니다. Docker 이미지는 debian:9 (Debian Stretch)를 기반으로 합니다.

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

SAST

SAST 취약점의 location은 영향을 받는 파일의 경로를 제공하는 file과 영향을 받는 줄 번호를 나타내는 start_line 필드가 있어야 합니다. end_line, class, method가 포함될 수도 있습니다.

예를 들어, 여기에 있는 src/main/java/com/gitlab/example/App.java의 41번 라인에서 발견된 보안 결함에 대한 location 객체는 다음과 같습니다.

{
    "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

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

자신의 프로젝트에 적용되지 않는 경우 취약점을 해제할 수 있습니다.
가능한 위협이 있는 경우 취약점에 대한 이슈를 생성할 수 있습니다.

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

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

지금은 GitLab이 위치가 변경되면 취약점을 추적할 수 없지만, 이로 인해 사용자 피드백이 손실될 수 있습니다. 예를 들어, 영향을 받는 파일의 이름이 변경되거나 영향을 받는 줄 번호가 아래로 이동하는 경우 SAST 취약점에 대한 사용자 피드백이 손실됩니다. 이 문제는 issue #7586에서 다루어지고 있습니다.

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

심각도

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

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

Unknown 값은 데이터가 실제 값이 결정되기에는 충분하지 않다는 의미입니다. 따라서 높음, 중간, 또는 낮음이 될 수 있으며 조사가 필요합니다. 현재 사용 가능한 SAST Analyzers 및 현재 사용 가능한 데이터에 대한 차트를 제공했습니다.

복구

보고서의 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 필드는 수정 사항을 참조하는 객체 배열입니다. fixes[].id에는 수정된 취약점의 고유 식별자가 포함되어 있습니다. 이 필드는 필수입니다.

차이

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

보안 스캐너 통합

작업 정의

이름

이미지

스크립트

스테이지

실패 안전

아티팩트

정책

정책 확인 예시

Docker 이미지

이미지 크기

이미지 태그

명령줄

변수

SAST 및 의존성 스캔

컨테이너 스캔

구성 파일

출력 파일

종료 코드

로깅

로그 레벨

공통 logutil 패키지

보고서

보고서 유효성 검사

로컬에서 유효성 검사

보고서 필드

버전

취약점

ID

카테고리

스캔

스캔 기본 식별자

이름, 메시지 및 설명

해결 방법

식별자

상세정보

위치

디펜던시 스캔

컨테이너 스캔

SAST

취약점 추적 및 Merge

심각도

복구

요약

수정된 취약점

차이

도움말

기능 사용 가능성과 제품 평가판

도움받기

공통 `logutil` 패키지