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

의존성 스캐닝

의존성 스캐닝은 응용 프로그램의 의존성을 알려진 취약점을 분석합니다. 모든 의존성, 즉 중첩된 의존성 또는 중첩된 의존성으로도 알려진 이러한 의존성을 스캔합니다.

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

의존성 스캐닝은 응용 프로그램 수명 주기의 개발 단계에서 실행될 수 있습니다. 파이프라인이 실행될 때마다 취약점이 식별되고 소스 및 대상 브랜치 간에 비교됩니다. 취약점과 그 심각성은 Merge Request에 나열되어 응용 프로그램의 위험에 대응할 수 있도록 하며, 코드 변경이 커밋되기 전에 사전에 대응할 수 있게 합니다. 취약점은 또한 파이프라인 외부에서 연속적인 취약성 스캐닝으로 식별될 수도 있습니다.

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

• 간략한 개요는 의존성 스캐닝를 참조하세요
• 대화 형 독서 및 이 튜토리얼에 대한 어떤 방법의 데모를 보려면 의존성 스캐닝 튜토리얼 GitLab Application Security part 3의 사용 방법를 참조하세요
• 다른 대화 형 독서 및 방법 데모를 보려면 GitLab Application Security Playlist에서 시작하세요

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

다음 언어 및 의존성 관리자가 지원됩니다:

1. 코틀린 프로젝트에 대한 지원은 issue 336866에서 추적됩니다.

2. Java 21 LTS의 경우 sbt의 버전은 1.9.7로 제한됩니다. 더 많은 sbt 버전에 대한 지원은 issue 430335에서 추적할 수 있습니다. 이는 FIPS 모드가 활성화된 경우 지원되지 않습니다.

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

4. pnpm 잠금 파일의 지원은 GitLab 15.11에서 도입되었습니다. pnpm 잠금 파일에는 번들된 의존성이 포함되지 않으므로 보고된 의존성이 npm 또는 yarn에서 다를 수 있습니다.

5. Python 3.10을 지원하려면 다음의 스탠자를 GitLab CI/CD 구성 파일에 추가하십시오. 이것은 기본값인 Python 3.9 대신 Python 3.10 이미지를 사용한다는 것을 지정합니다.

   gemnasium-dependency_scanning:
     image:
       name: $CI_TEMPLATE_REGISTRY_HOST/security-products/gemnasium-python:4-python-3.10

6. Poetry 프로젝트에 대한 poetry.lock 파일의 지원은 GitLab 15.0에 추가되었습니다. poetry.lock 파일이 없는 프로젝트에 대한 지원은 issue에서 추적할 수 있습니다: Poetry's pyproject.toml support for dependency scanning.

7. sbt 1.0.x에 대한 지원은 GitLab 16.8에서 폐기되었습니다.

8. 3.8.8 미만의 Maven 지원은 GitLab 16.9에서 폐기되었으며, GitLab 17.0에서 제거될 예정입니다.

9. Python 3.9 지원은 GitLab 16.9에서 폐기되었으며, GitLab 17.0에서 제거될 예정입니다.

의존성 감지

의존성 스캐닝은 리포지터리에 사용된 언어를 자동으로 감지합니다. 감지된 언어와 일치하는 모든 분석기가 실행됩니다. 일반적으로 분석기의 선택을 사용자 지정할 필요가 없습니다. 폐기 또는 제거가 있을 때 조정할 필요가 없도록 최상의 커버리지를 위해 모든 분석기를 자동으로 사용하는 것이 좋습니다. 그러나 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. 직접 lock 파일을 구문 분석하는 방법.
2. package manager 또는 빌드 도구를 실행하여 구문 분석 가능한 파일을 생성한 다음 해당 파일을 구문 분석하는 방법.

lock 파일을 구문 분석하여 의존성 정보를 얻는 방법

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

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

2. NuGet 버전 2 lock 파일 지원은 GitLab 16.2에서 도입되었습니다.

3. lockfileVersion = 3이 GitLab 15.7에서 지원되기 시작했습니다.

4. Yarn v2 및 v3 지원은 GitLab 15.11에서 도입되었습니다. 그러나 이 기능은 GitLab 15.0 이후 버전에서도 사용할 수 있습니다.

   Yarn v2 또는 v3에 대해 다음 기능이 지원되지 않습니다:

   • workspaces
   • yarn patch

   패치, 워크스페이스 또는 둘 다를 포함하는 Yarn 파일은 여전히 처리되지만 해당 기능은 무시됩니다.

패키지 관리자를 실행하여 구문 분석 가능한 파일을 생성하여 의존성 정보 얻기

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

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

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

2. 서로 다른 Java 버전은 서로 다른 Gradle 버전을 필요로 합니다. 위의 표에 나열된 Gradle 버전은 분석기 이미지에 사전 설치되어 있습니다. 분석기에서 사용하는 Gradle 버전은 프로젝트가 gradlew (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이 자동으로 선택됩니다.

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

3. 이 테스트에서 확인된 사항은, Pipfile.lock 파일이 발견되면, 이 파일에 나열된 정확한 패키지 버전을 검사하는 데 Gemnasium이 사용된다는 것입니다.

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

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

GitLab은 Supported files의 존재로 감지된 언어에 해당하는 분석기를 시작하기 위해 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. 단일 또는 멀티 모듈 메이븐 프로젝트의 경우 pom.xml.
2. 단일 또는 멀티 프로젝트 그레이들 빌드의 경우 build.gradle 또는 build.gradle.kts.
3. 단일 또는 멀티 프로젝트 sbt 빌드의 경우 build.sbt.

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

JavaScript

여러 파일을 처리하는 경우 각각의 분석기가 실행됩니다. 이 때 다음과 같이 다른 동작을 가집니다:

• Gemnasium 여러 lockfile을 지원합니다.

• Retire.js 여러 lockfile을 지원하지 않습니다. 여러 lockfile이 존재하는 경우 Retire.js는 디렉터리 트리를 알파벳순으로 탐색하면서 발견한 첫 번째 lockfile을 분석합니다.

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

Go

여러 파일을 지원합니다. go.mod 파일이 감지되면 분석기는 최소 버전 선택을 사용하여 빌드 디렉터리을 생성하려고 시도합니다. 비치명적 오류가 발생하면 분석기는 사용 가능한 go.sum 파일을 파싱하는 것으로 되감아합니다. 이 프로세스는 감지된 모든 go.mod와 go.sum 파일에 대해 반복됩니다.

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

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

추가 언어 지원

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

구성

의존성 스캔 분석기를 활성화하여 애플리케이션의 의존성을 알려진 취약점에 대해 스캔하도록합니다. 그런 다음 CI/CD 변수를 사용하여 동작을 조정할 수 있습니다.

분석기 활성화

전제 조건:

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

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

• 의존성 스캔이 포함된 자동 데브옵스를 활성화합니다.
• .gitlab-ci.yml 파일을 매뉴얼으로 편집합니다. 파일이 복잡한 경우 이 방법을 사용하세요.
• 사전 구성된 머지 요청을 사용합니다.
• 의존성 스캔을 강제하는 스캔 실행 정책을 작성합니다.

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

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

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

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

4. 다음을 .gitlab-ci.yml 파일의 맨 아래에 복사하여 붙여넣습니다. include 라인이 이미 있는 경우 template 라인만 추가합니다.

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

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

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

6. 편집 탭을 선택합니다.
7. 필드를 작성합니다. 브랜치 필드에 기본 브랜치를 사용하지 마세요.
8. 이 변경 사항으로 새 머지 요청 시작하기 확인란을 선택한 다음 변경 사항 커밋을 선택합니다.
9. 기본적인 작업 흐름에 따라 필드를 작성한 다음 머지 요청 생성을 선택합니다.
10. 표준 작업 흐름에 따라 머지 요청을 검토하고 편집한 다음 머지를 선택합니다.

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

사전 구성된 Merge Request 사용

• GitLab 14.1에서 도입됨 (기본 설정으로 활성화된 sec_dependency_scanning_ui_enable 플래그 사용).
• GitLab 14.2에서 일반 사용 가능. sec_dependency_scanning_ui_enable 플래그 제거.

이 방법은 자동으로 .gitlab-ci.yml 파일에 의존성 스캔 템플릿을 포함한 Merge Request을 준비합니다. 그런 다음 Merge Request을 Merge하여 의존성 스캔을 활성화합니다.

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

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

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

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

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

분석기 동작 사용자 정의

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

의존성 스캔 작업 재정의

작업 정의를 재정의하려면 (예: 변수 또는 의존성과 같은 속성 변경), 재정의할 작업의 이름을 사용하여 새 작업을 선언합니다. 이 새로운 작업은 템플릿 삽입 후에 배치되고 그 아래에 추가 키를 지정합니다. 예를 들어, 이 작업은 gemnasium 분석기에서 DS_REMEDIATE를 사용하지 않도록 설정합니다:

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

gemnasium-dependency_scanning:
  variables:
    DS_REMEDIATE: "false"

dependencies: [] 속성을 재정의하려면, 이 속성을 대상으로 한 새로운 작업을 추가하여 위와 같이 재정의합니다.

사용 가능한 CI/CD 변수

CI/CD 변수를 사용하여 분석 동작 사용자 정의를 수행할 수 있습니다.

전역 분석기 설정

다음 변수를 사용하여 전역 의존성 스캔 설정을 구성할 수 있습니다.

분석기별 설정

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

기타 변수

이전 표들은 사용 가능하고 테스트하는 특정 GitLab 및 분석 변수를 모두 열거한 것은 아닙니다. 지원하는 그림자 변수의 모든 디렉터리은 아니며, 환경 변수와 같은 많은 변수가 전달할 수 있으며 작동합니다. 이는 많은 디렉터리으로, 우리가 인식하지 못할 수도 있는 항목이므로 문서화되지 않습니다.

예를 들어, 비-GitLab 환경 변수 HTTPS_PROXY를 모든 의존성 스캐닝 작업에 전달하려면, 다음과 같이 .gitlab-ci.yml 파일에 CI/CD 변수를 설정하세요.

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

또는 의존성 스캐닝과 같은 특정 작업에서 사용할 수 있습니다.

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 14.10에서 도입. GitLab 팀원은 기밀 문제에서 자세한 정보를 볼 수 있습니다: https://gitlab.com/gitlab-org/gitlab/-/issues/354796
• 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: 각 지원하는 잠금 또는 빌드 파일에 대한 소프트웨어 컴포넌트 디렉터리(SBOM).

Dependency scanning 보고서

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

Dependency scanning 보고서에 대한 자세한 내용은 다음을 참조하세요.

• 보안 스캐너 통합.
• Dependency scanning 보고서 스키마.

CycloneDX Software Bill of Materials

• GitLab 14.8에 도입, Beta로 제공됨.
• GitLab 15.7에서 일반적으로 사용 가능.

Dependency Scanning은 각 지원하는 잠금 또는 빌드 파일에 대한 CycloneDX 소프트웨어 컴포넌트 디렉터리(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되면 결과로 나온 Merge된 파일에서 이 정보가 제거됩니다.

예를 들어, 다음의 .gitlab-ci.yml 추출은 Cyclone 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 "{}" +
    # Merge된 파일에서 중복 제거. 자세한 내용은 https://github.com/CycloneDX/cyclonedx-cli/issues/188을 참조하세요.
    - |
      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
    # 선택 사항: Merge된 sbom 유효성 검사
    - cyclonedx validate --input-version v1_4 --input-file gl-sbom-all.cdx.json
  artifacts:
    paths:
      - gl-sbom-all.cdx.json

취약점 데이터베이스 기여

취약점을 찾으려면 GitLab Advisory Database에서 검색할 수 있습니다. 또한 새로운 취약점을 제출할 수도 있습니다.

오프라인 환경에서 의존성 스캔 실행

제한적이거나 제한된 인터넷 액세스 환경에서 Self-managed GitLab 인스턴스를 위해 의존성 스캔 작업이 성공적으로 실행되기 위해서는 몇 가지 조정이 필요합니다. 자세한 내용은 오프라인 환경을 참조하세요.

오프라인 의존성 스캔 요구 사항

오프라인 환경에서 의존성 스캔을 사용하기 위한 요구 사항은 다음과 같습니다:

• docker 또는 kubernetes executor를 사용하는 GitLab Runner
• 로컬로 사용 가능한 의존성 스캔 analyzer 이미지의 Docker 컨테이너 레지스트리

• 제한된 액세스 환경에서는 https://gitlab.com/gitlab-org/security-products/gemnasium-db.git에 액세스를 허용해야 합니다. 만약 https://gitlab.com/gitlab-org/security-products/gemnasium-db.git에 액세스를 허용할 수 없다면 해당 git 리포지터리의 오프라인 복사본을 호스팅하고 GEMNASIUM_DB_REMOTE_URL CI/CD 변수를 이 리포지터리의 URL로 설정해야 합니다. 구성 변수에 대한 자세한 정보는 analyzer 동작 사용자 정의를 참조하세요.

  이 취약점 데이터베이스는 지속적으로 업데이트되므로 로컬 복사본을 GitLab과 주기적으로 동기화해야 합니다.

GitLab Runner는 기본 pull policy로 always를 가지고, 러너가 로컬 복사본이 있는 경우에도 Docker 이미지를 GitLab 컨테이너 레지스트리에서 가져오려고 시도합니다. 오프라인 환경에서는 GitLab Runner pull_policy를 if-not-present로 설정할 수 있습니다 만약 로컬로 사용 가능한 Docker 이미지만 사용하려면 pull policy 설정을 always로 유지하는 것을 권장합니다. 이는 CI/CD 파이프라인에서 업데이트된 스캐너를 사용할 수 있도록 하는데 도움이 됩니다.

로컬 Docker 레지스트리에 의존성 스캔 analyzer 이미지를 사용 가능하게 하기

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

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

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

Docker 이미지를 파일로 저장하고 전송하는 방법에 대한 자세한 내용은 Docker 문서의 docker save, docker load, docker export, 및 docker import를 참조하세요.

로컬 의존성 스캔 analyzer를 사용하기 위해 CI/CD 작업 변수 설정

.gitlab-ci.yml 파일에 다음 구성을 추가하세요. SECURE_ANALYZERS_PREFIX 값은 귀하의 로컬 Docker 컨테이너 레지스트리를 가리키도록 변경해야 합니다. 또한 GEMNASIUM_DB_REMOTE_URL 값을 오프라인 gemnasium-db 취약점 데이터베이스의 위치로 변경해야 합니다.

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

variables:
  SECURE_ANALYZERS_PREFIX: "docker-registry.example.com/analyzers"
  GEMNASIUM_DB_REMOTE_URL: "gitlab.example.com/gemnasium-db.git"

이전 변수에 대한 설명은 구성 섹션을 참조하세요.

gemnasium_db 고급 안내 데이터베이스 복사 호스팅

gemnasium_db Git 리포지터리는 gemnasium, gemnasium-maven, 그리고 gemnasium-python에 의해 취약성 데이터의 소스로 사용됩니다. 이 리포지터리는 최신 공지를 가져오기 위해 스캔 시간에 업데이트됩니다. 그러나 제한된 네트워킹 환경 때문에 때로는 이 업데이트를 실행할 수 없는 경우가 있습니다. 이 경우 사용자는 다음 중 하나를 할 수 있습니다:

• 고급 안내 데이터베이스 호스트
• 로컬 복제 사용

고급 안내 데이터베이스 호스트

만약 환경 내에서 gemnasium_db에 접근할 수 없는 경우, 사용자는 자체 Git 복사본을 호스팅할 수 있습니다. 그럼 분석기는 사용자 복사본에서 데이터베이스를 업데이트하도록 지시할 수 있습니다. 이는 GEMNASIUM_DB_REMOTE_URL을 사용하여 설정됩니다:

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

...

로컬 복제 사용

호스팅된 복사본이 불가능한 경우, 사용자는 gemnasium-db를 클론하거나 스캔 전에 아카이브를 생성하고 분석기를 디렉터리로 지정할 수 있습니다 (GEMNASIUM_DB_LOCAL_PATH을 사용). 분석기의 자체 업데이트 메커니즘을 비활성화하세요 (GEMNASIUM_DB_UPDATE_DISABLED를 사용). 이 예시에서 데이터베이스 디렉터리는 before_script에서 생성되며, gemnasium 분석기의 스캔 작업 전에 만들어집니다:

...

gemnasium-dependency_scanning:
  variables:
    GEMNASIUM_DB_LOCAL_PATH: ./gemnasium-db-local
    GEMNASIUM_DB_UPDATE_DISABLED: "true"
  before_script:
    - mkdir $GEMNASIUM_DB_LOCAL_PATH
    - tar -xzf gemnasium_db.tar.gz -C $GEMNASIUM_DB_LOCAL_PATH

Gradle 프로젝트에 프록시 사용하기

Gradle 래퍼 스크립트는 HTTP(S)_PROXY 환경 변수를 읽지 않습니다. 이 업스트림 이슈를 확인하세요.

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 디렉터리의 각 의존성을 가리키는 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은 가장 높은 버전 번호를 가진 버전을 설치하기 때문에 영향을 미칩니다. 이는 PIP_EXTRA_INDEX_URL 옵션을 사용하는 경우에만 영향을 미치며, 악용을 위해서는 해당 패키지가 이미 공개 인덱스에 존재하지 않아야 합니다(따라서 공격자가 임의의 버전 번호를 가진 패키지를 위치시킬 수 있습니다).

버전 번호 구문 분석

일부 경우에는 프로젝트 의존성의 버전이 보안 공지의 영향을 받는 범위에 있는지 판별하는 것이 불가능합니다.

예를 들어:

• 버전을 알 수 없을 때.
• 버전이 잘못되었을 때.
• 버전의 구문 분석 또는 범위와의 비교가 실패했을 때.
• 버전이 dev-master나 1.5.x와 같은 브랜치일 때.
• 비교하는 버전이 모호할 때. 예를 들어 1.0.0-20241502는 타임스탬프를 포함하고 있는 반면 1.0.0-2는 포함하고 있지 않기 때문에 비교할 수 없습니다.

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

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