• 지원되는 언어 및 패키지 관리자
• 의존성 감지
  • 분석기
  • 분석기가 의존성 정보를 얻는 방법
    • 잠금파일을 구문분석하여 의존성정보 얻기
    • 실행 가능한 파일 생성을 위해 패키지 관리자를 실행하여 의존성 정보 생성
  • 분석기가 어떻게 트리거되는가
  • 여러 파일이 처리되는 방법
    • Python
    • Java 및 Scala
    • JavaScript
    • Go
    • PHP, C, C++, .NET, C#, Ruby, JavaScript
    • 추가 언어 지원
• 구성
  • CI/CD 템플릿을 사용하여 분석기를 활성화
    • .gitlab-ci.yml 파일을 매뉴얼으로 편집
    • 미리 구성된 Merge Request 사용
  • CI/CD 컴포넌트를 사용하여 의존성 스캔 활성화
    • 언어 및 패키지 관리자별 사용 가능한 CI/CD 컴포넌트
  • MR(Merge Request) 파이프라인에서 작업 실행
  • 분석기 동작 사용자 정의
  • 의존성 스캔 작업 재정의
  • 사용 가능한 CI/CD 변수
    • 전역 분석기 설정
    • 분석기별 설정
    • 기타 변수
  • 사용자 지정 TLS 인증 기관
    • 사용자 지정 TLS 인증 기관 사용
  • 개인 Maven 리포지터리 사용
  • FIPS 활성화 이미지
• 출력
  • Dependency scanning 보고서
  • CycloneDX Software Bill of Materials
    • 여러 CycloneDX SBOM Merge
• 취약점 데이터베이스 기여
• 오프라인 환경
  • 요구 사항
  • 분석기 이미지의 로컬 사본
  • GitLab Advisory Database 액세스
    • GitLab Advisory Database의 복제본 사용
    • GitLab Advisory Database의 사본 사용
• Gradle 프로젝트에서 프록시 사용
• Maven 프로젝트에서 프록시 사용
• 언어 및 패키지 관리자에 대한 구체적인 설정
  • Python (pip)
  • Python (setuptools)
  • Python (Pipenv)
• 경고
  • Python 프로젝트
  • 버전 번호 구문 분석

의존성 스캐닝

의존성 스캐닝은 알려진 취약점을 가진 애플리케이션의 의존성을 분석합니다. 모든 의존성, 즉 전이적 의존성 또는 중첩된 의존성도 스캔됩니다.

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

의존성 스캐닝은 애플리케이션 수명 주기의 개발 단계에서 실행할 수 있습니다. 파이프라인이 실행될 때마다 취약점이 식별되고 소스 및 타깃 브랜치 간에 비교됩니다. Merge Request에 취약점과 심각도가 나열되어 코드 변경이 커밋되기 전에 애플리케이션의 위험에 대응할 수 있습니다. 취약점은 파이프라인 외부에서도 식별될 수 있으며 지속적인 취약성 스캐닝도 가능합니다.

GitLab은 의존성 스캐닝과 컨테이너 스캐닝을 모두 제공하여 모든 이러한 의존성 유형을 대상으로 보호합니다. 가능한 최대한 위험 영역을 커버하기 위해 모든 보안 스캐너를 사용할 것을 권장합니다. 이러한 기능을 비교하려면 의존성 스캐닝과 컨테이너 스캐닝 비교를 참조하세요.

• 개요는 의존성 스캐닝을 참조하세요.
• 인터랙티브 리딩 및 이용 방법 데모에 대해 의존성 스캐닝 튜토리얼 GitLab Application Security part 3를 참조하세요
• 다른 인터랙티브 리딩 및 이용 방법 데모는 GitLab Application Security Playlist에서 시작하세요

지원되는 언어 및 패키지 관리자

의존성 스캐닝 CI 템플릿을 사용하여 분석기 활성화 시 다음 언어 및 의존성 관리자가 지원됩니다:

1. Java 21 LTS는 sbt를 위한 제한된 버전 1.9.7로 제한됩니다. 지원되는 더 많은 sbt 버전은 issue 430335에서 추적됩니다. FIPS 모드를 활성화한 경우 지원되지 않습니다.

2. FIPS 모드가 활성화된 경우 Gradle은 지원되지 않습니다.

의존성 감지

의존성 스캐닝은 리포지터리에 사용된 언어를 자동으로 감지합니다. 감지된 언어와 일치하는 모든 분석기가 실행됩니다. 분석기를 사용자 정의할 필요는 일반적으로 없습니다. 최상의 범위를 위해 모든 분석기를 자동으로 선택하도록하여 폐기 또는 제거가 발생할 때 조정할 필요가 없도록 권장합니다. 그러나 DS_EXCLUDED_ANALYZERS 변수를 사용하여 선택사항을 재정의할 수 있습니다.

언어 감지는 CI 작업 rules에 의존하며 리포지터리의 루트로부터 최대 두 디렉터리 레벨을 검색합니다. 예를 들어 gemnasium-dependency_scanning 작업은 리포지터리에 Gemfile, api/Gemfile, 또는 api/client/Gemfile 중 하나가 포함되어 있는 경우 활성화되지만 api/v1/client/Gemfile과 같이 지원되는 의존성 파일이 하나뿐인 경우에는 활성화되지 않습니다.

Java 및 Python의 경우, 지원되는 의존성 파일이 감지되면 의존성 스캐닝은 프로젝트를 빌드하고 일부 Java 또는 Python 명령을 실행하여 의존성 디렉터리을 가져옵니다. 다른 모든 프로젝트의 경우 프로젝트를 먼저 빌드할 필요 없이 잠금 파일을 구문 분석하여 의존성 디렉터리을 얻습니다.

지원되는 의존성 파일이 감지되면, 중첩된 또는 종속적인 의존성의 깊이에 제한이 없습니다.

분석기

의존성 스캐닝은 다음 공식적인 Gemnasium 기반 분석기를 지원합니다:

• gemnasium
• gemnasium-maven
• gemnasium-python

분석기는 Docker 이미지로 게시되며, 이를 사용하여 의존성 스캐닝은 각 분석을 위해 전용 컨테이너를 시작합니다. 또한 사용자 정의 보안 스캐너를 통합할 수도 있습니다.

각 분석기는 새로운 Gemnasium 버전이 출시됨에 따라 업데이트됩니다. 자세한 정보는 분석기 릴리스 프로세스 문서를 참조하십시오.

분석기가 의존성 정보를 얻는 방법

GitLab 분석기는 다음 두 방법 중 하나를 사용하여 의존성 정보를 얻습니다:

1. 잠금 파일 직접 구문 분석하기
2. 패키지 관리자 또는 빌드 도구를 실행하여 생성된 의존성 정보 파일을 구문 분석하기

잠금파일을 구문분석하여 의존성정보 얻기

다음 패키지 관리자는 GitLab 분석기가 직접 구문 분석할 수 있는 잠금 파일을 사용합니다.

1. Go 프로젝트에서 사용하는 빌드 디렉터리을 생성할 수 없는 경우, 의존성 스캐닝은 go.sum을 구문 분석합니다.

2. NuGet 버전 2 잠금 파일의 지원은 GitLab 16.2에서 소개되었습니다.

3. lockfileVersion = 3 지원은 GitLab 15.7에서 소개되었습니다.

4. Yarn 버전 4 지원은 GitLab 16.11에서 소개되었습니다.

   Yarn Berry의 다음 기능은 지원되지 않습니다:

   • 작업 영역
   • yarn patch

   패치, 작업 영역 또는 둘 다를 포함하는 Yarn 파일은 여전히 처리되지만 이러한 기능은 무시됩니다.

실행 가능한 파일 생성을 위해 패키지 관리자를 실행하여 의존성 정보 생성

다음과 같은 패키지 관리자를 지원하기 위해 GitLab 분석기는 다음 두 단계로 진행합니다:

1. 패키지 관리자 또는 특정 작업을 실행하여 의존성 정보를 내보냅니다.
2. 내보낸 의존성 정보를 구문 분석합니다.

1. 이 테스트는 .tool-versions 파일에서 지정된 maven의 기본 버전을 사용합니다.

2. 서로 다른 Java 버전에 따라 다른 Gradle 버전이 필요합니다. 상기 표에 나열된 Gradle 버전은 분석기 이미지에 사전 설치되어 있습니다. 분석기에 의해 사용되는 Gradle 버전은 프로젝트가 gradlew 파일을 사용하는지 여부에 따라 달라집니다:

   • 프로젝트가 사용하지 않는 경우, 분석기는 DS_JAVA_VERSION 변수에 의해 지정된 Java 버전에 따라 사전 설치된 Gradle 버전 중 하나로 자동 전환됩니다. 기본적으로 분석기는 Java 17 및 Gradle 7.3.3을 사용합니다.

     Java 버전 8 및 11의 경우, Gradle 6.7.1이 자동으로 선택되며, Java 버전 17의 경우 Gradle 7.3.3이 자동으로 선택됩니다.

   • 프로젝트가 사용하는 경우, 분석기 이미지에 사전 설치된 Gradle 버전은 무시되고, 프로젝트의 gradlew 파일에서 지정된 버전이 대신 사용됩니다.

3. 이 테스트는 Pipfile.lock 파일이 발견되면, Gemnasium이 이 파일에 나열된 정확한 패키지 버전을 스캔하는지 확인합니다.

4. go build의 구현으로, Go 빌드 프로세스는 네트워크 액세스, go mod download를 통한 사전 로드된 mod 캐시, 또는 vendored 의존성이 필요합니다. 자세한 내용은 패키지 및 의존성 컴파일의 Go 문서를 참조하십시오.

분석기가 어떻게 트리거되는가

GitLab은 rules:exists을 의존하며, 리포지터리의 지원되는 파일의 존재 여부에 따라 감지된 언어에 해당하는 분석기를 시작합니다. 위의 표에서 확인할 수 있습니다.

현재의 감지 로직은 최대 검색 깊이를 두 수준으로 제한합니다. 예를 들어, gemnasium-dependency_scanning 작업은 Gemfile.lock, api/Gemfile.lock, 또는 api/client/Gemfile.lock 중 하나를 포함하고 있을 때 활성화되지만, 유일하게 지원되는 의존성 파일이 api/v1/client/Gemfile.lock인 경우에는 활성화되지 않습니다.

지원되는 의존성 파일이 감지되면 모든 의존성(추이적 의존성 포함)이 분석됩니다. 분석되는 중첩 또는 추이적 의존성의 깊이에 제한이 없습니다.

여러 파일이 처리되는 방법

Python

요구 사항 파일 또는 잠금 파일 중 어느 하나가 감지된 디렉터리에서만 하나의 설치가 실행됩니다. 의존성은 포함될 때 잠금 파일에 따라 gemnasium-python에 의해 분석됩니다. 파일은 다음 순서대로 검색됩니다.

1. Pip를 사용하는 프로젝트의 경우 requirements.txt, requirements.pip, 또는 requires.txt.
2. Pipenv를 사용하는 프로젝트의 경우 Pipfile 또는 Pipfile.lock.
3. Poetry를 사용하는 프로젝트의 경우 poetry.lock.
4. Setuptools를 사용하는 프로젝트의 경우 setup.py.

검색은 루트 디렉터리에서 시작하여 루트 디렉터리에서 빌드가 발견되지 않은 경우 하위 디렉터리로 진행됩니다. 따라서 루트 디렉터리에 있는 Poetry 잠금 파일이 하위 디렉터리에 있는 Pipenv 파일보다 먼저 감지됩니다.

Java 및 Scala

빌드 파일이 감지된 디렉터리에서만 하나의 빌드가 실행됩니다. 여러 Gradle, Maven 또는 sbt 빌드, 또는 이러한 조합을 포함하는 대형 프로젝트의 경우, gemnasium-maven은 감지된 첫 번째 빌드 파일에 대해만 의존성을 분석합니다. 빌드 파일은 다음 순서대로 검색됩니다.

1. 단일 또는 다중 모듈 Maven 프로젝트의 경우 pom.xml.
2. 단일 또는 다중 프로젝트 Gradle 빌드의 경우 build.gradle 또는 build.gradle.kts.
3. 단일 또는 다중 프로젝트 sbt 빌드의 경우 build.sbt.

검색은 루트 디렉터리에서 시작하여 루트 디렉터리에서 빌드가 발견되지 않은 경우 하위 디렉터리로 진행됩니다. 따라서 루트 디렉터리에 있는 sbt 빌드 파일이 하위 디렉터리에 있는 Gradle 빌드 파일보다 먼저 감지됩니다.

JavaScript

다음 분석기들이 실행됩니다. 각 분석기는 여러 파일을 처리할 때 다른 동작을 합니다.

• Gemnasium

  여러 lockfiles를 지원합니다.

• Retire.js

  여러 lockfiles를 지원하지 않습니다. 여러 lockfiles가 존재할 때 Retire.js는 알파벳순으로 디렉터리 트리를 통해 발견된 첫 번째 lockfile을 분석합니다.

gemnasium 분석기는 JavaScript 프로젝트의 vendored 라이브러리(즉, 프로젝트에 체크아웃되었지만 패키지 관리자로 관리되지 않는 라이브러리)를 스캔합니다.

Go

여러 파일이 지원됩니다. go.mod 파일이 감지되면, 분석기는 Minimal Version Selection을 사용하여 build list를 생성하려고 시도합니다. 비 치명적인 오류가 발생하면, 분석기는 사용 가능한 go.sum 파일을 구문 분석하기로 되돌아갑니다. 이 프로세스는 감지된 각 go.mod 및 go.sum 파일에 대해 반복됩니다.

PHP, C, C++, .NET, C#, Ruby, JavaScript

이러한 언어의 분석기는 여러 lockfiles를 지원합니다.

추가 언어 지원

추가 언어, 의존성 관리자 및 의존성 파일의 지원은 다음 이슈에서 추적됩니다.

구성

의존성 스캔 분석기를 활성화하여 알려진 취약점을 위해 응용프로그램의 의존성을 스캔하도록 합니다. 그런 다음 CI/CD 변수를 사용하여 동작을 조정할 수 있습니다.

CI/CD 템플릿을 사용하여 분석기를 활성화

전제 조건:

• .gitlab-ci.yml 파일에는 test 단계가 있어야 합니다.
• Self-Managed Runner를 사용하는 경우, docker 또는 kubernetes executor가 있는 GitLab Runner가 필요합니다.
• GitLab.com에서 SaaS Runner를 사용하는 경우, 기본적으로 이 기능이 활성화됩니다.

분석기를 활성화하려면:

• 자동 DevOps를 활성화합니다. 이것은 의존성 스캔을 포함합니다.
• 매뉴얼으로 .gitlab-ci.yml 파일을 편집합니다. 파일이 복잡한 경우에 이 방법을 사용하십시오.
• 미리 구성된 Merge Request을 사용합니다.
• 의존성 스캔을 강제로 실행하는 스캔 실행 정책을 만듭니다.

.gitlab-ci.yml 파일을 매뉴얼으로 편집

이 방법은 기존의 .gitlab-ci.yml 파일을 매뉴얼으로 편집해야 합니다. 귀하의 GitLab CI/CD 구성 파일이 복잡한 경우에 이 방법을 사용하십시오.

의존성 스캔을 활성화하려면:

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

4. 다음을 .gitlab-ci.yml 파일의 맨 아래에 복사하여 붙여 넣으십시오. 이미 include 줄이 있는 경우, 아래에 template 줄만 추가하십시오.

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

5. 유효성 검사 탭을 선택한 후, 파이프라인 유효성 검사를 선택합니다.

   메시지 시뮬레이션 완료됨은 파일이 유효하다는 것을 확인합니다.

6. 편집 탭을 선택합니다.
7. 필드를 작성합니다. 브랜치 필드에는 기본 브랜치를 사용하지 마십시오.
8. 이 변경으로 새로운 Merge Request 시작 확인란을 선택한 후, 변경 내용 커밋을 선택합니다.
9. 기존의 표준적인 워크플로에 따라 필드를 작성하고, Merge Request 생성을 선택합니다.
10. Merge Request을 검토하고 표준적인 워크플로에 따라 Merge을 선택합니다.

이제 파이프라인에 의존성 스캔 작업이 포함됩니다.

미리 구성된 Merge Request 사용

이 방법은 .gitlab-ci.yml 파일이 없는 경우나 최소한의 구성 파일이 있는 경우에 자동으로 .gitlab-ci.yml 파일에 의존성 스캔 템플릿을 포함하여 Merge Request을 준비합니다. 그런 다음 Merge Request을 통해 의존성 스캔을 활성화합니다.

의존성 스캔을 활성화하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
2. 보안 > 보안 구성을 선택합니다.
3. 의존성 스캔 행에서 Merge Request으로 구성을 선택합니다.
4. Merge Request 생성을 선택합니다.
5. Merge Request을 검토한 후, Merge을 선택합니다.

이제 파이프라인에 의존성 스캔 작업이 포함됩니다.

CI/CD 컴포넌트를 사용하여 의존성 스캔 활성화

• GitLab 17.0에서 도입되었습니다. 이 기능은 Experiment입니다.
• 의존성 스캔 CI/CD 컴포넌트는 Android 프로젝트만 지원합니다.

애플리케이션의 의존성을 스캔하려면 CI/CD 컴포넌트를 사용하십시오. 지침은 해당 컴포넌트의 README 파일을 참조하십시오.

언어 및 패키지 관리자별 사용 가능한 CI/CD 컴포넌트

• Android 애플리케이션

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

MR(Merge Request) 파이프라인에서 보안 스캔 도구 사용을 참조하십시오.

분석기 동작 사용자 정의

의존성 스캔 동작을 사용자 정의하려면 CI/CD 변수를 사용할 수 있습니다.

의존성 스캔 작업 재정의

작업 정의를 재정의하려면(variables 또는 dependencies와 같은 속성 변경) 재정의할 작업과 동일한 이름의 새 작업을 선언하십시오. 이 새 작업은 템플릿 포함 후에 배치되어야 하며 추가 키를 지정해야 합니다. 예를 들어, 다음은 gemnasium 분석기의 DS_REMEDIATE를 비활성화하는 예시입니다.

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

gemnasium-dependency_scanning:
  variables:
    DS_REMEDIATE: "false"

dependencies: [] 속성을 재정의하려면, 위와 같은 방법으로 오버라이드 작업을 추가하고 해당 속성을 타겟팅하십시오.

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

gemnasium-dependency_scanning:
  dependencies: ["build"]

사용 가능한 CI/CD 변수

CI/CD 변수를 사용하여 의존성 스캔 동작을 사용자 정의할 수 있습니다.

전역 분석기 설정

다음 변수들은 전역 의존성 스캔 설정을 구성할 수 있도록 합니다.

분석기별 설정

다음 변수들은 특정 의존성 스캔 분석기의 동작을 구성합니다.

기타 변수

이전 표는 사용할 수있는 모든 변수의 철저한 디렉터리이 아닙니다. 지원 및 테스트하는 모든 구체적인 GitLab 및 분석기 변수를 포함하고 있습니다. 환경 변수와 같은 많은 변수가 있으며 이를 전달할 수 있으며 그들은 작동합니다. 이는 많은 디렉터리이며 우리가 알지 못할 수 있으며 따라서 문서화되지 않았습니다.

예를 들어, 모든 Dependency Scanning 작업에 비-GitLab 환경 변수 HTTPS_PROXY를 전달하려면, 다음과 같이 .gitlab-ci.yml 파일의 CI/CD 변수를 설정하십시오.

variables:
  HTTPS_PROXY: "https://squid-proxy:3128"

또는 Dependency Scanning과 같은 특정 작업에서 사용할 수 있습니다.

dependency_scanning:
  variables:
    HTTPS_PROXY: $HTTPS_PROXY

모든 변수를 테스트하지 않았으므로 일부 변수가 작동하는 것을 발견할 수도 있고, 다른 변수는 작동하지 않을 수 있습니다. 작동하지 않는 변수가 있고 필요한 경우 기능 요청을 제출하거나 코드 기여를하여 해당 변수를 사용할 수 있도록 합니다.

사용자 지정 TLS 인증 기관

Dependency Scanning을 사용하면 분석기 컨테이너 이미지와 함께 제공되는 기본값 대신 SSL/TLS 연결에 대한 사용자 지정 TLS 인증서를 사용할 수 있습니다.

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

사용자 지정 TLS 인증 기관 사용

사용자 지정 TLS 인증 기관을 사용하려면 CI/CD 변수 ADDITIONAL_CA_CERT_BUNDLE에 X.509 PEM 공개키 인증서의 텍스트 표현를 할당하십시오.

예를 들어, .gitlab-ci.yml 파일에서 인증서를 구성하려면:

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

개인 Maven 리포지터리 사용

개인 Maven 리포지터리에 로그인 자격 증명이 필요한 경우 MAVEN_CLI_OPTS CI/CD 변수를 사용할 수 있습니다.

개인 Maven 리포지터리 사용에 대해 자세히 알아보세요. 개인 Maven 리포지터리 사용 방법.

FIPS 활성화 이미지

• GitLab 15.0에서 도입됨 - FIPS 모드가 활성화되면 Gemnasium은 FIPS 활성화 이미지를 사용합니다.

GitLab은 또한 FIPS 활성화 Red Hat UBI 버전의 Gemnasium 이미지를 제공합니다. GitLab 인스턴스에서 FIPS 모드가 활성화되면 Gemnasium 스캐닝 작업은 자동으로 FIPS 활성화 이미지를 사용합니다. 매뉴얼으로 FIPS 활성화 이미지로 전환하려면 변수 DS_IMAGE_SUFFIX를 "-fips"로 설정하십시오.

Gradle 프로젝트용 의존성 스캐닝 및 Yarn 프로젝트용 자동 복구는 FIPS 모드에서 지원되지 않습니다.

출력

Dependency Scanning은 다음 출력을 생성합니다.

• Dependency scanning 보고서: 의존성에서 감지된 모든 취약점의 세부 정보를 포함합니다.
• CycloneDX Software Bill of Materials: 각 지원되는 잠금 또는 빌드 파일에 대한 Software Bill of Materials (SBOM).

Dependency scanning 보고서

Dependency Scanning은 모든 취약점에 대한 세부 정보를 포함하는 보고서를 출력합니다. 보고서는 내부적으로 처리되며 결과는 UI에 표시됩니다. 보고서는 또한 의존성 스캐닝 작업의 artifact로 출력되며 gl-dependency-scanning-report.json이라는 이름의 파일로 저장됩니다.

의존성 스캐닝 보고서에 대한 자세한 내용은 다음을 참조하세요.

• 보안 스캐너 통합.
• 의존성 스캐닝 보고서 스키마.

CycloneDX Software Bill of Materials

• GitLab 15.7에서 일반적으로 사용 가능합니다.

의존성 스캐닝은 감지된 각 지원되는 잠금 또는 빌드 파일에 대한 CycloneDX Software Bill of Materials (SBOM)을 출력합니다.

CycloneDX SBOM은 다음과 같습니다.

• gl-sbom-<package-type>-<package-manager>.cdx.json라는 이름으로 지정됩니다.
• 의존성 스캐닝 작업의 job artifact로 사용할 수 있습니다.
• 감지된 잠금 또는 빌드 파일과 동일한 디렉터리에 저장됩니다.

예를 들어, 프로젝트에 다음과 같은 구조가 있는 경우:

.
├── ruby-project/
│   └── Gemfile.lock
├── ruby-project-2/
│   └── Gemfile.lock
├── php-project/
│   └── composer.lock
└── go-project/
    └── go.sum

그럼 Gemnasium 스캐너는 다음과 같은 CycloneDX SBOM을 생성합니다.

.
├── ruby-project/
│   ├── Gemfile.lock
│   └── gl-sbom-gem-bundler.cdx.json
├── ruby-project-2/
│   ├── Gemfile.lock
│   └── gl-sbom-gem-bundler.cdx.json
├── php-project/
│   ├── composer.lock
│   └── gl-sbom-packagist-composer.cdx.json
└── go-project/
    ├── go.sum
    └── gl-sbom-go-go.cdx.json

여러 CycloneDX SBOM Merge

여러 CycloneDX SBOM을 하나의 SBOM으로 Merge하는 CI/CD 작업을 사용할 수 있습니다. GitLab은 각 CycloneDX SBOM의 메타데이터에 구현에 대한 정보를 저장하기 위해 CycloneDX Properties를 사용합니다. 여러 CycloneDX SBOM이 Merge되면 이러한 정보는 결과로 생성된 파일에서 제거됩니다.

예를 들어, 다음 .gitlab-ci.yml을 사용하면 CycloneDX SBOM 파일을 Merge하고 결과 파일을 유효성을 검사할 수 있습니다.

stages:
  - test
  - merge-cyclonedx-sboms

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

merge cyclonedx sboms:
  stage: merge-cyclonedx-sboms
  image:
    name: cyclonedx/cyclonedx-cli:0.24.2
    entrypoint: [""]
  script:
    - apt-get update && apt-get install -y jq
    - find . -name "gl-sbom-*.cdx.json" -exec cyclonedx merge --output-file gl-sbom-all.cdx.json --input-files "{}" +
    # remove duplicates from merged file. See https://github.com/CycloneDX/cyclonedx-cli/issues/188 for details.
    - |
      jq '. |
      {
        "bomFormat": .bomFormat,
        "specVersion": .specVersion,
        "serialNumber": .serialNumber,
        "version": .version,
        "metadata": {
          "tools": [
            (.metadata.tools | unique[])
          ]
        },
        "components": [
          (.components | unique[])
        ]
      }' "gl-sbom-all.cdx.json" > gl-sbom-all.cdx.json.tmp && mv gl-sbom-all.cdx.json.tmp gl-sbom-all.cdx.json
    # optional: validate the merged sbom
    - cyclonedx validate --input-version v1_4 --input-file gl-sbom-all.cdx.json
  artifacts:
    paths:
      - gl-sbom-all.cdx.json

취약점 데이터베이스 기여

취약점을 찾으려면 GitLab 보고서 데이터베이스를 검색할 수 있습니다. 또한 새로운 취약점을 제출할 수도 있습니다.

오프라인 환경

인터넷을 통한 외부 리소스에 제한적이거나 일시적으로 액세스할 수 있는 환경에서의 Self-Managed형 GitLab 인스턴스의 경우, 의존성 스캐닝 작업이 성공적으로 실행되려면 일부 조정이 필요합니다. 자세한 정보는 오프라인 배포를 참조하세요.

요구 사항

오프라인 환경에서 의존성 스캐닝을 실행하려면 다음이 필요합니다:

• docker 또는 kubernetes 실행기를 갖춘 GitLab 러너
• 의존성 스캐닝 분석기 이미지의 로컬 사본
• GitLab Advisory Database에 대한 액세스

분석기 이미지의 로컬 사본

모든 지원되는 언어 및 프레임워크로 의존성 스캐닝을 사용하려면 다음 기본 의존성 스캐닝 분석기 이미지를 registry.gitlab.com에서 로컬 Docker 컨테이너 레지스트리로 가져와야 합니다:

registry.gitlab.com/security-products/gemnasium:5
registry.gitlab.com/security-products/gemnasium:5-fips
registry.gitlab.com/security-products/gemnasium-maven:5
registry.gitlab.com/security-products/gemnasium-maven:5-fips
registry.gitlab.com/security-products/gemnasium-python:5
registry.gitlab.com/security-products/gemnasium-python:5-fips

::이미지를 로컬 오프라인 Docker 레지스트리로 가져오는 과정은 네트워크 보안 정책에 따라 다릅니다. 외부 리소스를 가져오거나 일시적으로 액세스할 수 있는 승인된 프로세스를 찾으려면 IT 스태프에게 상담하세요. 이러한 스캐너 이미지는 정기적으로 업데이트되며 정기적으로 다운로드할 수 있습니다.::

1. GitLab CI/CD를 사용하여 로컬 분석기를 구성합니다.

   CI/CD 변수 SECURE_ANALYZERS_PREFIX의 값을 사용할 로컬 Docker 레지스트리로 설정합니다. 이 예에서는 docker-registry.example.com입니다.

   include:
     - template: Security/Dependency-Scanning.gitlab-ci.yml
      
   variables:
     SECURE_ANALYZERS_PREFIX: "docker-registry.example.com/analyzers"
   

GitLab Advisory Database 액세스

GitLab Advisory Database는 gemnasium, gemnasium-maven, gemnasium-python 분석기에서 사용하는 취약점 데이터의 원본입니다. 이러한 분석기 이미지에는 데이터베이스의 복제본이 포함되어 있습니다. 스캔을 시작하기 전에 복제본은 데이터베이스와 동기화되어 분석가가 최신 취약점 데이터를 보유하도록 합니다.

오프라인 환경에서는 GitLab Advisory Database의 기본 호스트에 액세스할 수 없습니다. 대신 데이터베이스를 GitLab 러너에서 액세스할 수 있는 곳에 호스팅해야 합니다. 또한 데이터베이스를 자체 일정에 따라 매뉴얼으로 업데이트해야 합니다.

데이터베이스를 호스팅할 수 있는 옵션은 다음과 같습니다:

• GitLab Advisory Database의 복제본 사용.
• GitLab Advisory Database의 사본 사용.

GitLab Advisory Database의 복제본 사용

GitLab Advisory Database의 복제본을 사용하는 것이 가장 효과적이기 때문에 추천됩니다.

GitLab Advisory Database의 복제본을 호스팅하려면:

1. GitLab Advisory Database를 GitLab 러너가 HTTP를 통해 액세스할 수 있는 호스트에 복제합니다.
2. .gitlab-ci.yml 파일에 CI/CD 변수 GEMNASIUM_DB_REMOTE_URL의 값을 Git 리포지터리의 URL로 설정하세요.

예:

variables:
  GEMNASIUM_DB_REMOTE_URL: https://users-own-copy.example.com/gemnasium-db.git

GitLab Advisory Database의 사본 사용

GitLab Advisory Database의 사본을 사용하려면 분석기가 다운로드하는 아카이브 파일을 호스팅해야 합니다.

GitLab Advisory Database의 사본을 사용하려면:

1. GitLab 러너가 HTTP를 통해 액세스할 수 있는 호스트에 GitLab Advisory Database의 아카이브를 다운로드합니다. 아카이브는 https://gitlab.com/gitlab-org/security-products/gemnasium-db/-/archive/master/gemnasium-db-master.tar.gz에서 찾을 수 있습니다.

2. .gitlab-ci.yml 파일을 업데이트합니다.

   • CI/CD 변수 GEMNASIUM_DB_LOCAL_PATH를 로컬 데이터베이스 사본으로 설정하세요.
   • CI/CD 변수 GEMNASIUM_DB_UPDATE_DISABLED를 데이터베이스 업데이트를 비활성화하도록 설정하세요.
   • 스캔이 시작되기 전에 취약점 데이터베이스를 다운로드하고 추출하세요.

   variables:
     GEMNASIUM_DB_LOCAL_PATH: ./gemnasium-db-local
     GEMNASIUM_DB_UPDATE_DISABLED: "true"
      
   dependency_scanning:
     before_script:
       - wget https://local.example.com/gemnasium_db.tar.gz
       - mkdir -p $GEMNASIUM_DB_LOCAL_PATH
       - tar -xzvf gemnasium_db.tar.gz --strip-components=1 -C $GEMNASIUM_DB_LOCAL_PATH
   

Gradle 프로젝트에서 프록시 사용

Gradle 래퍼 스크립트는 HTTP(S)_PROXY 환경 변수를 읽지 않습니다. 해당 upstream 이슈를 확인하세요(https://github.com/gradle/gradle/issues/11065).

Gradle 래퍼 스크립트에 프록시를 사용하려면 GRADLE_CLI_OPTS CI/CD 변수를 사용하여 옵션을 지정할 수 있습니다:

variables:
  GRADLE_CLI_OPTS: "-Dhttps.proxyHost=squid-proxy -Dhttps.proxyPort=3128 -Dhttp.proxyHost=squid-proxy -Dhttp.proxyPort=3128 -Dhttp.nonProxyHosts=localhost"

Maven 프로젝트에서 프록시 사용

Maven은 HTTP(S)_PROXY 환경 변수를 읽지 않습니다.

Maven 의존성 스캐너에 프록시를 사용하려면 MAVEN_CLI_OPTS CI/CD 변수를 사용하여 옵션을 지정할 수 있습니다:

variables:
  MAVEN_CLI_OPTS: "-DproxySet=true -Dhttps.proxyHost=squid-proxy -Dhttps.proxyPort=3128 -Dhttp.proxyHost=squid-proxy -Dhttp.proxyPort=3218"

언어 및 패키지 관리자에 대한 구체적인 설정

구체적인 언어 및 패키지 관리자에 대한 구성을 보려면 다음 섹션을 참조하세요.

Python (pip)

분석기가 실행되기 전에 Python 패키지를 설치해야 하는 경우 before_script에서 pip install --user를 사용해야 합니다. --user 플래그는 프로젝트 의존성이 사용자 디렉터리에 설치되도록합니다. --user 옵션을 전달하지 않으면 패키지가 전역적으로 설치되며 스캔되지 않으며 프로젝트 의존성 디렉터리에 나타나지 않습니다.

Python (setuptools)

분석기가 실행되기 전에 Python 패키지를 설치해야 하는 경우 before_script에서 python setup.py install --user를 사용해야 합니다. --user 플래그는 프로젝트 의존성이 사용자 디렉터리에 설치되도록합니다. --user 옵션을 전달하지 않으면 패키지가 전역적으로 설치되며 스캔되지 않으며 프로젝트 의존성 디렉터리에 나타나지 않습니다.

개인 PyPi 리포지터리에 대해 자체 서명된 인증서를 사용해야 하는 경우 특별한 작업 구성(위의 템플릿 .gitlab-ci.yml 이외)이 필요합니다. 그러나 리포지터리에 액세스할 수 있도록 setup.py를 업데이트해야 합니다. 다음은 예시 구성입니다:

1. install_requires 디렉터리의 각 의존성에 대해 리포지터리 URL을 가리키는 dependency_links 속성을 작성하기 위해 setup.py를 업데이트하세요:

   install_requires=['pyparsing>=2.0.3'],
   dependency_links=['https://pypi.example.com/simple/pyparsing'],
   

2. 리포지터리 URL에서 인증서를 가져와 프로젝트에 추가하세요:

   printf "\n" | openssl s_client -connect pypi.example.com:443 -servername pypi.example.com | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > internal.crt
   

3. setup.py를 새로 다운로드된 인증서를 가리키도록 업데이트하세요:

   import setuptools.ssl_support
   setuptools.ssl_support.cert_paths = ['internal.crt']
   

Python (Pipenv)

네트워크 연결이 제한된 환경에서 실행하는 경우, PIPENV_PYPI_MIRROR 변수를 구성하여 프라이빗 PyPi 미러를 사용해야 합니다. 이 미러에는 기본 및 개발 의존성이 모두 포함되어 있어야 합니다.

variables:
  PIPENV_PYPI_MIRROR: https://pypi.example.com/simple

또는, 프라이빗 레지스트리를 사용할 수 없는 경우, 필요한 패키지를 Pipenv 가상 환경 캐시에 로드할 수 있습니다. 이 옵션의 경우, 프로젝트는 Pipfile.lock를 리포지터리에 체크인하고, 기본 및 개발 패키지를 캐시에 로드해야 합니다. 이렇게 할 수 있는 예시는 python-pipenv 프로젝트를 참조하세요.

경고

모든 컨테이너의 최신 버전 및 모든 패키지 관리자 및 언어의 가장 최신 지원 버전을 사용하는 것을 권장합니다. 이전 버전을 사용하는 것은 활성 보안 보고 및 보안 수정의 지원을 더 이상 받지 못할 수 있기 때문에 보안 위험이 증가합니다.

Python 프로젝트

PIP_EXTRA_INDEX_URL 환경 변수 사용에는 CVE-2018-20225에서 문서화된 가능한 공격에 대해 추가 주의가 필요합니다:

pip (모든 버전)에서 발견된 문제는 사용자가 개인 색인에서 개인 패키지를 얻고자 했더라도 가장 높은 버전 번호의 버전을 설치하기 때문에 발생합니다. 이는 PIP_EXTRA_INDEX_URL 옵션의 사용에만 영향을 주며, 이를 악용하려면 해당 패키지가 공개 색인에 이미 존재하지 않아야 합니다 (따라서 공격자는 임의 버전 번호로 해당 패키지를 공개 색인에 넣을 수 있음).

버전 번호 구문 분석

일부 경우에는 프로젝트 의존성의 버전이 보안 공지의 영향 범위내에 있는지 확인할 수 없는 경우가 있습니다.

예를 들어:

• 버전을 알 수 없음.
• 버전이 유효하지 않음.
• 버전을 구문 분석하거나 범위와 비교하는 데 실패함.
• 버전이 dev-master 또는 1.5.x와 같이 브랜치인 경우.
• 비교된 버전이 모호함. 예를 들어 1.0.0-20241502은 타임스탬프를 포함하는 반면 다른 쪽은 그렇지 않기 때문에 1.0.0-2와 비교할 수 없습니다.

이러한 경우 분석기는 의존성을 건너뛰고 로그에 메시지를 출력합니다.

GitLab 분석기는 가정을 하지 않으며, 잘못된 양성 또는 잘못된 음성으로 이어질 수 있기 때문에 주의해야 합니다. 토론은 issue 442027을 참조하세요.