• 지원되는 언어 및 패키지 관리자
• 종속성 감지
  • 분석기
  • 분석기가 종속성 정보를 가져오는 방법
    • 잠금 파일을 직접 구문 분석하여 종속성 정보 가져오기
    • 패키지 관리자를 실행하여 구문 분석 가능한 파일 생성하기
  • Analyzers가 어떻게 트리거되는가
  • 여러 파일이 어떻게 처리되는가
    • 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 Advisory Database에 대한 액세스
    • GitLab Advisory Database의 복제 사용
    • GitLab Advisory Database의 사본 사용
• Gradle 프로젝트에서 프록시 사용하기
• Maven 프로젝트에서 프록시 사용하기
• 언어 및 패키지 관리자별 특정 설정
  • Python (pip)
  • Python (setuptools)
  • Python (Pipenv)
• 경고
  • Gradle 프로젝트
  • Maven 프로젝트
    • 해결책
  • Python 프로젝트
  • 버전 번호 파싱
• Swift 프로젝트 빌드
• CocoaPods 프로젝트 빌드

의존성 스캐닝

의존성 스캐닝은 응용 프로그램의 종속성을 알려진 취약점을 위해 분석합니다. 모든 종속성이 스캔되며, 전이적 종속성이라고도 하는 중첩 종속성도 포함됩니다.

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

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

GitLab은 의존성 스캐닝과 함께 컨테이너 스캐닝을 제공하여 이러한 종속성 유형에 대해 보호할 수 있도록 지원합니다. 가능한 리스크 영역을 최대한 많이 포함하기 위해 모든 보안 스캐너를 사용하도록 권장합니다. 이러한 기능을 비교하려면 의존성 스캐닝과 컨테이너 스캐닝 비교를 참조하세요.

경고: 의존성 스캐닝은 컴파일러 및 해석기의 런타임 설치를 지원하지 않습니다.

• 개요는 의존성 스캐닝을 참조하세요.
• 이 의존성 스캐닝 문서의 대화형 읽기 및 사용 방법 데모는 의존성 스캐닝 튜토리얼 GitLab Application Security part 3의 사용 방법를 참조하세요.
• 다른 대화형 읽기 및 사용 방법 데모는 GitLab Application Security Playlist로 시작하세요를 참조하세요.

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

다음 언어 및 의존성 관리자가 의존성 스캐닝에서 지원됩니다:

1. sbt의 Java 21 LTS는 버전 1.9.7로 제한됩니다. 더 많은 sbt 버전의 지원은 이슈 430335에서 추적할 수 있습니다. [FIPS 모드](https://docs.gitlab.com/ee/development/fips_compliance.html#enable-fips-mode)가 활성화된 경우 지원되지 않습니다.

종속성 감지

의존성 스캐닝은 저장소에 사용된 언어를 자동으로 감지합니다. 감지된 언어와 일치하는 모든 분석기가 실행됩니다. 일반적으로 분석기의 선택을 사용자 정의할 필요가 없습니다. 폐기 또는 제거가 있을 때 조정할 필요를 피하기 위해 최상의 범위를 자동으로 사용하도록 권장합니다. 그러나 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. 이 테스트는 .tool-versions 파일에서 지정된 maven의 기본 버전을 사용합니다.

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

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

     Java 버전 8 및 11의 경우, 자동으로 Gradle 6.7.1이 선택됩니다. Java 17은 Gradle 7.6.4를 사용하며, Java 21은 Gradle 8.8을 사용합니다.

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

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

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

Analyzers가 어떻게 트리거되는가

GitLab은 rules:exists를 사용하여 저장소의 Supported files의 존재로 감지된 언어에 대해 해당 분석기를 시작합니다. 이는 위의 표에서 나타납니다.

현재 감지 논리는 최대 검색 깊이를 두 수준으로 제한합니다. 예를 들어 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, 또는 이러한 조합을 포함하는 대규모 프로젝트의 경우, 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 분석기는 JavaScript 프로젝트의 사양 라이브러리를 스캔합니다 (즉, 프로젝트에 체크인되지만 패키지 매니저로 관리되지 않는 라이브러리).

Go

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

구문 분석되는, ang한 go.mod 파일이 의존성의 적절한 관리를 보장하기 위해 명령어 go mod tidy를 사용하여 정리되어야 합니다. 이 프로세스는 감지된 모든 go.mod 파일에 대해 반복됩니다.

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

해당 언어의 분석기는 여러 락 파일을 지원합니다.

추가 언어 지원

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

구성

취약점이 알려진 의존성을 스캔하도록 의존성 스캐닝 분석기를 활성화하세요. 그런 다음 CI/CD 변수를 사용하여 해당 동작을 조정할 수 있습니다.

분석기 활성화

전제 조건:

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

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

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

사전 구성된 병합 요청 사용

이 방법은 .gitlab-ci.yml 파일에 의존성 스캐닝 템플릿을 포함한 병합 요청을 자동으로 준비합니다. 그 뒤 이 병합 요청을 병합하여 의존성 스캐닝을 활성화합니다.

의존성 스캐닝을 활성화하려면:

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 분석기의 모든 사용자 정의를 테스트하십시오. 이 작업을 수행하지 않을 경우 대량의 거짓 긍정을 포함한 예상치 못한 결과가 발생할 수 있습니다.

의존성 스캔 작업 무시

작업 정의를 무시하려면(예: 변수 또는 의존성과 같은 속성 변경), 무시할 작업의 이름을 같은 이름으로 새 작업으로 선언합니다. 이 새 작업은 템플릿 포함 이후에 배치되고 그 아래에 추가 키를 지정합니다. 예를 들어, 이렇게 하면 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 및 분석기 변수 목록은 아닙니다. 사용할 수 있는 환경 변수와 같은 많은 변수가 있으며 이러한 변수들은 작동합니다. 여기에는 문서화되지 않은 수많은 변수들이 포함되어 있으며, 우리는 많은 것을 알지 못할 수 있습니다.

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

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

참고: Gradle 프로젝트는 추가 변수 설정이 필요합니다.

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

dependency_scanning:
  variables:
    HTTPS_PROXY: $HTTPS_PROXY

우리가 모든 변수를 테스트하지 않았기 때문에 모든 변수가 작동하거나 작동하지 않을 수 있습니다. 작동하지 않는 경우 필요한 경우 기능 요청을 제출하거나 코드 기여를 하는 것을 제안합니다.

사용자 정의 TLS 인증서 기관

의존성 스캐닝은 분석기 컨테이너 이미지에 기본으로 제공되는 것 대신 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 저장소 사용를 참조하십시오.

FIPS 활성화 이미지

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

GitLab은 또한 FIPS 모드가 활성화되어 있는 경우 FIPS 활성화 Red Hat UBI 버전의 Gemnasium 이미지를 제공합니다. FIPS 모드가 GitLab 인스턴스에서 활성화되면 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 병합

여러 개의 CycloneDX SBOM을 하나의 SBOM으로 병합하는 CI/CD 작업을 사용할 수 있습니다. GitLab은 CycloneDX Properties를 사용하여 각 CycloneDX SBOM의 메타데이터에 구현별 세부 정보를 저장하며, 빌드 및 잠금 파일의 위치와 같은 정보가 포함됩니다. 여러 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 "{}" +
    # 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 Advisory Database를 검색할 수 있습니다. 또한 새로운 취약점을 제출할 수 있습니다.

오프라인 환경

인터넷을 통한 외부 리소스에 대한 액세스가 제한적이거나 불안정한 환경에서 self-managed GitLab 인스턴스를 사용하는 경우, 의존성 스캔 작업이 성공적으로 실행되려면 몇 가지 조정이 필요합니다. 자세한 내용은 오프라인 환경을 참조하세요.

요구 사항

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

• docker 또는 kubernetes executor를 사용하는 GitLab Runner
• 의존성 스캔 분석기 이미지의 로컬 사본
• 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 이미지를 로컬 오프라인 Docker 레지스트리로 가져오는 프로세스는 네트워크 보안 정책에 따라 다릅니다. 외부 리소스를 가져오거나 일시적으로 액세스하는 것을 승인하는 수용되고 승인된 프로세스를 찾기 위해 IT 직원에게 문의하세요. 이러한 스캐너들은 주기적으로 업데이트됩니다와 새로운 정의와 함께 제공되며 정기적으로 다운로드할 수 있습니다.

1. 지역 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 Advisory Database에 대한 액세스

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

오프라인 환경에서는 기본적인 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 환경 변수를 읽지 않습니다. 이 업스트림 이슈를 참조하세요.

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이 이 구성을 사용하도록 지시하도록 MAVEN_CLI_OPTS CI/CD 변수를 사용할 수 있습니다(자세한 내용은 Maven 문서를 참조).

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

언어 및 패키지 관리자별 특정 설정

특정 언어 및 패키지 관리자의 구성에 대해 아래 섹션을 참조하세요.

Python (pip)

스캔 작업의 before_script에서 Python 패키지를 설치해야 하는 경우 pip install --user를 사용해야 합니다. --user 플래그는 프로젝트 종속성이 사용자 디렉터리에 설치되도록 합니다. --user 옵션을 전달하지 않으면 패키지가 전역적으로 설치되어 스캔되지 않으며 프로젝트 종속성 목록에 표시되지 않습니다.

Python (setuptools)

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

개인 PyPi 저장소에 self-signed 인증서를 사용하는 경우, 템플릿 .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 프로젝트

공개 네트워크에서 중앙 저장소가 개인 레지스트리로 미러링된 격리된 네트워크에서 Maven 빌드가 gemnasium-maven-plugin 종속성을 찾을 수 없을 수 있습니다. 이 문제는 Maven이 기본적으로 로컬 저장소(/root/.m2)를 검색하지 않고 중앙 저장소에서 가져오기를 시도하기 때문에 발생합니다. 이로 인해 누락된 종속성에 대한 오류가 발생합니다.

해결책

이 문제를 해결하려면 settings.xml 파일에 <pluginRepositories> 섹션을 추가하십시오. 이를 통해 Maven이 로컬 저장소에서 플러그인을 찾을 수 있게 됩니다.

다음 사항을 고려한 후 settings.xml 파일을 수정하세요:

• 이 해결책은 기본 Maven 중앙 저장소가 개인 레지스트리로 미러링된 환경에 대해서만 적용됩니다.
• 이 해결책을 적용한 후 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 프로젝트를 빌드할 때 다음의 Best Practice를 따르세요.

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

   Package.resolved 파일은 종속성을 특정 버전에 고정합니다. 다른 환경에서도 일관성을 유지하기 위해 항상 이 파일을 리포지토리에 커밋하세요.

   git add Package.resolved
   git commit -m "의존성을 고정시키기 위해 Package.resolved 추가"
   

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를 사용하여 의존성을 관리하는 프로젝트를 빌드할 때 다음의 Best Practice를 따르세요.

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

   Podfile.lock 파일은 의존성을 특정 버전에 고정하는 데 중요합니다. 서로 다른 환경에서 일관성을 유지하기 위해 항상 이 파일을 리포지토리에 커밋하세요.

   git add Podfile.lock
   git commit -m "CocoaPods 의존성을 고정시키기 위해 Podfile.lock 추가"
   

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

   • xcodebuild 명령행 도구:

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

   • Xcode IDE:

     1. Xcode에서 .xcworkspace 파일을 열기.
     2. 대상 스킴 선택.
     3. Product > 빌드 선택 또는 ⌘+B 누르기.

   • fastlane, iOS 및 Android 앱을 자동으로 빌드하고 릴리스하는 도구:

     1. fastlane 설치:

        sudo gem install fastlane
        

     2. 프로젝트에서 fastlane 구성:

        fastlane init
        

     3. fastfile에 lane 추가:

        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. 개인 spec 저장소 추가:

      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을 실행하여 모든 종속성이 올바르게 설치되고 워크스페이스가 업데이트되도록 하세요.