• 기능
• 전제 조건
• 구성
  • 컨테이너 스캐닝 설정 사용자화
    • 원격 레지스트리에 있는 이미지 스캔
      • 원격 레지스트리에 인증
    • 언어별 결과 보고
    • Merge Request 파이프라인에서 작업 실행
    • 사용 가능한 CI/CD 변수
  • 지원되는 배포판
    • FIPS 활성화된 이미지
  • 자동 Merge Request을 통한 컨테이너 스캔 활성화
  • 컨테이너 스캔 템플릿 재정의
  • 기본 브랜치 이미지 설정
  • 사용자 정의 SSL CA 인증서 사용
  • 취약점 허용 디렉터리
    • vulnerability-allowlist.yml 데이터 형식
      • 파일 형식
      • 컨테이너 스캔 작업 로그 형식
  • 오프라인 환경에서 컨테이너 스캔 실행
    • 오프라인 컨테이너 스캔 요구 사항
      • 사용자 정의 인증 기관 지원
    • GitLab 컨테이너 스캔 분석기 이미지를 Docker 레지스트리 내에 사용 가능하게 만들기
    • 로컬 컨테이너 스캐닝 CI/CD 변수 설정하여 로컬 컨테이너 스캐너 분석기 사용
    • 파이프라인을 사용하여 컨테이너 스캐닝 취약점 데이터베이스 업데이트 자동화
    • 외부 사설 레지스트리의 이미지 스캔
  • 중략
  • 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를 받는 경우
  • unable to open a file: open /home/gitlab/.cache/trivy/ee/db/metadata.json: no such file or directory
• 변경 사항

컨테이너 스캐닝

• 변경됨 GitLab 15.0에서 주요 분석기 버전을 4에서 5로 변경했습니다.
• 이전 - GitLab Ultimate를 GitLab Free로 변경했습니다. 15.0에서.
• GitLab 15.4에서 도커를 참조하는 컨테이너 스캐닝 변수를 이름을 바꿨습니다.
• GitLab 15.6에서 컨테이너 스캐닝 템플릿을 Security/Container-Scanning.gitlab-ci.yml 에서 Jobs/Container-Scanning.gitlab-ci.yml로 이동했습니다.

귀하의 애플리케이션의 Docker 이미지는 자체적으로 알려진 취약점을 포함한 Docker 이미지를 기반으로 할 수 있습니다. 이러한 취약점을 스캔하고 Merge Request에서 표시하여 GitLab을 사용하여 Docker 기반 앱을 감사할 수 있습니다.

• 개요는 컨테이너 스캐닝을 참조하세요.
• 비디오 안내는 GitLab을 사용하여 컨테이너 스캐닝 설정하는 방법을 참조하세요.
• 초보용 튜토리얼은 취약점을 위한 Docker 컨테이너 스캔을 참조하세요.

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

GitLab은 모든 이러한 의존성 유형에 대한 커버리지를 보장하기 위해 컨테이너 스캐닝과 의존성 스캐닝을 제공합니다. 가능한 한 많은 리스크 영역을 커버하기 위해 모든 보안 스캐너를 사용하도록 권장합니다. 이러한 기능을 비교하려면 의존성 스캐닝과 컨테이너 스캐닝 비교를 참조하세요.

GitLab은 보안 스캐너로 Trivy 보안 스캐너를 통합하여 컨테이너에서 취약점 정적 분석을 수행합니다.

외부 디렉터리에 표시된 것 외의 보안 스캐너를 GitLab과 통합하려면 보안 스캐너 통합을 참조하세요.

다음 중 하나를 수행하여 컨테이너 스캐닝을 활성화할 수 있습니다. - 기존의 .gitlab-ci.yml 파일에 CI 작업을 포함합니다. - 자동 DevOps에서 제공되는 자동 컨테이너 스캐닝을 암시적으로 사용합니다.

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

기능

전제 조건

파이프라인에 컨테이너 스캐닝을 활성화하려면 다음이 필요합니다. - test 단계를 포함하는 GitLab CI/CD 파이프라인은 stages 키워드로 재정의되지 않은 한 사용 가능합니다. - Linux/amd64의 docker 또는 kubernetes executor를 사용하는 GitLab Runner. - 러너와 동일한 컴퓨터에 설치된 Docker 18.09.03 또는 그 이상 버전입니다. GitLab.com의 인스턴스 러너를 사용하는 경우 이미 해당 사항입니다. - 지원되는 배포판에 맞는 이미지. - 프로젝트의 컨테이너 레지스트리에 Docker 이미지를 빌드하고 푸시합니다. - 외부 컨테이너 레지스트리를 사용하는 경우 CS_REGISTRY_USER 및 CS_REGISTRY_PASSWORD 구성 변수를 통해 인증 자격 증명을 제공해야 할 수 있습니다. 이러한 변수를 사용하는 방법에 대한 자세한 내용은 원격 레지스트리에 인증를 참조하세요.

구성

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

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

포함된 템플릿:

• CI/CD 파이프라인에서 container_scanning 작업을 생성합니다.
• 프로젝트의 컨테이너 레지스트리에서 빌드된 Docker 이미지를 가져와 가능한 취약점을 스캔합니다. (자세한 내용은 필수 조건을 참조하세요).

GitLab은 나중에 다운로드하고 분석할 수 있는 컨테이너 스캐닝 보고서 아티팩트를 저장합니다. 다운로드 시 항상 가장 최신 아티팩트를 받을 수 있습니다. 또한, CycloneDX SBOM JSON 보고서가 컴포넌트 디렉터리을 보고하기 위해 생성됩니다.

다음은 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의 variables 매개변수를 사용하여 CI/CD 변수를 설정하십시오. .gitlab-ci.yml에서 설정하는 변수는 Container-Scanning.gitlab-ci.yml의 변수를 덮어씁니다.

다음 예제는 컨테이너 스캐닝 템플릿을 포함하고 분석기에 대한 자세한 출력을 활성화하는 것입니다:

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가 활성화되어 있는 경우 지원되지 않습니다.

언어별 결과 보고

CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN CI/CD 변수는 스캔에서 프로그래밍 언어와 관련된 결과를 보고할지를 제어합니다. 지원되는 언어에 대한 자세한 내용은 Trivy 문서의 언어별 패키지를 참조하세요.

기본적으로 보고는 운영 체제(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"

이 기능을 활성화하면 프로젝트에 Dependency Scanning이 활성화된 경우 Vulnerability Report에서 중복 발견을 볼 수 있습니다. 이는 GitLab이 서로 다른 유형의 스캔 도구 간에 중복 결과를 자동으로 처리할 수 없기 때문에 발생합니다. 중복될 가능성이 있는 의존성의 유형에 대해 자세히 알아보려면 Dependency Scanning과 Container Scanning 비교를 참조하세요.

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

Merge Request 파이프라인에서 보안 스캔 도구를 사용하는 방법에 대해서는 Merge Request 파이프라인에서 보안 스캔 도구 사용을 참조하세요.

사용 가능한 CI/CD 변수

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

1. 수정 상태 정보는 소프트웨어 공급 업체 및 컨테이너 이미지 운영 체제 패키지 메타데이터의 정확한 수정 가능성 데이터에 매우 의존적이며 개별 컨테이너 스캐너의 해석에 따라 다릅니다. 컨테이너 스캐너가 취약점에 대한 수정된 패키지의 가용성을 잘못 보고하는 경우 `CS_IGNORE_STATUSES`를 사용하면 이 설정이 활성화될 때 결과를 잘못된 양성 또는 거짓 음성으로 필터링할 수 있습니다.

지원되는 배포판

다음은 지원되는 Linux 배포판입니다:

• Alma Linux
• Alpine Linux
• Amazon Linux
• CentOS
• CBL-Mariner
• Debian
• Distroless
• Oracle Linux
• Photon OS
• Red Hat (RHEL)
• Rocky Linux
• SUSE
• Ubuntu

FIPS 활성화된 이미지

GitLab은 또한 컨테이너 스캔 이미지의 FIPS 활성화 Red Hat UBI 버전을 제공합니다. 따라서 표준 이미지를 FIPS 활성화된 이미지로 대체할 수 있습니다. 이미지를 구성하려면 CS_IMAGE_SUFFIX를 -fips로 설정하거나 CS_ANALYZER_IMAGE 변수를 표준 태그에 -fips 확장자를 추가하여 수정합니다.

FIPS 모드가 활성화된 경우에는 인증된 레지스트리의 이미지를 컨테이너 스캔할 수 없습니다. CI_GITLAB_FIPS_MODE가 "true"로 설정되고 CS_REGISTRY_USER 또는 CS_REGISTRY_PASSWORD가 설정되어 있는 경우, 분석기는 오류로 종료되고 스캔을 수행하지 않습니다.

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

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

1. 컨테이너 스캔을 활성화하려는 프로젝트에서 Secure > Security configuration로 이동합니다.
2. Container Scanning 행에서 Configure with a 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

기본 브랜치 이미지 설정

기본적으로 컨테이너 스캔은 이미지 이름 규칙이 이미지 이름이 아닌 브랜치별 식별자를 이미지 태그에 저장한다고 가정합니다. 이미지 이름이 기본 브랜치와 기본 브랜치가 아닌 브랜치에서 다르면 이전에 감지된 취약점이 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 인증서 사용

ADDITIONAL_CA_CERT_BUNDLE CI/CD 변수를 사용하여 HTTPS를 사용하는 레지스트리에서 Docker 이미지를 가져올 때 피어를 확인하는 데 사용되는 사용자 정의 SSL CA 인증서를 구성할 수 있습니다. ADDITIONAL_CA_CERT_BUNDLE 값은 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로 구성하면 인증서의 경로가 필요하고, 변수로 구성하면 인증서의 텍스트 표현이 필요합니다.

취약점 허용 디렉터리

특정 취약점을 허용디렉터리에 추가하려면 다음 단계를 따르세요:

1. 컨테이너 스캔 템플릿 재정의 지침에 따라 .gitlab-ci.yml 파일에 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 파일을 생성할 때 취약점이 포함되지 않습니다.
• 파이프라인의 보안 탭에는 해당 취약점이 표시되지 않습니다. 보안 탭의 기존 정보 기준인 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를 지정할 수 있습니다. 일치하는 CVE ID가 있는 주어진 이미지의 모든 취약점은 스캔 보고서에서 제외됩니다. 이미지 이름은 Docker 이미지를 지정하는 데 사용되는 환경 변수 중 하나에서 검색됩니다. 예를 들어, $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG 또는 CS_IMAGE과 같은 값입니다. 이 블록에서 제공된 이미지는 이 값을 일치시켜야 하며 태그 값을 포함해서는 절대로 안 됩니다. 예를 들어, CS_IMAGE=alpine:3.7를 사용하여 스캔할 이미지를 지정하면 images 블록에서 alpine을 사용하지만 alpine:3.7을 사용해서는 결코 안 됩니다.

  여러 가지 방법으로 컨테이너 이미지를 지정할 수 있습니다:

  • 이미지 이름만으로(예: centos).
  • 레지스트리 호스트명이 포함된 전체 이미지 이름(예: your.private.registry:5000/centos).
  • 레지스트리 호스트명과 sha256 라벨이 포함된 전체 이미지 이름(예: registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256).

컨테이너 스캔 작업 로그 형식

컨테이너 스캔 분석기가 생성한 로그를 확인하여 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로 표시됩니다.

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

인터넷을 통한 외부 리소스에 대한 제한적이거나 intermittent한 접근 권한이 있는 환경에서 Self-Managed GitLab 인스턴스의 경우, 컨테이너 스캔 작업이 성공적으로 실행되려면 일부 조정이 필요합니다. 자세한 내용은 오프라인 배포를 참조하세요.

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

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

• docker 또는 kubernetes executor가 있는 GitLab Runner.
• 컨테이너 스캔 이미지의 로컬 Docker 컨테이너 레지스트리를 구성해야 합니다. 해당 이미지는 각각의 레지스트리에서 찾을 수 있습니다:

GitLab Runner는 기본적으로 always pull 정책을 갖고 있어서, 로컬 복사본이 있는 경우에도 GitLab 컨테이너 레지스트리에서 Docker 이미지를 가져오려고 합니다. 오프라인 환경에서는 GitLab Runner의 pull_policy를 if-not-present로 설정할 수 있습니다. 이는 로컬에서만 사용 가능한 Docker 이미지를 사용하는 경우에 해당합니다. 그러나 CI/CD 파이프라인에서 업데이트된 스캐너를 사용하려면 오프라인 환경이 아닌 경우에는 항상 pull 정책 설정을 유지하는 것을 권장합니다.

사용자 정의 인증 기관 지원

Trivy의 사용자 정의 인증 기관 지원은 4.0.0 버전에서 도입되었습니다.

GitLab 컨테이너 스캔 분석기 이미지를 Docker 레지스트리 내에 사용 가능하게 만들기

컨테이너 스캔을 위해 registry.gitlab.com에서 다음 이미지를 로컬 Docker 컨테이너 레지스트리로 가져와야 합니다:

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

Docker 이미지를 로컬 오프라인 Docker 레지스트리로 가져오는 프로세스는 네트워크 보안 정책에 따라 다릅니다. 외부 리소스를 가져오거나 일시적으로 액세스할 수 있는 승인된 과정을 IT 스태프에 상의하십시오. 이러한 스캐너는 주기적으로 업데이트되며 가끔은 사용자가 직접 업데이트할 수 있을 수 있습니다.

이미지를 레지스트리로 업데이트하는 방법에 대한 구체적인 단계에 대해서는 파이프라인을 사용한 컨테이너 스캔 취약점 데이터베이스 업데이트 자동화를 참조하세요.

Docker 이미지를 파일로 저장하고 전송하는 방법에 대한 자세한 내용은 Docker 문서에서 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:7
  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 컨테이너 레지스트리에서 이미지를 스캔하기 위해 필요한 구성을 보여주는 예제입니다:

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 변수를 추가하여, 해당 변수의 값이 작업 로그에 노출될 수 있다는 점에 유의해야 합니다.

중략

(::: the remaining content is not translated :::)

CycloneDX 소프트웨어 부자재 디렉터리

• GitLab 15.11에서 소개됨.

JSON 보고서 파일 외에도 Container Scanning 도구는 스캔된 이미지에 대한 CycloneDX 소프트웨어 부자재(SBOM)를 출력합니다. 이 CycloneDX SBOM은 gl-sbom-report.cdx.json이라고 하며 JSON 보고서 파일과 동일한 디렉터리에 저장됩니다. 이 기능은 Trivy 분석 도구를 사용할 때만 지원됩니다.

이 보고서는 의존성 디렉터리에서 볼 수 있습니다.

CycloneDX SBOM은 다른 작업 artifacts와 동일한 방식으로 다운로드할 수 있습니다.

보안 대시보드

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

취약점 데이터베이스

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

이미지는 상위 통보 데이터베이스에서 데이터를 사용합니다:

• AlmaLinux 보안 통보
• Amazon Linux 보안 센터
• Arch Linux 보안 추적기
• SUSE CVRF
• CWE 통보
• Debian 보안 버그 추적기
• GitHub 보안 통보
• Go 취약점 데이터베이스
• CBL-Mariner 취약점 데이터
• NVD
• OSV
• Red Hat OVAL v2
• Red Hat 보안 데이터 API
• Photon 보안 통보
• Rocky Linux UpdateInfo
• Ubuntu CVE 추적기 (2021년 중반 이후의 데이터 소스만)

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

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

GitLab Ultimate 티어에서는 외부 소스의 데이터를 보강하기 위해 GitLab 공고 데이터베이스의 데이터를 Merge합니다. GitLab Premium 및 무료 티어에서는 외부 소스의 데이터를 보강하기 위해 GitLab 공고 데이터베이스(오픈 소스 에디션)의 데이터를 Merge합니다. 현재 이러한 보강은 Trivy 스캐너 이미지에만 적용됩니다.

다른 분석 도구의 데이터베이스 업데이트 정보는 유지 관리 표에서 확인할 수 있습니다.

취약점 해결

취약점이 발견되면 해결할 수 있습니다.

취약점 해결 방법(자동 복구)

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

변별된 Dockerfile에 액세스할 수 있는 스캐닝 도구 반드시 접근해야 합니다. 이를 위해 .gitlab-ci.yml 파일에 CS_DOCKERFILE_PATH CI/CD 변수를 설정해야 합니다. 스캐닝 도구가 이 파일에 액세스할 수 있도록 하려면 본 문서의 컨테이너 스캐닝 템플릿 재정의 섹션에 설명된 지침을 따라야 합니다.

취약점에 대한 자세한 내용은 취약점 해결 방법을 참조하십시오.

문제 해결

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 이상인지 확인하십시오. 자세한 내용은 issue #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>

unable to open a file: open /home/gitlab/.cache/trivy/ee/db/metadata.json: no such file or directory

압축된 Trivy 데이터베이스는 컨테이너의 /tmp 폴더에 저장되며 실행시에 /home/gitlab/.cache/trivy/{ee|ce}/db로 추출됩니다. 이 오류는 러너 구성에서 /tmp 디렉터리에 볼륨 마운트가 있는 경우 발생할 수 있습니다.

이를 해결하려면 /tmp 폴더에 대한 바인딩 대신 /tmp 내의 지정된 파일 또는 폴더를 바인딩하십시오.

변경 사항

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