- 기능
- 전제 조건
- 구성
- 보안 대시보드
- 취약점 데이터베이스
- 취약점 해결
- 취약점 해결 방법(자동 복구)
-
문제 해결
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
- 변경 사항
컨테이너 스캐닝
귀하의 애플리케이션의 Docker 이미지는 자체적으로 알려진 취약점을 포함한 Docker 이미지를 기반으로 할 수 있습니다. 이러한 취약점을 스캔하고 Merge Request에서 표시하여 GitLab을 사용하여 Docker 기반 앱을 감사할 수 있습니다.
- 개요는 컨테이너 스캐닝을 참조하세요.
- 비디오 안내는 GitLab을 사용하여 컨테이너 스캐닝 설정하는 방법을 참조하세요.
- 초보용 튜토리얼은 취약점을 위한 Docker 컨테이너 스캔을 참조하세요.
컨테이너 스캐닝은 종종 소프트웨어 구성 분석(SCA)의 일부로 간주됩니다. SCA에는 코드가 사용하는 항목을 검사하는 측면들이 포함될 수 있습니다. 이러한 항목은 주로 외부 소스에서 가져온 응용 프로그램 및 시스템 의존성을 포함하며 직접 작성한 항목이 아닙니다.
GitLab은 모든 이러한 의존성 유형에 대한 커버리지를 보장하기 위해 컨테이너 스캐닝과 의존성 스캐닝을 제공합니다. 가능한 한 많은 리스크 영역을 커버하기 위해 모든 보안 스캐너를 사용하도록 권장합니다. 이러한 기능을 비교하려면 의존성 스캐닝과 컨테이너 스캐닝 비교를 참조하세요.
GitLab은 보안 스캐너로 Trivy 보안 스캐너를 통합하여 컨테이너에서 취약점 정적 분석을 수행합니다.
외부 디렉터리에 표시된 것 외의 보안 스캐너를 GitLab과 통합하려면 보안 스캐너 통합을 참조하세요.
다음 중 하나를 수행하여 컨테이너 스캐닝을 활성화할 수 있습니다.
- 기존의 .gitlab-ci.yml
파일에 CI 작업을 포함합니다.
- 자동 DevOps에서 제공되는 자동 컨테이너 스캐닝을 암시적으로 사용합니다.
GitLab은 소스 브랜치와 대상 브랜치 사이에서 발견된 취약점을 비교하고 Merge Request에서 정보를 직접 표시합니다.
기능
기능 | Free 및 Premium에서 | Ultimate에서 |
---|---|---|
스캐너 구성 | 예 | 예 |
설정 사용자 지정(변수, 오버라이딩, 오프라인 환경 지원 등) | 예 | 예 |
CI 작업 아티팩트로 JSON 보고서 보기 | 예 | 예 |
CycloneDX SBOM JSON 보고서 생성 | 예 | 예 |
GitLab UI에서 컨테이너 스캐닝을 활성화할 수 있는 기능 | 예 | 예 |
UBI 이미지 지원 | 예 | 예 |
Trivy 지원 | 예 | 예 |
GitLab 공지 데이터베이스 포함 | GitLab의 advisories-communities 프로젝트의 지연된 콘텐츠로 한정 | 예 - Gemnasium DB의 모든 최신 콘텐츠 |
Merge Request 및 CI 파이프라인 작업의 보안 탭에서 보고 데이터 제시 | 아니요 | 예 |
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 변수를 사용하여 분석기를 구성할 수 있습니다.
ADDITIONAL_CA_CERT_BUNDLE
| ""
| 신뢰할 CA 인증서 번들입니다. 자세한 내용은 사용자 지정 SSL CA 인증서 사용를 참조하세요. | All |
| CI_APPLICATION_REPOSITORY
| $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
| 스캔할 이미지의 Docker 리포지터리 URL입니다. | All |
| CI_APPLICATION_TAG
| $CI_COMMIT_SHA
| 스캔할 이미지의 Docker 리포지터리 태그입니다. | All |
| CS_ANALYZER_IMAGE
| registry.gitlab.com/security-products/container-scanning:7
| 분석기의 Docker 이미지입니다. | All |
| CS_DEFAULT_BRANCH_IMAGE
| ""
| CS_IMAGE
의 기본 브랜치에서의 이름입니다. 자세한 내용은 기본 브랜치 이미지 설정를 참조하세요. | All |
| CS_DISABLE_DEPENDENCY_LIST
| "false"
| GitLab 17.0에서 제거됨. | All |
| CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN
| "true"
| 스캔 이미지에 설치된 언어별 패키지에 대한 스캔을 비활성화합니다. | All |
| CS_DOCKER_INSECURE
| "false"
| HTTPS를 통해 안전한 Docker 레지스트리에 인증서 확인을 하지 않고 액세스할 수 있게 합니다. | All |
| CS_DOCKERFILE_PATH
| Dockerfile
| 자동 복구 생성에 사용할 Dockerfile
의 경로입니다. 기본적으로 스캐너는 프로젝트의 루트 디렉터리에 있는 Dockerfile
이라는 파일을 찾습니다. 프로젝트에서 Dockerfile
이 비표준 위치(예: 서브디렉터리)에 있을 경우에만 이 변수를 구성해야 합니다. 자세한 내용은 취약점에 대한 솔루션을 참조하세요. | All |
| CS_IGNORE_STATUSES
1 | ""
| 분석기가 특정 상태의 취약점 결과를 무시하도록 하는 디렉터리입니다. trivy
에서 허용되는 값은 다음과 같습니다: unknown,not_affected,affected,fixed,under_investigation,will_not_fix,fix_deferred,end_of_life
. | All |
| CS_IGNORE_UNFIXED
| "false"
| 수정되지 않은 취약점을 무시합니다. | All |
| CS_IMAGE
| $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG
| 스캔할 Docker 이미지입니다. 설정된 경우 이 변수가 $CI_APPLICATION_REPOSITORY
및 $CI_APPLICATION_TAG
변수를 덮어씁니다. | All |
| CS_IMAGE_SUFFIX
| ""
| CS_ANALYZER_IMAGE
에 추가되는 접미어입니다. -fips
로 설정한 경우 FIPS-enabled
이미지가 스캔에 사용됩니다. 자세한 내용은 FIPS-enabled 이미지를 참조하세요. | All |
| CS_QUIET
| ""
| 설정된 경우 작업 로그에서 취약점 테이블의 출력을 비활성화합니다. GitLab 15.1에서 도입되었습니다. | All |
| CS_REGISTRY_INSECURE
| "false"
| 안전하지 않은 레지스트리(HTTP)에 액세스할 수 있게 합니다. 로컬에서 이미지를 테스트하는 경우에만 true
로 설정해야 합니다. Trivy가 작동하려면 레지스트리가 80/tcp
포트에서 청취해야 합니다. | All |
| CS_REGISTRY_PASSWORD
| $CI_REGISTRY_PASSWORD
| 인증이 필요한 Docker 레지스트리에 액세스하기 위한 비밀번호입니다. 기본값은 $CS_IMAGE
가 $CI_REGISTRY
에 있을 때만 설정됩니다. FIPS mode가 활성화되어 있는 경우 지원되지 않습니다. | All |
| CS_REGISTRY_USER
| $CI_REGISTRY_USER
| 인증이 필요한 Docker 레지스트리에 액세스하기 위한 사용자 이름입니다. 기본값은 $CS_IMAGE
가 $CI_REGISTRY
에 있을 때만 설정됩니다. FIPS mode가 활성화되어 있는 경우 지원되지 않습니다. | All |
| CS_SEVERITY_THRESHOLD
| UNKNOWN
| 심각도 수준 임계치입니다. 지원되는 수준은 UNKNOWN
, LOW
, MEDIUM
, HIGH
, CRITICAL
입니다. 분석기는 이 임계치보다 높거나 같은 심각도 수준의 취약점을 출력합니다. | Trivy |
| CS_TRIVY_JAVA_DB
| "ghcr.io/aquasecurity/trivy-java-db"
| trivy-java-db 취약점 데이터베이스를 대체하는 대체 위치를 지정합니다. | Trivy |
| SECURE_LOG_LEVEL
| info
| 최소 로깅 레벨을 설정합니다. 이 로깅 레벨 이상의 메시지가 출력됩니다. 로깅 수준은 다음과 같습니다. fatal
, error
, warn
, info
, debug
. | All |-
수정 상태 정보는 소프트웨어 공급 업체 및 컨테이너 이미지 운영 체제 패키지 메타데이터의 정확한 수정 가능성 데이터에 매우 의존적이며 개별 컨테이너 스캐너의 해석에 따라 다릅니다. 컨테이너 스캐너가 취약점에 대한 수정된 패키지의 가용성을 잘못 보고하는 경우 `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
플래그가 CS_ANALYZER_IMAGE
에 자동으로 추가됩니다.FIPS 모드가 활성화된 경우에는 인증된 레지스트리의 이미지를 컨테이너 스캔할 수 없습니다. CI_GITLAB_FIPS_MODE
가 "true"
로 설정되고 CS_REGISTRY_USER
또는 CS_REGISTRY_PASSWORD
가 설정되어 있는 경우, 분석기는 오류로 종료되고 스캔을 수행하지 않습니다.
자동 Merge Request을 통한 컨테이너 스캔 활성화
프로젝트에서 컨테이너 스캔을 활성화하려면 보안 구성 페이지에서 Merge Request을 생성하세요.
- 컨테이너 스캔을 활성화하려는 프로젝트에서 Secure > Security configuration로 이동합니다.
- 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
로 구성하면 인증서의 경로가 필요하고, 변수로 구성하면 인증서의 텍스트 표현이 필요합니다.
취약점 허용 디렉터리
특정 취약점을 허용디렉터리에 추가하려면 다음 단계를 따르세요:
-
컨테이너 스캔 템플릿 재정의 지침에 따라
.gitlab-ci.yml
파일에GIT_STRATEGY: fetch
를 설정합니다. -
vulnerability-allowlist.yml
이라는 YAML 파일에 허용 디렉터리에 있는 취약점을 정의하세요. 이 파일은vulnerability-allowlist.yml
데이터 형식에서 설명한 형식을 사용해야 합니다. -
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
에서 다음을 제외합니다:
- CVE ID: CVE-2019-8696, CVE-2014-8166, _CVE-2017-18248_을 포함한 모든 취약점.
-
registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256
컨테이너 이미지에서 발견된 모든 CVE ID가 _CVE-2018-4180_인 취약점. -
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
).
- 이미지 이름만으로(예:
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
로 표시됩니다.
오프라인 환경에서 컨테이너 스캔 실행
인터넷을 통한 외부 리소스에 대한 제한적이거나 intermittent한 접근 권한이 있는 환경에서 Self-Managed GitLab 인스턴스의 경우, 컨테이너 스캔 작업이 성공적으로 실행되려면 일부 조정이 필요합니다. 자세한 내용은 오프라인 배포를 참조하세요.
오프라인 컨테이너 스캔 요구 사항
오프라인 환경에서 컨테이너 스캔을 사용하려면 다음이 필요합니다:
-
docker
또는kubernetes
executor가 있는 GitLab Runner. - 컨테이너 스캔 이미지의 로컬 Docker 컨테이너 레지스트리를 구성해야 합니다. 해당 이미지는 각각의 레지스트리에서 찾을 수 있습니다:
GitLab Analyzer | 컨테이너 레지스트리 |
---|---|
컨테이너-스캔 | 컨테이너-스캔 컨테이너 레지스트리 |
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 변수 설정하여 로컬 컨테이너 스캐너 분석기 사용
-
컨테이너 스캐닝 템플릿 재정의을
.gitlab-ci.yml
파일에서 오버라이드하여 로컬 Docker 컨테이너 레지스트리에 호스팅된 Docker 이미지를 참조하도록 설정합니다.include: - template: Jobs/Container-Scanning.gitlab-ci.yml container_scanning: image: $CI_REGISTRY/namespace/container-scanning
-
로컬 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
내의 지정된 파일 또는 폴더를 바인딩하십시오.
변경 사항
컨테이너 스캐닝 분석기의 변경 사항은 프로젝트의 변경 로그에서 찾을 수 있습니다.