• 기능
• 구성
  • 분석기 활성화
    • 미리 구성된 병합 요청 사용하기
    • .gitlab-ci.yml 파일을 수동으로 편집하기
  • 분석기 동작 맞춤 설정
    • 상세 출력 켜기
    • 원격 레지스트리에서 이미지 스캔하기
      • 원격 레지스트리에 인증하기
    • 언어별 발견 사항 보고
    • 병합 요청 파이프라인에서 작업 실행
    • 사용 가능한 CI/CD 변수
  • 지원되는 배포판
    • FIPS 지원 이미지
  • 컨테이너 스캐닝 템플릿 재정의
  • 기본 브랜치 이미지 설정
  • 사용자 정의 SSL CA 인증 기관 사용
  • 취약점 허용 목록
    • vulnerability-allowlist.yml 데이터 형식
      • 파일 형식
      • 컨테이너 스캐닝 작업 로그 형식
  • 오프라인 환경에서 컨테이너 스캐닝 실행
    • 오프라인 컨테이너 스캐닝을 위한 요구 사항
      • 사용자 인증 기관에 대한 지원
    • GitLab 컨테이너 스캐닝 분석기 이미지를 Docker 레지스트리 내에서 사용 가능하게 설정
    • 로컬 컨테이너 스캐너 분석기를 사용하기 위해 컨테이너 스캐닝 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
  • unable to open a file: open /home/gitlab/.cache/trivy/ee/db/metadata.json: no such file or directory
  • context deadline exceeded 오류 해결
• 변경 사항

컨테이너 스캐닝

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

귀하의 애플리케이션의 Docker 이미지는 알려진 취약점이 포함된 Docker 이미지에 기반할 수 있습니다. 해당 취약점을 스캔하고 병합 요청에 표시하는 추가 컨테이너 스캐닝 작업을 파이프라인에 포함함으로써, GitLab을 사용하여 Docker 기반 애플리케이션을 감사할 수 있습니다.

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

컨테이너 스캐닝은 종종 소프트웨어 구성 분석(SCA)의 일부로 간주됩니다. SCA는 코드에서 사용하는 항목을 검사하는 측면을 포함할 수 있습니다. 이 항목은 일반적으로 외부 소스에서 가져오는 애플리케이션 및 시스템 종속성으로, 사용자가 직접 작성한 항목에서 출처를 찾는 경우는 거의 없습니다.

GitLab은 모든 이러한 종속성 유형을 보장하기 위해 컨테이너 스캐닝 및 종속성 스캐닝을 제공합니다. 위험 영역을 최대한 덮기 위해 모든 보안 스캐너를 사용하는 것을 권장합니다. 이러한 기능의 비교는 종속성 스캐닝과 컨테이너 스캐닝 비교를 참조하십시오.

GitLab은 컨테이너에서 취약점 정적 분석을 수행하기 위해 Trivy 보안 스캐너와 통합됩니다.

경고:
Grype 분석기는 제한된 수정만을 제외하고는 더 이상 유지 관리되지 않습니다. 이는 우리의 지원 성명서에서 설명되어 있습니다. Grype 분석기 이미지의 현재 주요 버전은 GitLab 19.0까지 최신 권고 데이터베이스 및 운영 체제 패키지로 업데이트됩니다. 그 시점이 지나면 분석기가 작동을 중지합니다.

GitLab은 소스 및 대상 브랜치 간에 발견된 취약점을 비교한 후:

• 병합 요청 위젯에 결과를 표시합니다.
• 나중에 다운로드하고 분석할 수 있는 컨테이너 스캐닝 보고서 아티팩트로 결과를 저장합니다. 다운로드할 때, 항상 최신 아티팩트를 받습니다.
• 감지된 구성 요소를 나열하는 CycloneDX SBOM JSON 보고서를 저장합니다.

기능

구성

CI/CD 파이프라인에서 컨테이너 스캔 분석기를 활성화합니다. 파이프라인이 실행될 때, 애플리케이션이 의존하는 이미지가 취약점에 대해 스캔됩니다. CI/CD 변수를 사용하여 컨테이너 스캔을 사용자 정의할 수 있습니다.

분석기 활성화

필수 조건:

• .gitlab-ci.yml 파일에 테스트 단계가 필요합니다.
• 자체 관리형 러너에서는 Linux/amd64에서 docker 또는 kubernetes 실행기가 있는 GitLab 러너가 필요합니다. GitLab.com의 인스턴스 러너를 사용하는 경우 기본적으로 활성화되어 있습니다.
• 지원되는 배포판에 맞는 이미지.
• 빌드 및 푸시하여 프로젝트의 컨테이너 레지스트리에 Docker 이미지를 푸시합니다.
• 타사 컨테이너 레지스트리를 사용하는 경우, CS_REGISTRY_USER 및 CS_REGISTRY_PASSWORD 구성 변수를 통해 인증 자격 증명을 제공해야 할 수 있습니다. 이러한 변수를 사용하는 방법에 대한 자세한 내용은 원격 레지스트리에 인증을 참조하세요.

분석기를 활성화하려면 다음 중 하나를 수행합니다:

• 종속성 스캔을 포함하는 Auto DevOps를 활성화합니다.
• 미리 구성된 머지 요청을 사용합니다.
• 컨테이너 스캔을 강제하는 스캔 실행 정책을 생성합니다.
• .gitlab-ci.yml 파일을 수동으로 편집합니다.

미리 구성된 병합 요청 사용하기

이 방법은 .gitlab-ci.yml 파일에 컨테이너 스캐닝 템플릿을 포함하는 병합 요청을 자동으로 준비합니다.

그런 다음 병합 요청을 병합하여 의존성 스캐닝을 활성화합니다.

복잡한 GitLab 구성 파일이 있는 경우 성공적으로 파싱되지 않을 수 있으며, 오류가 발생할 수 있습니다.

그럴 경우 수동 방법을 대신 사용하세요.

컨테이너 스캐닝을 활성화하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 보안 > 보안 구성을 선택합니다.
3. 컨테이너 스캐닝 행에서 병합 요청으로 구성을 선택합니다.
4. 병합 요청 만들기를 선택합니다.
5. 병합 요청을 검토한 후 병합을 선택합니다.

이제 파이프라인에 컨테이너 스캐닝 작업이 포함됩니다.

.gitlab-ci.yml 파일을 수동으로 편집하기

이 방법은 기존의 .gitlab-ci.yml 파일을 수동으로 편집해야 합니다. GitLab CI/CD 구성 파일이 복잡하거나 기본 옵션을 사용해야 하는 경우 이 방법을 사용하세요.

컨테이너 스캐닝을 활성화하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 빌드 > 파이프라인 편집기를 선택합니다.
3. .gitlab-ci.yml 파일이 존재하지 않으면 파이프라인 구성을 선택한 후 예제 내용을 삭제합니다.

4. .gitlab-ci.yml 파일의 하단에 다음을 복사하여 붙여넣습니다. include 행이 이미 존재하는 경우, 그 아래에 오직 template 행만 추가합니다.

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

5. 검증 탭을 선택한 다음 파이프라인 검증을 선택합니다.

   시뮬레이션이 성공적으로 완료되었습니다 메시지가 파일이 유효함을 확인합니다.

6. 편집 탭을 선택합니다.
7. 필드를 작성합니다. 브랜치 필드에 기본 브랜치를 사용하지 마십시오.
8. 이 변경 사항으로 새로운 병합 요청 시작 체크박스를 선택한 다음 변경 사항 커밋을 선택합니다.
9. 표준 워크플로우에 따라 필드를 작성한 후 병합 요청 만들기를 선택합니다.
10. 표준 워크플로우에 따라 병합 요청을 검토 및 편집하고, 파이프라인이 통과할 때까지 기다린 후 병합을 선택합니다.

이제 파이프라인에 컨테이너 스캐닝 작업이 포함됩니다.

분석기 동작 맞춤 설정

컨테이너 스캐닝을 사용자 정의하려면 CI/CD 변수를 사용하세요.

상세 출력 켜기

의존성 스캐닝 작업이 수행하는 내용을 상세히 확인해야 할 경우 상세 출력을 켭니다. 예를 들어, 문제 해결 시에 유용합니다.

다음 예제에서는 컨테이너 스캐닝 템플릿이 포함되고 상세 출력이 활성화됩니다.

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 모드가 활성화되어 있을 때 지원되지 않습니다.

언어별 발견 사항 보고

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"

이 기능을 활성화하면 의존성 스캐닝이 프로젝트에 대해 활성화되어 있으면 취약점 보고서에서 중복 발견 사항을 볼 수 있습니다. 이는 GitLab이 서로 다른 유형의 스캔 도구 간에 발견 사항을 자동으로 중복 제거할 수 없기 때문에 발생합니다. 어떤 유형의 의존성이 중복될 가능성이 있는지 이해하려면 의존성 스캐닝과 컨테이너 스캐닝 비교를 참조하세요.

병합 요청 파이프라인에서 작업 실행

병합 요청 파이프라인에서 보안 스캐닝 도구 사용을 참조하세요.

사용 가능한 CI/CD 변수

컨테이너 스캐닝을 사용자 지정하려면 CI/CD 변수를 사용하세요. 다음 표에는 컨테이너 스캐닝에 특화된 CI/CD 변수가 나열되어 있습니다. 또한 미리 정의된 CI/CD 변수를 사용할 수 있습니다.

경고:

병합 요청에서 GitLab 분석기의 사용자 지정을 테스트한 후 이러한 변경 사항을 기본 브랜치에 병합하세요. 그렇게 하지 않으면 많은 수의 잘못된 긍정 결과를 포함한 예상치 못한 결과가 발생할 수 있습니다.

각주:

1. 수정 상태 정보는 소프트웨어 공급업체 및 컨테이너 이미지 운영 체제 패키지 메타데이터의 정확한 수정 가능성 데이터에 크게 의존합니다. 또한 개별 컨테이너 스캐너의 해석에도 영향을 받습니다. 컨테이너 스캐너가 취약점에 대해 수정된 패키지의 가용성을 잘못 보고하는 경우 CS_IGNORE_STATUSES를 사용하면 이 설정이 활성화될 때 발견 사항의 잘못된 긍정 또는 잘못된 부정 필터링이 발생할 수 있습니다.

지원되는 배포판

다음 리눅스 배포판이 지원됩니다:

• 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 모드가 GitLab 인스턴스에서 활성화되면 -fips 플래그가 자동으로 CS_ANALYZER_IMAGE에 추가됩니다.

FIPS 모드가 활성화된 상태에서는 인증된 레지스트리의 이미지에 대한 컨테이너 스캐닝이 지원되지 않습니다. CI_GITLAB_FIPS_MODE가 "true"이며 CS_REGISTRY_USER 또는 CS_REGISTRY_PASSWORD가 설정되면, 분석기가 오류와 함께 종료되며 스캔을 수행하지 않습니다.

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

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

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

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

container_scanning:
  variables:
    GIT_STRATEGY: fetch

기본 브랜치 이미지 설정

기본적으로 컨테이너 스캐닝은 이미지 명명 규칙이 이미지 이름이 아니라 이미지 태그에 브랜치 특정 식별자를 저장한다고 가정합니다. 기본 브랜치와 비기본 브랜치 간의 이미지 이름이 다를 때, 이전에 감지된 취약점이 병합 요청에서 새롭게 감지된 것으로 나타납니다.

동일한 이미지가 기본 브랜치와 비기본 브랜치에서 서로 다른 이름을 가진 경우, 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 변수를 사용하여 사용자 정의 SSL CA 인증 기관을 구성할 수 있습니다. 이는 HTTPS를 사용하는 레지스트리에서 Docker 이미지를 가져올 때 피어를 확인하는 데 사용됩니다. 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 형태이거나 인증서의 텍스트 표현이 필요한 변수 형태일 수 있습니다.

취약점 허용 목록

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

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

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가 있는 주어진 이미지의 모든 취약점은 스캔 보고서에서 제외됩니다. 이미지 이름은 스캔할 도커 이미지를 지정하기 위해 사용되는 환경 변수 중 하나(예: $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).

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

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

vulnerability-allowlist.yml 파일의 정확성을 확인하고 스캔 결과를 검증하려면 container_scanning 작업 세부정보에 있는 로그를 확인하세요.

로그는 찾은 취약점의 목록을 표 형식으로 포함하고 있으며, 예를 들어 다음과 같습니다:

+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
|   STATUS   |      CVE SEVERITY       |      PACKAGE NAME      |    PACKAGE VERSION    |                            CVE DESCRIPTION                             |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
|  Approved  |   High CVE-2019-3462    |          apt           |         1.4.8         | HTTP 전송 방식에서의 302 리디렉션 필드의 잘못된 sanitization으로 인해 |
|            |                         |                        |                       |  apt 버전 1.4.8 및 이전 버전에서 MITM 공격자가 콘텐츠 주입으로 |
|            |                         |                        |                       | 원격 코드 실행을 유발할 수 있습니다.                                 |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Unapproved |  Medium CVE-2020-27350  |          apt           |         1.4.8         | APT는 .deb 패키지를 파싱하는 동안 여러 정수 오버플로우 및 언더플로우가 발생했습니다.  |
|            |                         |                        |                       | 이 문제는 apt-pkg/contrib/extracttar.cc, apt-pkg/deb/debfile.cc,  |
|            |                         |                        |                       | apt-pkg/contrib/arfile.cc와 관련이 있습니다. 이 문제는 다음에 영향을 미칩니다:  |
|            |                         |                        |                       | apt 1.2.32ubuntu0 버전 이전; 1.6.12ubuntu0 버전 이전; 2.0.2ubuntu0  |
|            |                         |                        |                       | 버전 이전; 2.1.10ubuntu0 버전 이전.                                   |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Unapproved |  Medium CVE-2020-3810   |          apt           |         1.4.8         | APT의 ar/tar 구현에서 입력 검증이 누락되어 특수하게 조작된 deb 파일을 처리할 때  |
|            |                         |                        |                       | 서비스 거부를 초래할 수 있습니다.                                      |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+

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

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

외부 리소스에 대한 제한적이거나 간헐적인 접근이 있는 환경에서 자체 관리되는 GitLab 인스턴스의 경우, 컨테이너 스캐닝 작업이 성공적으로 실행되기 위해 몇 가지 조정이 필요합니다.

추가 정보는 오프라인 환경을 참조하세요.

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

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

• docker 또는 kubernetes 실행기를 가진 GitLab Runner.
• 컨테이너 스캐닝 이미지의 복사본으로 로컬 Docker 컨테이너 레지스트리를 구성해야 합니다. 이 이미지는 해당 레지스트리에서 찾을 수 있습니다:

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

사용자 인증 기관에 대한 지원

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 save, docker load, docker export, docker import에 대한 Docker 문서를 참조하세요.

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

1. .gitlab-ci.yml 파일에서 container_scanning 템플릿을 재정의하여 로컬 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 Container Registry를 사용하는 경우, 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"

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

또한:

• 변수의 값이 Mask variable 옵션의 마스킹 요구 사항에 맞지 않을 수 있으므로, 해당 값이 작업 로그에 노출될 수 있습니다.

• Protect variable 옵션을 선택하면 스캔이 보호되지 않은 기능 브랜치에서 실행되지 않을 수 있습니다.

• 옵션이 선택되지 않은 경우 읽기 전용 권한을 가진 자격 증명을 생성하고 정기적으로 회전하는 것을 고려하세요.

외부 개인 레지스트리에서 이미지를 스캔하는 것은 FIPS 모드가 활성화되어 있을 때 지원되지 않습니다.

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

trivy 스캐너가 사용되고 스캔 중인 컨테이너 이미지에서 jar 파일이 발견되면, trivy는 추가적인 trivy-java-db 취약점 데이터베이스를 다운로드합니다. 기본적으로 trivy-java-db 데이터베이스는 ghcr.io/aquasecurity/trivy-java-db:1에 OCI 아티팩트로 호스팅됩니다. 이 레지스트리에 접근할 수 없거나 TOOMANYREQUESTS로 응답하는 경우, 한 가지 해결책은 trivy-java-db를 보다 접근 가능한 컨테이너 레지스트리로 미러링하는 것입니다:

mirror 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 이미지가 아니므로 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

독립형 컨테이너 스캐닝 도구 실행

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

1. Docker Desktop 또는 Docker Machine을 실행하세요.

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

   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 형식

컨테이너 스캐닝 도구는 JSON 보고서를 출력하며, 이는 CI 구성 파일에서 artifacts:reports 키워드를 통해 GitLab Runner가 인식합니다.

CI 작업이 완료되면, Runner는 이러한 보고서를 GitLab에 업로드하며, CI 작업 아티팩트에서 확인할 수 있습니다. GitLab Ultimate에서는 이 보고서를 해당 파이프라인에서 볼 수 있으며, 취약점 보고서의 일부가 됩니다.

이 보고서는 보안 보고서 스키마에 정의된 형식을 따라야 합니다. 다음을 참조하세요:

• 컨테이너 스캐닝 보고서에 대한 최신 스키마.
• 예제 컨테이너 스캐닝 보고서

자세한 내용은 보안 스캐너 통합을 참조하세요.

CycloneDX 소프트웨어 자재 명세서

• 도입됨 GitLab 15.11에서.

JSON 보고서 파일 외에도, 컨테이너 스캐닝 도구는 스캔된 이미지에 대해 CycloneDX 소프트웨어 자재 명세서(SBOM)를 출력합니다. 이 CycloneDX SBOM의 이름은 gl-sbom-report.cdx.json이며, JSON 보고서 파일과 동일한 디렉토리에 저장됩니다. 이 기능은 Trivy 분석기가 사용될 때만 지원됩니다.

이 보고서는 의존성 목록에서 확인할 수 있습니다.

CycloneDX SBOM은 다른 작업 아티팩트를 다운로드하는 방법으로 다운로드할 수 있습니다.

레지스트리용 컨테이너 스캔

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

• GitLab 17.1에 도입됨 enable_container_scanning_for_registry라는 플래그와 함께. 기본적으로 비활성화되어 있습니다.
• Self-managed 및 GitLab Dedicated에서 활성화됨 GitLab 17.2에서.
• GitLab 17.2에서 일반적으로 사용 가능함. 기능 플래그 enable_container_scanning_for_registry가 제거되었습니다.

latest 태그로 컨테이너 이미지를 푸시하면 기본 브랜치에 대해 새로운 파이프라인에서 자동으로 컨테이너 스캔 작업이 트리거됩니다.

정기적인 컨테이너 스캔과 달리, 스캔 결과에는 보안 보고서가 포함되지 않습니다. 대신, 레지스트리용 컨테이너 스캐닝은 스캔에서 감지된 구성 요소를 검사하기 위해 지속적 취약성 스캐닝을 사용합니다.

보안 발견 사항이 확인되면, GitLab은 이러한 발견 사항으로 취약성 보고서를 작성합니다. 취약성은 취약성 보고서 페이지의 컨테이너 레지스트리 취약성 탭에서 볼 수 있습니다.

전제 조건

• 레지스트리용 컨테이너 스캐닝을 활성화하려면 프로젝트에서 최소한 Maintainer 역할을 가지고 있어야 합니다.
• 사용되는 프로젝트는 비어 있지 않아야 합니다. 컨테이너 이미지를 저장하기 위해 빈 프로젝트를 사용하는 경우, 이 기능은 의도한 대로 작동하지 않습니다. 우회 방법으로, 프로젝트에 기본 브랜치에서 초기 커밋이 포함되어 있는지 확인하세요.
• 기본적으로 하루에 프로젝트당 50개의 스캔 제한이 있습니다.
• 컨테이너 레지스트리 알림을 구성해야 합니다.

레지스트리용 컨테이너 스캐닝 활성화

GitLab Container Registry에 대한 컨테이너 스캐닝을 활성화하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 보안 > 보안 구성을 선택합니다.
3. 레지스트리용 컨테이너 스캐닝 섹션으로 스크롤하고 토글을 켭니다.

취약성 데이터베이스

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

이미지는 업스트림 참고 자료 데이터베이스의 데이터를 사용합니다:

• 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 Advisory Database.
• 오픈 소스 GitLab Advisory Database (오픈 소스 에디션).

GitLab Ultimate 계층에서는 GitLab Advisory Database에서 가져온 데이터가 외부 출처의 데이터를 보강하기 위해 병합됩니다. GitLab Premium 및 Free 계층에서는 GitLab Advisory Database (오픈 소스 에디션)에서 가져온 데이터가 외부 출처의 데이터를 보강하기 위해 병합됩니다. 이 보강은 현재 Trivy 스캐너의 분석기 이미지에만 적용됩니다.

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

취약점에 대한 솔루션 (자동 수정)

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

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

수정 지원을 활성화하려면 스캐닝 도구가 CS_DOCKERFILE_PATH CI/CD 변수로 지정된 Dockerfile에 접근할 수 있어야 합니다. 스캐닝 도구가 이 파일에 접근할 수 있도록 하려면, 이 문서의 컨테이너 스캐닝 템플릿 오버라이딩 섹션에 설명된 지침에 따라 .gitlab-ci.yml 파일에 GIT_STRATEGY: fetch를 설정해야 합니다.

취약점 해결 방법에 대한 자세한 내용을 읽어보세요.

문제 해결

docker: Error response from daemon: failed to copy xattrs

러너가 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>

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의 특정 파일이나 폴더를 바인딩하세요 (예: /tmp/myfile.txt).

context deadline exceeded 오류 해결

이 오류는 타임아웃이 발생했음을 의미합니다. 이를 해결하려면 container_scanning 작업에 충분히 긴 지속 시간을 가진 TRIVY_TIMEOUT 환경 변수를 추가하세요.

변경 사항

컨테이너 스캐닝 분석기에 대한 변경 사항은 프로젝트의 changelog에서 확인할 수 있습니다.