• 기능
• Prerequisites
• Configuration
  • 컨테이너 스캐닝 설정 사용자화
    • 원격 레지스트리에 있는 이미지 스캔
      • 원격 레지스트리에 인증
    • 의존성 디렉터리
    • 언어별 결과 보고
    • Merge Request 파이프라인에서 작업 실행하기
    • 사용 가능한 CI/CD 변수
  • 지원되는 배포
    • FIPS 사용 이미지
  • 자동 Merge Request을 통해 컨테이너 스캔 활성화
  • 컨테이너 스캐닝 템플릿 재정의
  • 스캐너 변경
  • 기본 브랜치 이미지 설정
  • 사용자 정의 SSL CA 인증서 사용
  • 취약점 화이트리스트 지정
    • vulnerability-allowlist.yml 데이터 형식
      • 파일 형식
      • 컨테이너 스캐닝 작업 로그 형식
  • 오프라인 환경에서 컨테이너 스캐닝 실행
    • 오프라인 컨테이너 스캐닝 요구 사항
      • 사용자 정의 인증 기관 지원
    • 로컬 Docker 레지스트리 내에서 GitLab 컨테이너 스캐닝 분석기 이미지 사용 가능하게 만들기
    • 로컬 컨테이너 스캐너 분석기를 사용하는 컨테이너 스캐닝 CI/CD 변수 설정
    • 파이프라인을 이용한 컨테이너 스캐닝 취약점 데이터베이스 업데이트 자동화
    • 외부 개인 레지스트리에서 이미지 스캔
    • Trivy Java 데이터베이스 미러 생성 및 사용하기
• 스탠드얼론 컨테이너 스캐닝 도구 실행
• 리포트 JSON 형식
  • CycloneDX 소프트웨어 컴포넌트 디렉터리
• 보안 대시보드
• 취약점 데이터베이스
• 취약점과 상호 작용하기
• 취약점에 대한 해결책 (자동 복구)
• 문제 해결
  • docker: Error response from daemon: failed to copy xattrs
  • “gl-container-scanning-report.json: no matching files” 경고 메시지 받기
  • AWS ECR에서 이미지를 스캔할 때 unexpected status code 401 Unauthorized: Not Authorized 메시지 받기
• 변경 사항

Container Scanning

• 변경 사항으로 GitLab 15.0에서 주요 분석기 버전을 4에서 5로 변경했습니다.
• GitLab Ultimate에서 GitLab Free로 이전되었습니다. (GitLab 15.0)
• GitLab 15.4에서 Docker를 참조하는 Container Scanning 변수 이름이 변경되었습니다.
• GitLab 15.6에서 Container Scanning 템플릿이 Security/Container-Scanning.gitlab-ci.yml에서 Jobs/Container-Scanning.gitlab-ci.yml로 이동되었습니다.

귀하의 애플리케이션 Docker 이미지는 자체적으로 알려진 취약점을 포함하고 있을 수 있습니다. Merge Request에서 해당 취약점을 검사하고 표시하는 추가 Container Scanning 작업을 파이프라인에 포함하여 GitLab을 사용하여 Docker 기반 앱을 감사할 수 있습니다.

• 개요는 Container Scanning를 참조하세요.
• 비디오 안내는 GitLab을 사용하여 Container Scanning 설정하는 방법를 참조하세요.

Container Scanning은 종종 소프트웨어 구성 분석(SCA)의 일부로 간주됩니다. SCA에는 코드에서 사용하는 항목을 검사하는 측면이 포함될 수 있습니다. 이러한 항목에는 대부분 외부 소스에서 가져온 응용 프로그램 및 시스템 의존성이 포함되는데, 직접 작성한 항목이 아닙니다.

GitLab은 모든 이러한 의존성 유형을 커버하기 위해 Container Scanning 및 Dependency Scanning을 제공합니다. 가능한 모든 리스크 영역을 커버하기 위해 모든 보안 스캐너를 사용할 것을 권장합니다. 이러한 기능을 비교하려면 Dependency Scanning compared to Container Scanning를 참조하세요.

GitLab은 컨테이너의 취약점 정적 분석을 위해 오픈 소스 도구를 통합합니다:

• Trivy
• Grype

여기에 나열된 도구 이외의 보안 스캐너를 GitLab과 통합하려면 보안 스캐너 통합을 참조하세요.

다음 중 하나를 수행하여 컨테이너 스캔을 활성화할 수 있습니다:

• 기존의 .gitlab-ci.yml 파일에 CI 작업을 포함하세요.
• Auto DevOps에서 제공하는 Auto Container Scanning을 묵시적으로 사용하세요.

GitLab은 발견된 취약점을 소스와 타겟 브랜치 간에 비교하고 Merge Request에서 직접 정보를 표시합니다.

기능

Prerequisites

파이프라인에서 컨테이너 스캐닝을 활성화하려면 다음이 필요합니다.

• GitLab CI/CD 파이프라인에는 stages 키워드로 오버라이드하지 않는 한 기본적으로 사용할 수 있는 test 단계가 포함되어 있어야 합니다.
• Linux/amd64에서 실행하는 docker 또는 kubernetes executor가 있는 GitLab Runner.
• GitLab.com의 인스턴스 러너를 사용하는 경우 실행하는 컴퓨터에 이미 Docker 18.09.03 이상이 설치되어 있어야 합니다.
• 지원되는 배포판과 일치하는 이미지가 필요합니다.
• Docker 이미지를 프로젝트의 컨테이너 레지스트리에 빌드하고 푸시해야 합니다.
• 서드파티 컨테이너 레지스트리를 사용하는 경우 CS_REGISTRY_USER 및 CS_REGISTRY_PASSWORD configuration variables를 통해 인증 자격 증명을 제공해야 할 수 있습니다. 이 변수들을 사용하는 방법에 대한 자세한 내용은 원격 레지스트리에 인증를 참조하세요.

Configuration

컨테이너 스캐닝을 활성화하려면.gitlab-ci.yml 파일에 Container-Scanning.gitlab-ci.yml 템플릿을 추가하세요.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

추가된 템플릿은:

• CI/CD 파이프라인에서 container_scanning 작업을 생성합니다.
• 프로젝트의 컨테이너 레지스트리에서 빌드된 Docker 이미지를 가져와 가능한 취약점을 스캔합니다.

GitLab은 결과를 컨테이너 스캐닝 보고서 artifact로 저장하여 나중에 다운로드하고 분석할 수 있습니다. 다운로드할 때 항상 가장 최근 artifact를 받게 됩니다. 의존성 스캔이 활성화된 경우 의존성 스캔 보고서 artifact도 생성됩니다.

다음은 Docker 이미지를 빌드하고 컨테이너 레지스트리에 푸시한 후 이미지를 스캔하는 샘플 .gitlab-ci.yml입니다.

include:
  - template: Jobs/Build.gitlab-ci.yml
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_DEFAULT_BRANCH_IMAGE: $CI_REGISTRY_IMAGE/$CI_DEFAULT_BRANCH:$CI_COMMIT_SHA

CS_DEFAULT_BRANCH_IMAGE를 설정하면 브랜치별로 이미지 이름이 다를 때 중복 취약점 결과를 피할 수 있습니다. CS_DEFAULT_BRANCH_IMAGE의 값은 기본 브랜치에 표시되는 스캔된 이미지의 이름을 나타냅니다. 이 중복 제거가 어떻게 이루어지는지에 대한 자세한 내용은 기본 브랜치 이미지 설정을 참조하세요.

컨테이너 스캐닝 설정 사용자화

GitLab이 컨테이너를 스캔하는 방식을 사용자화할 필요가 있는 경우가 있습니다. 예를 들어 보다 자세한 출력을 활성화하거나 인증이 필요한 Docker 레지스트리에 접근하는 경우가 있을 수 있습니다. 이러한 설정을 변경하려면 .gitlab-ci.yml에서 CI/CD variables를 설정하려면 variables 매개변수를 사용하세요. .gitlab-ci.yml에서 설정한 변수는 Container-Scanning.gitlab-ci.yml에 정의된 변수를 덮어씁니다.

다음 예제는 컨테이너 스캐닝 템플릿을 include하고 분석기에 대해 자세한 출력을 활성화하는 경우입니다.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

variables:
    SECURE_LOG_LEVEL: 'debug'

원격 레지스트리에 있는 이미지 스캔

프로젝트의 컨테이너 레지스트리가 아닌 다른 레지스트리에 있는 이미지를 스캔하려면 다음 .gitlab-ci.yml을 사용하세요.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_IMAGE: example.com/user/image:tag

원격 레지스트리에 인증

비공개 레지스트리의 이미지를 스캔하려면 CS_REGISTRY_USER 변수에 사용자 이름을, CS_REGISTRY_PASSWORD 구성 변수에 비밀번호를 제공해야 합니다.

예를 들어 AWS Elastic Container Registry에서 이미지를 스캔하는 경우:

container_scanning:
  before_script:
    - ruby -r open-uri -e "IO.copy_stream(URI.open('https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip'), 'awscliv2.zip')"
    - unzip awscliv2.zip
    - sudo ./aws/install
    - aws --version
    - export AWS_ECR_PASSWORD=$(aws ecr get-login-password --region region)

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

variables:
    CS_IMAGE: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag>
    CS_REGISTRY_USER: AWS
    CS_REGISTRY_PASSWORD: "$AWS_ECR_PASSWORD"
    AWS_DEFAULT_REGION: <region>

원격 레지스트리에 인증하는 것은 FIPS mode가 활성화된 경우에는 지원되지 않습니다.

의존성 디렉터리

• GitLab 14.6에서 도입됨.

CS_DISABLE_DEPENDENCY_LIST CI/CD 변수는 스캔이 의존성 디렉터리 보고서를 생성하는지 여부를 제어합니다. 이 변수는 현재 trivy 분석기를 사용할 때만 지원됩니다. 변수의 기본 설정인 "false"은 보고서를 생성하도록 합니다. 보고서를 비활성화하려면 변수를 "true"로 설정하세요.

예를 들어:

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_DISABLE_DEPENDENCY_LIST: "true"

언어별 결과 보고

• GitLab 14.6에서 도입됨.

CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN CI/CD 변수는 프로그래밍 언어와 관련된 결과를 보고하는지 여부를 제어합니다. 지원되는 언어는 사용하는 스캐너에 따라 다릅니다:

• Trivy
• Grype.

기본적으로 보고서에는 운영 체제(OS) 패키지 관리자(예: yum, apt, apk, tdnf)로 관리되는 패키지만 포함됩니다. 비-OS 패키지의 보안 결과를 보고하려면 CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN을 "false"로 설정하세요.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false"

이 기능을 활성화하면 프로젝트에 의존성 스캔이 활성화된 경우 Vulnerability Report에서 중복 결과를 볼 수 있습니다. 이는 GitLab이 다른 유형의 스캔 도구에 걸쳐 중복 결과를 자동으로 제거할 수 없기 때문에 발생합니다. 어떤 유형의 의존성이 중복되어 나타날 가능성이 있는지 이해하려면 Dependency Scanning compared to Container Scanning을 참조하세요.

Merge Request 파이프라인에서 작업 실행하기

Merge Request 파이프라인에서 보안 스캔 도구 사용하기를 참조하세요.

사용 가능한 CI/CD 변수

다음 CI/CD 변수를 사용하여 분석기를 구성할 수 있습니다.

1. 수정 상태 정보는 소프트웨어 공급업체 및 컨테이너 이미지 운영 체제 패키지 메타데이터에서의 정확한 수정 가능성 데이터와 개별 컨테이너 스캐너에 따라 해석의 영향을 받습니다. 컨테이너 스캐너가 취약성의 수정된 패키지의 가용성을 잘못 보고하는 경우, `CS_IGNORE_STATUSES`를 사용하면 이 설정이 활성화된 경우 취약점 검색 결과의 거짓 긍정 또는 부정 필터링으로 이어질 수 있습니다.

지원되는 배포

지원은 사용되는 스캐너에 따라 다릅니다:

FIPS 사용 이미지

• 소개됨 GitLab 14.1에서.

GitLab은 또한 컨테이너 스캐닝 이미지의 FIPS 지원 Red Hat UBI 버전을 제공합니다. 따라서 표준 이미지를 FIPS 지원 이미지로 대체 할 수 있습니다. 이미지를 구성하려면 CS_IMAGE_SUFFIX를 -fips로 설정하거나 CS_ANALYZER_IMAGE 변수를 표준 태그와 -fips 확장으로 수정하십시오.

GitLab 14.10부터 FIPS 모드가 GitLab 인스턴스에서 활성화되면 CS_ANALYZER_IMAGE에 자동으로 -fips가 추가됩니다.

FIPS 모드에서 인증 레지스트리의 이미지를 사용한 컨테이너 스캐닝은 지원되지 않습니다. CI_GITLAB_FIPS_MODE가 "true"로 설정되고, CS_REGISTRY_USER 또는 CS_REGISTRY_PASSWORD가 설정된 경우, 분석기는 오류로 종료되고 스캔을 수행하지 않습니다.

자동 Merge Request을 통해 컨테이너 스캔 활성화

• 소개됨 GitLab 14.9에서.

프로젝트에서 컨테이너 스캔을 활성화하려면 보안 구성 페이지에서 Merge Request을 만드세요:

1. 컨테이너 스캔을 활성화하려는 프로젝트로 이동하여 보안 > 보안 구성으로 이동하세요.
2. 컨테이너 스캔 행에서 Merge Request으로 구성을 선택하세요.

이렇게 하면 컨테이너 스캔을 활성화하기 위해 필요한 변경 사항이 포함 된 Merge Request이 자동으로 생성됩니다. 구성을 완료하려면이 Merge Request을 검토하고 Merge하세요.

구성 도구는 .gitlab-ci.yml 파일이 없거나 최소한의 구성 파일이 있는 경우에 가장 잘 작동합니다. 복잡한 GitLab 구성 파일이 있는 경우 성공적으로 구문 분석되지 않을 수도 있고 오류가 발생할 수도 있습니다.

컨테이너 스캐닝 템플릿 재정의

작업 정의를 재정의하려면(예: variables와 같은 속성 변경) 템플릿 포함 후 작업을 선언하고 추가 키를 지정해야 합니다.

이 예제에서는 GIT_STRATEGY를 fetch로 설정합니다:

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    GIT_STRATEGY: fetch

스캐너 변경

CS_ANALYZER_IMAGE 구성 변수의 값에 따라 컨테이너 스캐닝 분석기는 다른 스캐너를 사용할 수 있습니다.

다음 옵션이 가능합니다:

기본 브랜치 이미지 설정

• 소개됨 GitLab 14.5에서.

기본적으로 컨테이너 스캐닝은 이미지 명명 규칙이 이미지 이름이 아닌 이미지 태그에 브랜치별 식별자를 저장한다고 가정합니다. 이미지 이름이 기본 브랜치와 기본 브랜치가 아닌 브랜치에서 다를 때 이전에 감지된 취약점이 Merge Request에 새롭게 감지됩니다.

동일한 이미지가 기본 브랜치와 기본이 아닌 브랜치에서 다른 이름을 가질 때, CS_DEFAULT_BRANCH_IMAGE 변수를 사용하여 기본 브랜치에서 이미지의 이름을 지정할 수 있습니다. 그럼 GitLab은 비기본 브랜치에서 스캔을 실행할 때 이미 존재하는 취약점을 올바르게 결정합니다.

예를 들어, 다음과 같다고 가정합시다:

• 비기본 브랜치는 이미지를 네이밍 컨벤션 $CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHA로 발행합니다.
• 기본 브랜치는 이미지를 네이밍 컨벤션 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA로 발행합니다.

이 예시에서 취약점이 중복 생성되지 않도록 하려면 다음과 같은 CI/CD 구성을 사용할 수 있습니다:

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_DEFAULT_BRANCH_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  before_script:
    - export CS_IMAGE="$CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHA"
    - |
      if [ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]; then
        export CS_IMAGE="$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
      fi

CS_DEFAULT_BRANCH_IMAGE는 주어진 CS_IMAGE에 대해 항상 동일해야 합니다. 바뀌면 매뉴얼으로 중복되는 취약점 집합을 생성해야 할 수 있습니다.

Auto DevOps를 사용할 때, CS_DEFAULT_BRANCH_IMAGE는 자동으로$CI_REGISTRY_IMAGE/$CI_DEFAULT_BRANCH:$CI_APPLICATION_TAG로 설정됩니다.

사용자 정의 SSL CA 인증서 사용

Docker 이미지를 가져올 때 사용되는 커스텀 SSL CA 인증 기관을 구성하려면 ADDITIONAL_CA_CERT_BUNDLE CI/CD 변수를 사용할 수 있습니다. ADDITIONAL_CA_CERT_BUNDLE 값은 HTTPS를 사용하는 레지스트리에서 Docker 이미지를 가져올 때 피어를 확인하는 데 사용됩니다. 이 값은 X.509 PEM 공개 키 인증서의 텍스트 표현을 포함해야 합니다. 예를 들어, .gitlab-ci.yml 파일에 이 값을 구성하려면 다음을 사용하세요:

container_scanning:
  variables:
    ADDITIONAL_CA_CERT_BUNDLE: |
        -----BEGIN CERTIFICATE-----
        MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
        ...
        jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
        -----END CERTIFICATE-----

ADDITIONAL_CA_CERT_BUNDLE 값은 또한 UI에서 사용자 정의 변수로 구성할 수 있습니다. 이는 file일 수도 있고, 인증서의 경로를 필요로 하는 선택사항입니다. 또는 텍스트 표현을 필요로 하는 변수일 수도 있습니다.

취약점 화이트리스트 지정

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

특정 취약점을 화이트리스트화하려면 다음 단계를 따르세요:

1. .gitlab-ci.yml 파일에서 GIT_STRATEGY: fetch 설정을 따라하여 GIT_STRATEGY: fetch를 설정합니다.
2. vulnerability-allowlist.yml이라는 YAML 파일에서 화이트리스트지정된 취약점을 정의합니다. 이 파일은 vulnerability-allowlist.yml 데이터 형식에 설명된 형식을 사용해야 합니다.
3. vulnerability-allowlist.yml 파일을 프로젝트의 Git 리포지터리 루트 폴더에 추가합니다.

vulnerability-allowlist.yml 데이터 형식

vulnerability-allowlist.yml 파일은 취약점의 CVE ID 디렉터리을 지정하는 YAML 파일입니다. 이 디렉터리은 존재해도 되는 취약점으로 인해 제외해야 하는 취약점을 지정합니다.

만일 vulnerability-allowlist.yml 파일에서 일치하는 항목을 찾는다면, 다음과 같은 일이 발생합니다:

• 분석기가 gl-container-scanning-report.json 파일을 생성할 때 취약점은 포함되지 않습니다.
• 파이프라인의 Security 탭에서 취약점은 표시되지 않습니다. 이것은 보안 탭의 근본이 되는 JSON 파일에 포함되지 않습니다.

예제 vulnerability-allowlist.yml 파일:

generalallowlist:
  CVE-2019-8696:
  CVE-2014-8166: cups
  CVE-2017-18248:
images:
  registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256:
    CVE-2018-4180:
  your.private.registry:5000/centos:
    CVE-2015-1419: libxml2
    CVE-2015-1447:

이 예제는 gl-container-scanning-report.json에서 다음을 제외합니다:

1. CVE ID가 CVE-2019-8696, CVE-2014-8166, _CVE-2017-18248_인 모든 취약점.
2. registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 컨테이너 이미지에서 CVE ID가 _CVE-2018-4180_인 모든 취약점.
3. your.private.registry:5000/centos 컨테이너에서 CVE ID가 CVE-2015-1419, _CVE-2015-1447_인 모든 취약점.

파일 형식

• generalallowlist 블록을 사용하여 전역적으로 CVE ID를 지정할 수 있습니다. 일치하는 CVE ID를 가진 모든 취약점은 검사 보고서에서 제외됩니다.

• images 블록을 사용하여 각 컨테이너 이미지에 대해 독립적으로 CVE ID를 지정할 수 있습니다. 이 블록에서 제공된 이미지는 $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG 또는 CS_IMAGE와 같은 Docker 이미지를 지정하는 환경 변수 중 하나에서 가져온 이미지 이름이어야 합니다. 이 블록에서 제공된 이미지는 이 값과 일치해야하며 태그 값을 포함해서는 안 됩니다. 예를 들어, CS_IMAGE=alpine:3.7를 사용하여 스캔할 이미지를 지정하는 경우 alpine을 images 블록에 사용하지만 alpine:3.7을 사용해서는 안 됩니다.

  컨테이너 이미지는 여러 가지 방법으로 지정할 수 있습니다: - 이미지 이름만 지정합니다(예: centos). - 레지스트리 호스트명이 포함된 전체 이미지 이름(예: your.private.registry:5000/centos). - 레지스트리 호스트명과 sha256 라벨이 포함된 전체 이미지 이름(예: registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256).

참고: CVE ID 뒤의 문자열(cups 및 이전 예제의 libxml2)은 선택 사항의 주석 형식이며 취약점 처리에 영향을 미치지 않습니다. 취약점을 설명하는 주석을 포함할 수 있습니다.

컨테이너 스캐닝 작업 로그 형식

컨테이너 스캐닝 분석기에 의해 생성된 로그를 확인하여 스캔 결과와 vulnerability-allowlist.yml 파일의 정확성을 확인할 수 있습니다.

로그에는 테이블 형식의 발견된 취약점 디렉터리이 포함되어 있습니다. 예를 들면:

+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
|   STATUS   |      CVE SEVERITY       |      PACKAGE NAME      |    PACKAGE VERSION    |                            CVE DESCRIPTION                             |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
|  Approved  |   High CVE-2019-3462    |          apt           |         1.4.8         | Incorrect sanitation of the 302 redirect field in HTTP transport metho |
|            |                         |                        |                       | d of apt versions 1.4.8 and earlier can lead to content injection by a |
|            |                         |                        |                       |  MITM attacker, potentially leading to remote code execution on the ta |
|            |                         |                        |                       |                             rget machine.                              |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Unapproved |  Medium CVE-2020-27350  |          apt           |         1.4.8         | APT had several integer overflows and underflows while parsing .deb pa |
|            |                         |                        |                       | ckages, aka GHSL-2020-168 GHSL-2020-169, in files apt-pkg/contrib/extr |
|            |                         |                        |                       | acttar.cc, apt-pkg/deb/debfile.cc, and apt-pkg/contrib/arfile.cc. This |
|            |                         |                        |                       |  issue affects: apt 1.2.32ubuntu0 versions prior to 1.2.32ubuntu0.2; 1 |
|            |                         |                        |                       | .6.12ubuntu0 versions prior to 1.6.12ubuntu0.2; 2.0.2ubuntu0 versions  |
|            |                         |                        |                       | prior to 2.0.2ubuntu0.2; 2.1.10ubuntu0 versions prior to 2.1.10ubuntu0 |
|            |                         |                        |                       |                                  .1;                                   |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Unapproved |  Medium CVE-2020-3810   |          apt           |         1.4.8         | Missing input validation in the ar/tar implementations of APT before v |
|            |                         |                        |                       | ersion 2.1.2 could result in denial of service when processing special |
|            |                         |                        |                       |                         ly crafted deb files.                          |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+

로그의 취약점은 해당 CVE ID가 vulnerability-allowlist.yml 파일에 추가되었을 때 Approved로 표시됩니다.

오프라인 환경에서 컨테이너 스캐닝 실행

GitLab의 오프라인 컨테이너 스캐닝은 제한된, 제약된 또는 가끔씩만 인터넷을 통해 외부 리소스에 접근할 수 있는 환경의 Self-managed 인스턴스를 위해 일부 조정이 필요합니다. 자세한 내용은 오프라인 환경을 참조하세요.

오프라인 컨테이너 스캐닝 요구 사항

오프라인 환경에서 컨테이너 스캐닝을 사용하려면 다음이 필요합니다:

• docker 또는 kubernetes 실행기를 사용하는 GitLab Runner(요구 사항).
• 컨테이너 스캐닝 이미지의 사본을 포함한 로컬 Docker 컨테이너 레지스트리를 구성해야 합니다. 관련 레지스트리에서 이미지를 찾을 수 있습니다:

GitLab Runner는 기본적으로 항상(pull policy) 이미지를 끌어옵니다, 따라서 러너는 로컬 사본이 있는 경우에도 GitLab 컨테이너 레지스트리에서 Docker 이미지를 끌어오려고 시도합니다. 오프라인 환경에서는 GitLab Runner의 셋팅을 if-not-present로 설정할 수 있으며, 이는 로컬에서 이용 가능한 Docker 이미지를 선호하는 경우입니다. 그러나 CI/CD 파이프라인에서 업데이트된 스캐너를 사용하려는 경우를 고려해 항상으로 pull policy 세팅을 유지하는 것을 권장합니다.

사용자 정의 인증 기관 지원

다음 버전에서 사용자 정의 인증 기관이 지원되었습니다:

로컬 Docker 레지스트리 내에서 GitLab 컨테이너 스캐닝 분석기 이미지 사용 가능하게 만들기

컨테이너 스캐닝을 위해 다음 이미지들을 registry.gitlab.com에서 로컬 Docker 컨테이너 레지스트리로 가져오세요:

registry.gitlab.com/security-products/container-scanning:6
registry.gitlab.com/security-products/container-scanning/grype:6
registry.gitlab.com/security-products/container-scanning/trivy:6

로컬 오프라인 Docker 레지스트리로 도커 이미지를 가져오는 과정은 귀하의 네트워크 보안 정책에 따라 다릅니다. 외부 리소스를 가져오거나 일시적으로 접근할 방법을 찾기 위해 귀하의 IT 직원과 협의하세요. 이러한 스캐너들은 정기적으로 업데이트되며, 경우에 따라 직접 업데이트할 수도 있습니다.

더 많은 정보는 파이프라인을 이용한 이미지 업데이트 방법에 대한 구체적인 단계를 참조하세요.

도커 이미지를 파일로 저장하고 전송하는 세부 정보는 도커 문서인 docker save, docker load, docker export 및 docker import를 확인하세요.

로컬 컨테이너 스캐너 분석기를 사용하는 컨테이너 스캐닝 CI/CD 변수 설정

1. .gitlab-ci.yml 파일에서 컨테이너 스캐닝 템플릿을 오버라이드하여 로컬 Docker 컨테이너 레지스트리에 호스팅된 Docker 이미지를 참조하세요:

   include:
     - template: Jobs/Container-Scanning.gitlab-ci.yml
      
   container_scanning:
     image: $CI_REGISTRY/namespace/container-scanning
   

2. 로컬 Docker 컨테이너 레지스트리가 HTTPS로 안전하게 실행 중이지만 자체 서명된 인증서를 사용하는 경우, 앞서 언급한 .gitlab-ci.yml의 container_scanning 섹션에 CS_DOCKER_INSECURE: "true"를 설정해야 합니다.

파이프라인을 이용한 컨테이너 스캐닝 취약점 데이터베이스 업데이트 자동화

예약된 파이프라인을 설정하여 미리 정해진 일정에 최신 취약점 데이터베이스를 가져오도록 권장합니다. 파이프라인을 이용하여 이를 자동화하면 매번 매뉴얼으로 하는 수고를 덜 수 있습니다. 다음의 .gitlab-ci.yml 예제를 참고하세요.

variables:
  SOURCE_IMAGE: registry.gitlab.com/security-products/container-scanning:6
  TARGET_IMAGE: $CI_REGISTRY/namespace/container-scanning

image: docker:latest

update-scanner-image:
  services:
    - docker:dind
  script:
    - docker pull $SOURCE_IMAGE
    - docker tag $SOURCE_IMAGE $TARGET_IMAGE
    - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY --username $CI_REGISTRY_USER --password-stdin
    - docker push $TARGET_IMAGE

위의 템플릿은 로컬 설치형 GitLab Docker 레지스트리에서 작동합니다. 그러나 GitLab이 아닌 Docker 레지스트리를 사용하는 경우, 자신의 로컬 레지스트리의 세부 정보에 따라 $CI_REGISTRY 값을 변경하고 docker login 자격 증명도 조정해야 합니다.

외부 개인 레지스트리에서 이미지 스캔

외부 개인 레지스트리의 이미지를 스캔하려면, 컨테이너 스캐닝 분석기가 이미지에 액세스하기 전에 인증해야 하는 접근 자격 증명을 구성해야 합니다.

GitLab 컨테이너 레지스트리를 사용하는 경우, CS_REGISTRY_USER 및 CS_REGISTRY_PASSWORD 구성 변수가 자동으로 설정되며 이 구성을 건너뛸 수 있습니다.

아래 예는 Google Container Registry에서 이미지 스캔을 위해 필요한 구성을 보여줍니다:

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_REGISTRY_USER: _json_key
    CS_REGISTRY_PASSWORD: "$GCP_CREDENTIALS"
    CS_IMAGE: "gcr.io/path-to-you-registry/image:tag"

이 구성을 커밋하기 전에, GCP_CREDENTIALS를 포함하는 CI/CD 변수를 추가해야 합니다. 이 변수는 Google Cloud Platform Container Registry 문서에서 설명한 JSON 키를 포함해야 합니다.

또한:

• 변수 값이 Mask variable 옵션의 마스킹 요구 사항에 맞지 않을 수 있으므로 값이 작업 로그에 노출될 수 있습니다.
• Protect variable 옵션을 선택하면 비보호 기능 브랜치에서 스캔이 실행되지 않을 수 있습니다.
• 옵션이 선택되지 않았다면 쓰기 전용 권한으로 자격 증명을 생성하고 정기적으로 회전시키는 것을 고려하세요.

FIPS mode가 활성화된 경우 FIPS mode에서는 외부 개인 레지스트리의 이미지 스캔이 지원되지 않습니다.

Trivy Java 데이터베이스 미러 생성 및 사용하기

trivy 스캐너를 사용하고 컨테이너 이미지를 스캔하는 도중에 jar 파일을 만나면 trivy는 추가적인 trivy-java-db 취약점 데이터베이스를 다운로드합니다. 기본적으로 trivy-java-db 데이터베이스는 OCI artifact인 ghcr.io/aquasecurity/trivy-java-db:1에 호스팅됩니다. 예를 들어, 해당 레지스트리에 접근할 수 없는 경우, 예를 들어 네트워크 격리된 오프라인 GitLab 인스턴스인 경우, trivy-java-db를 오프라인 인스턴스에서 접근할 수 있는 컨테이너 레지스트리로 미러링하는 것이 한 가지 해결책입니다.

trivy java db 미러:
  image:
    name: ghcr.io/oras-project/oras:v1.1.0
    entrypoint: [""]
  script:
    - oras login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - oras pull ghcr.io/aquasecurity/trivy-java-db:1
    - oras push $CI_REGISTRY_IMAGE:1 --config /dev/null:application/vnd.aquasec.trivy.config.v1+json javadb.tar.gz:application/vnd.aquasec.trivy.javadb.layer.v1.tar+gzip

이 취약점 데이터베이스는 일반적인 도커 이미지가 아니므로 docker pull을 사용하여 가져올 수 없습니다. GitLab UI에서 해당 이미지로 이동하면 이미지가 표시되지 않습니다.

만약 위의 컨테이너 레지스트리가 gitlab.example.com/trivy-java-db-mirror라면, 아래와 같이 컨테이너 스캔 작업을 구성해야 합니다. 끝에 :1 태그를 추가하지 말고, 이것은 trivy가 추가합니다:

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_TRIVY_JAVA_DB: gitlab.example.com/trivy-java-db-mirror

스탠드얼론 컨테이너 스캐닝 도구 실행

CI 작업의 컨텍스트 내에서 실행할 필요 없이 Docker 컨테이너에 대해 GitLab 컨테이너 스캐닝 도구를 실행할 수 있습니다. 이미지를 직접 스캔하려면 다음 단계를 따르세요:

1. Docker Desktop 또는 Docker Machine를 실행합니다.

2. 분석기의 Docker 이미지를 실행하면서 CI_APPLICATION_REPOSITORY 및 CI_APPLICATION_TAG 변수에 분석할 이미지 및 태그를 전달합니다:

   docker run \
     --interactive --rm \
     --volume "$PWD":/tmp/app \
     -e CI_PROJECT_DIR=/tmp/app \
     -e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
     -e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
     registry.gitlab.com/security-products/container-scanning
   

결과는 gl-container-scanning-report.json에 저장됩니다.

리포트 JSON 형식

컨테이너 스캐닝 도구는 CI 구성 파일의 artifacts:reports 키워드를 통해 GitLab Runner에서 인식하는 JSON 리포트를 생성합니다.

CI 작업이 완료되면 Runner가 이러한 리포트를 GitLab에 업로드하고, 이후에 CI 작업 아티팩트로 이를 이용할 수 있습니다. GitLab Ultimate에서는 이러한 리포트를 해당 파이프라인과 취약점 리포트에서 볼 수 있습니다.

이러한 리포트는 보안 리포트 스키마에서 정의된 형식을 따라야 합니다. 아래 링크를 참조하세요:

• 컨테이너 스캐닝 리포트의 최신 스키마.
• 컨테이너 스캐닝 리포트 예제

더 많은 정보는 보안 스캐너 통합을 참조하세요.

CycloneDX 소프트웨어 컴포넌트 디렉터리

• GitLab 15.11에서 도입.

JSON 리포트 파일 외에도, 컨테이너 스캐닝 도구는 스캔된 이미지의 CycloneDX 소프트웨어 컴포넌트 디렉터리(SBOM)을 출력합니다. 이 CycloneDX SBOM은 gl-sbom-report.cdx.json로 명명되며 JSON 리포트 파일과 동일한 디렉터리에 저장됩니다. 이 기능은 Trivy 분석기를 사용할 때만 지원됩니다.

이 SBOM은 다른 작업 아티팩트 다운로드와 마찬가지로 다운로드할 수 있습니다.

보안 대시보드

보안 대시보드는 그룹, 프로젝트 및 파이프라인의 모든 보안 취약점을 개요로 보여줍니다.

취약점 데이터베이스

모든 분석기 이미지는 매일 업데이트됩니다.

사용되는 upstream 공지 데이터베이스에 따라 데이터 소스는 다음과 같습니다:

이러한 스캐너에서 제공되는 데이터 소스 외에도, GitLab은 다음과 같은 취약점 데이터베이스를 유지합니다:

• 프로프리어터리 GitLab 고려 데이터베이스.
• 오픈 소스 GitLab 고려 데이터베이스 (오픈 소스 에디션).

GitLab Ultimate 티어에서는 외부 소스로부터의 데이터에 추가하여 GitLab 고려 데이터베이스의 데이터가 Merge됩니다. GitLab Premium 및 Free 티어에서는 외부 소스의 데이터에 GitLab 고려 데이터베이스 (오픈 소스 에디션)의 데이터가 Merge됩니다. 현재 이 Merge은 Trivy 스캐너를 사용하는 분석기 이미지에만 적용됩니다.

다른 분석기의 데이터베이스 업데이트 정보는 유지보수 테이블에서 확인할 수 있습니다.

취약점과 상호 작용하기

취약점을 발견한 후에는 해당 문제에 대처할 수 있습니다.

취약점에 대한 해결책 (자동 복구)

일부 취약점은 GitLab이 자동으로 생성한 해결책을 적용하여 해결할 수 있습니다.

복구 지원을 활성화하려면, 스캔 도구는 CS_DOCKERFILE_PATH CI/CD 변수에서 지정한 Dockerfile에 액세스해야 합니다. 스캔 도구가 이 파일에 액세스할 수 있도록 하려면, 이 문서의 컨테이너 스캔 템플릿 무시 섹션에 설명된 지침을 따라 .gitlab-ci.yml 파일에서 GIT_STRATEGY: fetch를 설정해야 합니다.

취약점에 대한 해결책에 대해 더 알아보기.

문제 해결

docker: Error response from daemon: failed to copy xattrs

러너(runner)가 docker 실행자를 사용하고 NFS가 사용되는 경우 (예: /var/lib/docker가 NFS 마운트에 있는 경우), 컨테이너 스캔이 다음과 같은 오류로 실패할 수 있습니다.

docker: Error response from daemon: failed to copy xattrs: failed to set xattr "security.selinux" on /path/to/file: operation not supported.

이는 Docker의 버그로 인한 결과로, 이 버그는 이제 수정되었습니다. 오류를 방지하려면, 러너가 사용하는 Docker 버전이 18.09.03 이상인지 확인하십시오. 자세한 정보는 이슈 #10241를 참조하십시오.

“gl-container-scanning-report.json: no matching files” 경고 메시지 받기

이에 대한 정보는 일반적인 응용 프로그램 보안 문제 해결 섹션을 참조하십시오.

AWS ECR에서 이미지를 스캔할 때 unexpected status code 401 Unauthorized: Not Authorized 메시지 받기

이는 AWS 지역이 구성되지 않았고 스캐너가 인가 토큰을 검색할 수 없을 때 발생할 수 있습니다. SECURE_LOG_LEVEL을 debug로 설정하면 다음과 같은 로그 메시지가 표시됩니다.

[35mDEBUG[0m failed to get authorization token: MissingRegion: could not find region configuration

이를 해결하려면, CI/CD 변수에 AWS_DEFAULT_REGION을 추가하십시오.

variables:
  AWS_DEFAULT_REGION: <AWS_REGION_FOR_ECR>

변경 사항

컨테이너 스캔 분석기의 변경 사항은 프로젝트의 변경 로그에서 찾을 수 있습니다.