• 지원되는 언어 및 패키지 관리자
• 의존성 감지
  • 분석기
  • 분석기가 의존성 정보를 얻는 방법
    • 잠금 파일을 구문 분석하여 의존성 정보를 얻기
    • 패키지 관리자를 실행하여 구문 분석 가능한 파일을 생성하여 종속성 정보를 얻기
  • 분석기가 트리거되는 방법
  • 여러 파일이 처리되는 방법
    • Python
    • Java 및 Scala
    • JavaScript
    • Go
    • PHP, C, C++, .NET, C#, Ruby, JavaScript
    • 추가 언어 지원
• 구성
  • 분석기 활성화
    • 미리 구성된 병합 요청 사용
    • .gitlab-ci.yml 파일을 수동으로 편집
    • CI/CD 구성 요소 사용
      • 사용 가능한 CI/CD 구성 요소
  • 병합 요청 파이프라인에서 작업 실행하기
  • 분석기 동작 사용자 지정
  • 종속성 스캐닝 작업 오버라이드
  • 사용 가능한 CI/CD 변수
    • 전역 분석기 설정
    • 분석기 특정 설정
    • 기타 변수
  • 맞춤 TLS 인증 기관
    • 맞춤 TLS 인증 기관 사용하기
  • 개인 Maven 리포지토리 사용
  • FIPS 지원 이미지
• 출력
  • 종속성 스캐닝 보고서
  • CycloneDX 소프트웨어 자재 명세서
    • 여러 CycloneDX SBOM 병합하기
• 취약점 데이터베이스에 기여하기
• 오프라인 환경
  • 요구 사항
  • 분석기 이미지의 로컬 복사본
  • GitLab 자문 데이터베이스에 대한 접근
    • GitLab 자문 데이터베이스의 복제본 사용
    • GitLab 자문 데이터베이스의 사본 사용
• Gradle 프로젝트에서 프록시 사용
• Maven 프로젝트에서 프록시 사용
• 언어 및 패키지 관리자를 위한 특정 설정
  • Python (pip)
  • Python (setuptools)
  • Python (Pipenv)
• 경고
  • Gradle 프로젝트
  • Maven 프로젝트
    • 해결 방법
  • Python 프로젝트
  • 버전 번호 파싱
• Swift 프로젝트 빌드
• CocoaPods 프로젝트 빌드

종속성 스캐닝

종속성 스캐닝은 애플리케이션의 종속성을 분석하여 알려진 취약점을 찾아냅니다. 모든 종속성이 스캔되며, 여기에는 전이 종속성(중첩 종속성이라고도 알려짐)이 포함됩니다.

종속성 스캐닝은 종종 소프트웨어 구성 분석(SCA)의 일부로 간주됩니다. SCA는 코드에서 사용하는 항목을 검사하는 측면을 포함할 수 있습니다. 이러한 항목은 일반적으로 외부 소스에서 가져오는 애플리케이션 및 시스템 종속성을 포함합니다.

종속성 스캐닝은 애플리케이션 생명 주기의 개발 단계에서 실행될 수 있습니다. 파이프라인이 실행될 때마다 취약점을 식별하고 소스 브랜치와 대상 브랜치 사이에서 비교합니다. 취약점과 그 심각도는 병합 요청에 나열되며, 이는 코드 변경이 커밋되기 전에 애플리케이션에 대한 위험을 사전에 해결할 수 있도록 합니다.
취약점은 연속 취약점 스캐닝을 통해 파이프라인 외부에서도 식별될 수 있습니다.

GitLab은 모든 이러한 종속성 유형에 대한 커버리지를 보장하기 위해 종속성 스캐닝 및 컨테이너 스캐닝을 제공합니다. 위험 영역을 최대한 커버하기 위해 모든 보안 스캐너를 사용하도록 권장합니다. 이러한 기능을 비교하려면 종속성 스캐닝과 컨테이너 스캐닝 비교를 참조하십시오.

경고:
종속성 스캐닝은 컴파일러 및 인터프리터의 런타임 설치를 지원하지 않습니다.

• 개요를 보려면 종속성 스캐닝을 참조하세요.

• 이 종속성 스캐닝 문서의 인터랙티브 읽기 및 데모 방법을 보려면 GitLab 애플리케이션 보안 Part 3 - 종속성 스캐닝 튜토리얼 사용 방법을 참조하세요.

• 다른 인터랙티브 읽기 및 데모 방법은 GitLab 애플리케이션 보안 재생 목록 시작하기를 참조하세요.

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

종속성 스캐닝에서 지원하는 언어 및 종속성 관리자는 다음과 같습니다:

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

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

3. pnpm 잠금 파일에 대한 지원은 GitLab 15.11에서 도입되었습니다. pnpm 잠금 파일은 번들 종속성을 저장하지 않으므로 보고된 종속성이 npm 또는 yarn과 다를 수 있습니다.

4. poetry.lock 파일을 가진 Poetry 프로젝트에 대한 지원은 GitLab 15.0에서 추가되었습니다. poetry.lock 파일이 없는 프로젝트에 대한 지원은 문제에서 추적됩니다: 종속성 스캐닝에 대한 Poetry의 pyproject.toml 지원.

5. sbt 1.0.x에 대한 지원은 GitLab 16.8에서 사용 중지되었으며, GitLab 17.0에 제거되었습니다.

6. Maven 3.8.8 미만은 GitLab 16.9에서 사용 중지되었으며, GitLab 17.0에서 제거됩니다.

7. 이전 Python 버전은 GitLab 16.9에서 사용 중지되었으며, GitLab 17.0에서 제거되었습니다.

8. 설치 프로그램에 의해 필요하기 때문에 pip 및 setuptools는 보고서에서 제외됩니다.

9. 단지 SBOM으로, 권고 사항 없이. CocoaPods 권고 사항 연구의 스파이크를 참조하세요.

의존성 감지

의존성 스캐닝은 리포지토리에서 사용되는 언어를 자동으로 감지합니다. 감지된 언어에 맞는 모든 분석기가 실행됩니다. 일반적으로 분석기 선택을 사용자 정의할 필요는 없습니다. 최상의 범위를 위해 자동으로 전체 선택을 사용하도록 분석기를 지정하지 않는 것을 권장합니다. 이는 더 이상 사용되지 않거나 제거될 때 조정할 필요가 없으므로 편리합니다.

그러나 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. NuGet 버전 2 잠금 파일에 대한 지원은 도입되었습니다 GitLab 16.2에서.

2. lockfileVersion = 3에 대한 지원은 도입되었습니다 GitLab 15.7에서.

3. Yarn 버전 4에 대한 지원은 도입되었습니다 GitLab 16.11에서.

   다음 기능은 Yarn Berry에 대해 지원되지 않습니다:

   • 워크스페이스
   • yarn patch

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

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

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

1. 패키지 관리자 또는 특정 작업을 실행하여 종속성 정보를 내보냅니다.

2. 내보낸 종속성 정보를 구문 분석합니다.

1. 이 테스트는 maven의 기본 버전을 사용하며, 이는 .tool-versions 파일에 명시되어 있습니다.

2. 다양한 Java 버전은 서로 다른 Gradle 버전을 요구합니다. 위의 테이블에 나열된 Gradle 버전은 분석기 이미지에 미리 설치되어 있습니다. 분석기가 사용하는 Gradle 버전은 프로젝트에서 gradlew (Gradle wrapper) 파일을 사용하는지 여부에 따라 다릅니다:

   • 프로젝트에서 gradlew 파일을 사용하지 않는 경우, 분석기는 자바에 의해 지정된 버전(기본 버전은 17)에 따라 미리 설치된 Gradle 버전 중 하나로 자동으로 전환됩니다.

     Java 버전 8 및 11에는 Gradle 6.7.1이 자동 선택되며, Java 17은 Gradle 7.6.4를 사용하고, Java 21은 Gradle 8.8을 사용합니다.

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

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

4. go build의 구현 때문에, Go 빌드 프로세스는 네트워크 접근, go mod download를 통한 미리 로딩된 모드 캐시 또는 벤더된 종속성이 필요합니다. 자세한 내용은 패키지 및 종속성 컴파일에 대한 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

  여러 잠금 파일을 지원합니다.

• Retire.js

  여러 잠금 파일을 지원하지 않습니다. 여러 잠금 파일이 존재하는 경우,
  Retire.js는 디렉토리 트리를 순회하며 알파벳 순으로 탐지된 첫 번째 잠금 파일을 분석합니다.

gemnasium 분석기는 자바스크립트 프로젝트를 위해 vendored 라이브러리(즉, 패키지 관리자가 관리하지 않지만 프로젝트에 체크인된 라이브러리)를 지원합니다.

Go

여러 파일이 지원됩니다. go.mod 파일이 감지되면, 분석기는
빌드 리스트를 생성하기 위해
최소 버전 선택을 사용하려고 합니다.
이것이 실패하면, 분석기는 대신 go.mod 파일 내의 종속성을 구문 분석하려고 합니다.

필수 조건으로, go.mod 파일은 종속성의 적절한 관리를 보장하기 위해
go mod tidy 명령을 사용하여 정리되어야 합니다.
이 과정은 발견된 모든 go.mod 파일에 대해 반복됩니다.

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

이 언어에 대한 분석기는 여러 잠금 파일을 지원합니다.

추가 언어 지원

추가 언어, 종속성 관리자 및 종속성 파일에 대한 지원은 다음 문제에서 추적됩니다:

구성

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

분석기 활성화

전제 조건:

• .gitlab-ci.yml 파일에 test 단계가 필요합니다.
• 자체 관리형 러너에서는 docker
  https://docs.gitlab.com/runner/executors/docker.html 또는
  kubernetes 실행기가 필요합니다.
• GitLab.com에서 SaaS 러너를 사용하는 경우, 기본적으로 활성화되어 있습니다.

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

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

미리 구성된 병합 요청 사용

이 방법은 .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/Dependency-Scanning.gitlab-ci.yml
   

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

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

6. 편집 탭을 선택합니다.

7. 필드를 완료합니다. 브랜치 필드에 기본 브랜치를 사용하지 마세요.

8. 이 변경 사항으로 새 병합 요청 시작 체크박스를 선택한 후, 변경 사항 커밋을 선택합니다.

9. 표준 워크플로에 따라 필드를 완료한 후, 병합 요청 생성을 선택합니다.

10. 표준 워크플로에 따라 병합 요청을 검토하고 수정한 후, 병합을 선택합니다.

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

CI/CD 구성 요소 사용

• GitLab 17.0에서 도입됨. 이 기능은 실험입니다.
• 종속성 스캐닝 CI/CD 구성 요소는 Android 프로젝트만 지원합니다.

CI/CD 구성 요소를 사용하여 애플리케이션의 종속성 스캐닝을 수행하세요. 자세한 지침은 해당 구성 요소의 README 파일을 참조하세요.

사용 가능한 CI/CD 구성 요소

https://gitlab.com/explore/catalog/components/dependency-scanning 참조하세요.

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

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

분석기 동작 사용자 지정

종속성 스캐닝을 사용자 지정하려면 CI/CD 변수를 사용하세요.

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

종속성 스캐닝 작업 오버라이드

작업 정의를 오버라이드하려면(예: 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 인증 기관을 사용하려면 🎉 X.509 PEM 공개 키 인증서의 텍스트 표현을 CI/CD 변수 ADDITIONAL_CA_CERT_BUNDLE에 할당합니다.

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

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

개인 Maven 리포지토리 사용

개인 Maven 리포지토리에 로그인 자격 증명이 필요한 경우,

MAVEN_CLI_OPTS CI/CD 변수를 사용할 수 있습니다.

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

FIPS 지원 이미지

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

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

Gradle 프로젝트에 대한 종속성 스캐닝 및 Yarn 프로젝트에 대한 자동 수정은 FIPS 모드에서 지원되지 않습니다.

FIPS 지원 이미지는 RedHat의 UBI 마이크로를 기반으로 합니다.

이들은 dnf 또는 microdnf와 같은 패키지 관리자를 가지고 있지 않으므로 런타임에 시스템 패키지를 설치할 수 없습니다.

출력

종속성 스캐닝은 다음 출력을 생성합니다:

• 종속성 스캐닝 보고서: 종속성에서 발견된 모든 취약점의 세부 정보를 포함합니다.
• CycloneDX 소프트웨어 자재 명세서: 발견된 각 지원되는 잠금 또는 빌드 파일에 대한 소프트웨어 자재 명세서(SBOM)를 포함합니다.

종속성 스캐닝 보고서

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

종속성 스캐닝 보고서에 대한 더 자세한 내용은 다음을 참조하세요:

• 보안 스캐너 통합.
• 종속성 스캐닝 보고서 스키마.

CycloneDX 소프트웨어 자재 명세서

• GitLab 15.7에서 일반 제공.

종속성 스캐닝은 지원되는 각 잠금 또는 빌드 파일을 감지하여 CycloneDX 소프트웨어 자재 명세서(SBOM)를 출력합니다.

CycloneDX SBOM은 다음과 같습니다:

• gl-sbom-<package-type>-<package-manager>.cdx.json이라는 이름을 가집니다.
• 종속성 스캐닝 작업의 작업 산출물로 제공됩니다.
• 감지된 잠금 또는 빌드 파일과 동일한 디렉토리에 저장됩니다.

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

.
├── 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 병합하기

CI/CD 작업을 사용하여 여러 CycloneDX SBOM을 단일 SBOM으로 병합할 수 있습니다. GitLab은 각 CycloneDX SBOM의 메타데이터에 구현 특정 세부정보를 저장하기 위해 CycloneDX Properties를 사용합니다. 이 정보에는 빌드 및 잠금 파일의 위치가 포함됩니다. 여러 CycloneDX SBOM이 함께 병합되면, 이 정보는 결과적으로 병합된 파일에서 제거됩니다.

예를 들어, 다음 .gitlab-ci.yml 추출은 Cyclone SBOM 파일이 어떻게 병합될 수 있는지와 결과 파일이 검증되는 방법을 보여줍니다.

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.25.1
    entrypoint: [""]
  script:
    - find . -name "gl-sbom-*.cdx.json" -exec cyclonedx merge --output-file gl-sbom-all.cdx.json --input-files "{}" +
    # 선택 사항: 병합된 sbom 검증
    - cyclonedx validate --input-version v1_4 --input-file gl-sbom-all.cdx.json
  artifacts:
    paths:
      - gl-sbom-all.cdx.json

취약점 데이터베이스에 기여하기

취약점을 찾기 위해 GitLab 어드바이저리 데이터베이스를 검색할 수 있습니다.

또한 새로운 취약점 제출도 가능합니다.

오프라인 환경

제한된 인터넷 자원에 접근하는 자가 관리형 GitLab 인스턴스에서 의존성 스캐닝 작업이 성공적으로 실행되도록 하려면 몇 가지 조정이 필요합니다. 자세한 내용은 오프라인 환경을 참조하세요.

요구 사항

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

• docker 또는 kubernetes 실행자를 가진 GitLab Runner
• 의존성 스캐닝 분석기 이미지의 로컬 복사본
• GitLab 어드바이저리 데이터베이스에 대한 접근

분석기 이미지의 로컬 복사본

모든 지원되는 언어 및 프레임워크와 함께 의존성 스캐닝을 사용하려면:

1. 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 이미지를 로컬 오프라인 Docker 레지스트리에 가져오는 과정은 귀하의 네트워크 보안 정책에 따라 다릅니다. IT 직원과 상담하여 외부 자원을 가져오거나 일시적으로 접근할 수 있는 승인된 프로세스를 확인하세요. 이러한 스캐너는 주기적으로 업데이트되어 새로운 정의가 추가되며, 정기적으로 다운로드하는 것이 좋습니다.

2. 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 자문 데이터베이스에 대한 접근

GitLab 자문 데이터베이스는 gemnasium, gemnasium-maven, 및 gemnasium-python 분석기에서 사용하는 취약성 데이터의 출처입니다. 이 분석기의 도커 이미지는 데이터베이스의 복제본을 포함합니다.

복제본은 스캔 시작 전에 데이터베이스와 동기화되어, 분석기가 최신 취약성 데이터를 가질 수 있도록 보장합니다.

오프라인 환경에서는 GitLab 자문 데이터베이스의 기본 호스트에 접근할 수 없습니다.

대신, GitLab 러너가 접근할 수 있는 어딘가에 데이터베이스를 호스팅해야 합니다.

또한, 귀하의 일정에 따라 수동으로 데이터베이스를 업데이트해야 합니다.

데이터베이스 호스팅을 위한 사용 가능한 옵션은 다음과 같습니다:

• GitLab 자문 데이터베이스의 복제본 사용.
• GitLab 자문 데이터베이스의 사본 사용.

GitLab 자문 데이터베이스의 복제본 사용

GitLab 자문 데이터베이스의 복제본을 사용하는 것이 가장 효율적인 방법이기 때문에 권장됩니다.

GitLab 자문 데이터베이스의 복제본을 호스팅하려면:

1. GitLab 러너에서 HTTP를 통해 접근할 수 있는 호스트에 GitLab 자문 데이터베이스를 복제합니다.
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 자문 데이터베이스의 사본 사용

GitLab 자문 데이터베이스의 사본을 사용하는 경우, 분석기가 다운로드하는 아카이브 파일을 호스팅해야 합니다.

GitLab 자문 데이터베이스의 사본을 사용하려면:

1. GitLab 러너에서 HTTP를 통해 접근할 수 있는 호스트에 GitLab 자문 데이터베이스의 아카이브를 다운로드합니다. 아카이브는 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 환경 변수를 읽지 않습니다. 이 상위 문제를 참고하십시오.

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 의존성 스캐너가 프록시를 사용하도록 하려면 settings.xml 파일을 사용하여 구성할 수 있으며, MAVEN_CLI_OPTS CI/CD 변수를 사용하여 Maven에게 이 구성을 사용하도록 지시할 수 있습니다:

variables:
  MAVEN_CLI_OPTS: "--settings mysettings.xml"

언어 및 패키지 관리자를 위한 특정 설정

특정 언어 및 패키지 관리자를 구성하는 방법은 다음 섹션을 참조하세요.

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 프로젝트를 참조하세요.

경고

모든 컨테이너의 최신 버전과 모든 패키지 관리자의 최신 지원 버전을 사용하는 것이 좋습니다. 이전 버전을 사용하는 것은 보안 위험이 증가하는데, 지원되지 않는 버전은 더 이상 능동적인 보안 보고 및 보안 수정의 백포팅 혜택을 받을 수 없습니다.

Gradle 프로젝트

Gradle 프로젝트에 대한 HTML 종속성 보고서를 생성할 때 reports.html.destination 또는 reports.html.outputLocation 속성을 재정의하지 마세요. 이렇게 하면 종속성 스캐닝이 제대로 작동하지 않습니다.

Maven 프로젝트

격리된 네트워크에서는 중앙 리포지토리가 개인 레지스트리인 경우(<mirror> 지시어로 명시적으로 설정된 경우), Maven 빌드가 gemnasium-maven-plugin 종속성을 찾지 못할 수 있습니다. 이 문제는 기본적으로 Maven이 로컬 리포지토리(/root/.m2)를 검색하지 않고 중앙 리포지토리에서 가져오려고 시도하기 때문에 발생합니다. 그 결과, 누락된 종속성에 대한 오류가 발생합니다.

해결 방법

이 문제를 해결하려면 settings.xml 파일에 <pluginRepositories> 섹션을 추가하세요. 이렇게 하면 Maven이 로컬 리포지토리에서 플러그인을 찾을 수 있습니다.

시작하기 전에 다음 사항을 고려하세요:

• 이 해결 방법은 기본 Maven 중앙 리포지토리가 개인 레지스트리에 미러링되는 환경에만 해당됩니다.
• 이 해결 방법을 적용한 후 Maven은 로컬 리포지토리에서 플러그인을 검색하므로 일부 환경에서는 보안에 영향을 줄 수 있습니다. 이 점이 귀하의 조직의 보안 정책과 일치하는지 확인하세요.

settings.xml 파일을 수정하는 방법은 다음과 같습니다:

1. Maven settings.xml 파일을 찾습니다. 이 파일은 일반적으로 다음 위치 중 하나에 있습니다:

   • 루트 사용자에 대한 /root/.m2/settings.xml.
   • 일반 사용자에 대한 ~/.m2/settings.xml.
   • 전역 설정에 대한 ${maven.home}/conf/settings.xml.

2. 파일에 기존 <pluginRepositories> 섹션이 있는지 확인합니다.

3. <pluginRepositories> 섹션이 이미 있는 경우, 그 안에 다음 <pluginRepository> 요소만 추가합니다.

   그렇지 않다면 전체 <pluginRepositories> 섹션을 추가합니다:

     <pluginRepositories>
       <pluginRepository>
           <id>local2</id>
           <name>로컬 리포지토리</name>
           <url>file:///root/.m2/repository/</url>
       </pluginRepository>
     </pluginRepositories>
   

4. Maven 빌드 또는 종속성 스캐닝 프로세스를 다시 실행하세요.

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 분석기는 잘못된 긍정 또는 부정 결과를 초래할 수 있는 가정을 하지 않습니다. 논의에 대한 내용은 문제 442027을 참조하세요.

Swift 프로젝트 빌드

Swift Package Manager (SPM)은 Swift 코드 배포를 관리하기 위한 공식 도구입니다.

Swift 빌드 시스템과 통합되어 종속성을 다운로드, 컴파일 및 링크하는 프로세스를 자동화합니다.

Swift 프로젝트를 SPM으로 빌드할 때 다음 모범 사례를 따르세요.

1. Package.resolved 파일을 포함하세요.

   Package.resolved 파일은 종속성을 특정 버전에 고정합니다.

   항상 이 파일을 저장소에 커밋하여 서로 다른 환경 간의 일관성을 보장하세요.

   git add Package.resolved
   git commit -m "Add Package.resolved to lock dependencies"
   

2. Swift 프로젝트를 빌드하려면 다음 명령어를 사용하세요:

   # 종속성 업데이트
   swift package update
   
   # 프로젝트 빌드
   swift build
   

3. CI/CD를 구성하려면 .gitlab-ci.yml 파일에 다음 단계를 추가하세요:

   swift-build:
     stage: build
     script:
       - swift package update
       - swift build
   

4. 선택 사항. 개인 Swift 패키지 저장소를 사용하고 유효성 검사된 인증서를 사용하는 경우, 인증서를 프로젝트에 추가하고 Swift가 이를 신뢰하도록 구성해야 할 수 있습니다:

   1. 인증서를 가져옵니다:

      echo | openssl s_client -servername your.repo.url -connect your.repo.url:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > repo-cert.crt
      

   2. Swift 패키지 매니페스트(Package.swift)에 다음 줄을 추가하세요:

      import Foundation
      
      #if canImport(Security)
      import Security
      #endif
      
      extension Package {
          public static func addCustomCertificate() {
              guard let certPath = Bundle.module.path(forResource: "repo-cert", ofType: "crt") else {
                  fatalError("Certificate not found")
              }
              SecCertificateAddToSystemStore(SecCertificateCreateWithData(nil, try! Data(contentsOf: URL(fileURLWithPath: certPath)) as CFData)!)
          }
      }
      
      // 패키지를 정의하기 전에 이 함수를 호출하세요
      Package.addCustomCertificate()
      

항상 청정 환경에서 빌드 프로세스를 테스트하여 종속성이 올바르게 지정되고 자동으로 해결되는지 확인하세요.

CocoaPods 프로젝트 빌드

CocoaPods는 Swift 및 Objective-C Cocoa 프로젝트를 위한 인기 있는 종속성 관리자입니다.

iOS, macOS, watchOS 및 tvOS 프로젝트에서 외부 라이브러리를 관리하기 위한 표준 형식을 제공합니다.

CocoaPods를 사용하여 종속성을 관리하는 프로젝트를 빌드할 때 다음 모범 사례를 따르세요.

1. Podfile.lock 파일을 포함하세요.

   Podfile.lock 파일은 종속성을 특정 버전에 고정하는 데 중요합니다.

   항상 이 파일을 저장소에 커밋하여 서로 다른 환경 간의 일관성을 보장하세요.

   git add Podfile.lock
   git commit -m "Add Podfile.lock to lock CocoaPods dependencies"
   

2. 다음 방법 중 하나로 프로젝트를 빌드할 수 있습니다:

   • xcodebuild 명령줄 도구:

     # CocoaPods 종속성 설치
     pod install
     
     # 프로젝트 빌드
     xcodebuild -workspace YourWorkspace.xcworkspace -scheme YourScheme build
     

   • Xcode IDE:

     1. Xcode에서 .xcworkspace 파일을 엽니다.

     2. 대상 스킴을 선택합니다.

     3. Product > Build를 선택합니다. ⌘+B를 눌러도 됩니다.

   • iOS 및 Android 앱의 빌드 및 릴리스를 자동화하기 위한 도구인 fastlane:

     1. fastlane를 설치합니다:

        sudo gem install fastlane
        

     2. 프로젝트에서 fastlane을 구성합니다:

        fastlane init
        

     3. fastfile에 레인을 추가합니다:

        lane :build do
          cocoapods
          gym(scheme: "YourScheme")
        end
        

     4. 빌드를 실행합니다:

        fastlane build
        

   • 프로젝트가 CocoaPods와 Carthage를 모두 사용하는 경우, Carthage를 사용하여 종속성을 빌드할 수 있습니다:

     1. CocoaPods 종속성을 포함하는 Cartfile을 만듭니다.

     2. 다음을 실행합니다:

        carthage update --platform iOS
        

3. CI/CD를 구성하여 선호하는 방법에 따라 프로젝트를 빌드하세요.

   예를 들어, xcodebuild를 사용할 때:

   cocoapods-build:
     stage: build
     script:
       - pod install
       - xcodebuild -workspace YourWorkspace.xcworkspace -scheme YourScheme build
   

4. 선택 사항. 개인 CocoaPods 저장소를 사용하는 경우, 프로젝트가 이를 액세스할 수 있도록 구성해야 할 수 있습니다:

   1. 개인 스펙 저장소를 추가합니다:

      pod repo add REPO_NAME SOURCE_URL
      

   2. Podfile에서 소스를 지정합니다:

      source 'https://github.com/CocoaPods/Specs.git'
      source 'SOURCE_URL'
      

5. 선택 사항. 개인 CocoaPods 저장소가 SSL을 사용하는 경우, SSL 인증서가 올바르게 구성되었는지 확인하세요:

   • 유효성 검사된 인증서를 사용하는 경우, 이를 시스템의 신뢰된 인증서에 추가합니다.

     .netrc 파일에서 SSL 구성을 지정할 수도 있습니다:

     machine your.private.repo.url
       login your_username
       password your_password

6. Podfile을 업데이트한 후, pod install을 실행하여 종속성을 설치하고 작업 공간을 업데이트하세요.

Podfile을 업데이트한 후 항상 pod install을 실행하여 모든 종속성이 올바르게 설치되고 작업 공간이 업데이트되도록 하세요.