의존성 목록
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
의존성 목록을 사용하여 프로젝트 또는 그룹의 의존성과 알려진 취약점을 포함한 해당 의존성에 대한 주요 세부 정보를 검토합니다. 개요를 보려면 Project Dependency - Advanced Security Testing을 참조하세요.
히스토리
- GitLab 16.2에서
group_level_dependencies라는 플래그와 함께 그룹에 대한 의존성 목록이 도입되었습니다. 기본적으로 비활성화됩니다. - GitLab 16.4에서 그룹에 대한 의존성 목록이 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
- GitLab 16.5에서 그룹에 대한 의존성 목록이 일반적으로 사용 가능해졌습니다. 기능 플래그
group_level_dependencies가 제거되었습니다.
의존성 목록을 사용하여 프로젝트 또는 그룹의 의존성과 알려진 취약점을 포함한 해당 의존성에 대한 주요 세부 정보를 검토합니다. 이 목록은 기존 및 새로운 발견을 포함하여 프로젝트의 의존성 모음입니다. 이 정보를 소프트웨어 명세서(SBOM 또는 BOM)라고도 합니다.
개요를 보려면 Project Dependency - Advanced Security Testing을 참조하세요.
의존성 목록 설정#
프로젝트의 의존성을 나열하려면 프로젝트의 기본 브랜치에서 의존성 스캔 또는 컨테이너 스캔을 실행합니다.
의존성 목록은 최신 기본 브랜치 파이프라인에서 업로드된
CycloneDX 보고서의 의존성도 표시합니다.
CycloneDX 보고서는 CycloneDX 사양 버전 1.4, 1.5 또는 1.6을 준수해야 합니다.
CycloneDX Web Tool을 사용하여 CycloneDX 보고서를 검증할 수 있습니다.
의존성 목록을 채우는 데 필수는 아니지만, SBOM 문서에는 일부 속성을 제공하고 일부 보안 기능을 활성화하기 위해 GitLab CycloneDX 속성 분류 체계가 포함되어야 하며 이를 준수해야 합니다.
프로젝트 의존성 보기#
히스토리
- GitLab 17.2에서
skip_sbom_occurrences_update_on_pipeline_id_change기능 플래그가 활성화된 경우location필드가 의존성이 마지막으로 감지된 커밋에 더 이상 연결되지 않습니다. 플래그는 기본적으로 비활성화됩니다. - GitLab 17.3에서
location필드는 항상 의존성이 처음 감지된 커밋에 연결됩니다. 기능 플래그skip_sbom_occurrences_update_on_pipeline_id_change가 제거되었습니다. - GitLab 17.11에서
dependency_paths라는 플래그와 함께 의존성 경로 보기 옵션이 도입되었습니다. 기본적으로 비활성화됩니다. - GitLab 18.2에서 의존성 경로 보기 옵션이 일반적으로 사용 가능해졌습니다. 기능 플래그
dependency_paths가 제거되었습니다.
사전 요구사항:
- 프로젝트 또는 그룹의 Developer, Maintainer 또는 Owner 역할.
프로젝트 또는 그룹의 모든 프로젝트 의존성을 보려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
- 왼쪽 사이드바에서 보안 > 의존성 목록을 선택합니다.
- 선택 사항. 전이 의존성이 있는 경우 모든 의존성 경로를 볼 수도 있습니다:
- 프로젝트의 경우 위치 열에서 의존성 경로 보기를 선택합니다.
- 그룹의 경우 위치 열에서 위치를 선택한 다음 의존성 경로 보기를 선택합니다.
각 의존성의 세부 정보가 나열되며 취약점의 심각도(있는 경우)에 따라 내림차순으로 정렬됩니다. 구성요소 이름, 패키저 또는 라이선스별로 목록을 정렬할 수 있습니다.
| 필드 | 설명 |
|---|---|
| 구성요소 | 의존성의 이름과 버전. |
| 패키저 | 의존성을 설치하는 데 사용되는 패키지 관리자. 지원되지 않는 패키지 관리자의 경우 "알 수 없음"으로 표시됩니다. |
| 위치 | 시스템 의존성의 경우 이 필드는 스캔된 이미지를 나열합니다. 애플리케이션 의존성의 경우 이 필드는 의존성을 선언한 프로젝트의 패키저별 잠금 파일에 대한 링크를 보여줍니다. 직접 의존 항목도 표시됩니다. 전이 의존성이 있는 경우 의존성 경로 보기를 선택하면 모든 의존 항목의 전체 경로가 표시됩니다. 전이 의존성은 직접 의존 항목을 조상으로 갖는 간접 의존 항목입니다. |
| 라이선스 (프로젝트만) | 의존성의 소프트웨어 라이선스로 연결됩니다. 의존성에서 감지된 취약점 수가 포함된 경고 배지. |
| 프로젝트 (그룹만) | 의존성이 있는 프로젝트로 연결됩니다. 동일한 의존성이 있는 프로젝트가 여러 개인 경우 이러한 프로젝트의 총 수가 표시됩니다. 이 의존성이 있는 프로젝트로 이동하려면 프로젝트 번호를 선택한 다음 해당 이름을 검색하여 선택합니다. |
의존성 목록 필터링#
히스토리
- GitLab 16.7에서
group_level_dependencies_filtering이라는 플래그와 함께 그룹에 대한 의존성 필터링이 도입되었습니다. 기본적으로 비활성화됩니다. - GitLab 16.10에서 그룹에 대한 의존성 필터링이 일반적으로 사용 가능해졌습니다. 기능 플래그
group_level_dependencies_filtering이 제거되었습니다. - GitLab 17.9에서
project_component_filter플래그와 함께 프로젝트에 대한 의존성 필터링이 도입되었습니다. 기본적으로 활성화됩니다. - GitLab 17.10에서 일반적으로 사용 가능해졌습니다. 기능 플래그
project_component_filter가 제거되었습니다. - GitLab 18.0에서
version_filtering_on_project_level_dependency_list및version_filtering_on_group_level_dependency_list라는 플래그와 함께 프로젝트 및 그룹에 대한 의존성 버전 필터링이 도입되었습니다. 기본적으로 비활성화됩니다. - GitLab 18.1에서 GitLab.com, GitLab Self-Managed 및 GitLab Dedicated에서 의존성 버전 필터링이 활성화되었습니다.
- 기능 플래그
version_filtering_on_project_level_dependency_list및version_filtering_on_group_level_dependency_list가 제거되었습니다.
의존성 목록을 필터링하여 의존성의 하위 집합에만 집중할 수 있습니다. 의존성 목록은 그룹과 프로젝트에서 사용할 수 있습니다.
그룹의 경우 다음으로 필터링할 수 있습니다:
- 프로젝트
- 라이선스
- 구성요소
- 구성요소 버전
프로젝트의 경우 다음으로 필터링할 수 있습니다:
- 구성요소
- 구성요소 버전
구성요소 버전으로 필터링하려면 먼저 정확히 하나의 구성요소로 필터링해야 합니다.
사전 요구사항:
- 프로젝트 또는 그룹의 Developer, Maintainer 또는 Owner 역할.
의존성 목록을 필터링하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
- 왼쪽 사이드바에서 보안 > 의존성 목록을 선택합니다.
- 필터 표시줄을 선택합니다.
- 필터를 선택한 다음 드롭다운 목록에서 하나 이상의 기준을 선택합니다. 드롭다운 목록을 닫으려면 목록 외부를 선택합니다. 필터를 더 추가하려면 이 단계를 반복합니다.
- 선택한 필터를 적용하려면 Enter를 누릅니다.
의존성 목록은 필터에 일치하는 의존성만 표시합니다.
취약점#
히스토리
- GitLab 17.9에서
update_sbom_occurrences_vulnerabilities_on_cvs라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다. - GitLab 17.9에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
- GitLab 18.5에서 의존성 목록이
detected및confirmed상태만 표시하도록 변경이 도입되었습니다.
SBOM 기반 의존성 스캔과 관련된 취약점 지원의 가용성은 기능 플래그로 제어됩니다. 자세한 내용은 기록을 참조하세요.
의존성에 알려진 취약점이 있는 경우 의존성 이름 옆의 화살표 또는 알려진 취약점 수를 나타내는 배지를 선택하여 볼 수 있습니다. 각
취약점에 대해 심각도와 설명이 아래에 표시됩니다. 취약점에 대한 자세한 내용을 보려면
취약점의 설명을 선택합니다. 취약점의 세부 정보 페이지가 열립니다.
의존성 목록은 detected 및 confirmed 상태의 취약점만 표시합니다.
취약점의 상태가 변경되면 SBOM이 포함된 기본 브랜치에서 새 파이프라인이 실행될 때까지
변경 사항이 의존성 목록에 반영되지 않습니다.
의존성 경로#
히스토리
- GitLab 16.9에서
project_level_sbom_occurrences라는 플래그와 함께 CycloneDX SBOM의 의존성 경로 정보가 도입되었습니다. 기본적으로 비활성화됩니다. - GitLab 17.0에서 CycloneDX SBOM의 의존성 경로 정보가 GitLab.com, GitLab Self-Managed 및 GitLab Dedicated에서 활성화되었습니다.
- GitLab 17.4에서 CycloneDX SBOM의 의존성 경로 정보가 일반적으로 사용 가능해졌습니다. 기능 플래그
project_level_sbom_occurrences가 제거되었습니다.
의존성 경로는 나열된 구성요소가 전이적이고 지원되는 패키지 관리자에 속하는 경우 구성요소의 직접 의존 항목을 표시합니다. 의존성 경로는 취약점이 있는 의존성에 대해서만 표시됩니다.
의존성 경로는 다음 패키지 관리자에 대해 지원됩니다:
의존성 경로는 dependency-scanning 구성요소를 사용하는 경우에만 다음 패키지 관리자에 대해 지원됩니다:
라이선스#
의존성 스캔 CI/CD 작업이 구성된 경우 발견된 라이선스가 이 페이지에 표시됩니다.
내보내기#
의존성 목록을 다음 형식으로 내보낼 수 있습니다:
- JSON
- CSV
- CycloneDX 형식(프로젝트만)
사전 요구사항:
- 프로젝트 또는 그룹의 Developer, Maintainer 또는 Owner 역할.
의존성 목록을 내보내려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
- 왼쪽 사이드바에서 보안 > 의존성 목록을 선택합니다.
- 내보내기를 선택한 다음 파일 형식을 선택합니다.
의존성 목록이 이메일 주소로 전송됩니다. 의존성 목록을 다운로드하려면 이메일의 링크를 선택합니다.
문제 해결#
의존성 목록으로 작업할 때 다음 문제가 발생할 수 있습니다.
라이선스가 '알 수 없음'으로 표시됨#
특정 의존성의 라이선스가 몇 가지 가능한 이유로 unknown으로 표시될 수 있습니다. 이 섹션에서는 특정 의존성의 라이선스가 알려진 이유로 unknown으로 표시되는지 확인하는 방법을 설명합니다.
라이선스가 업스트림에서 '알 수 없음'#
업스트림에서 의존성에 지정된 라이선스를 확인합니다:
- C/C++ 패키지의 경우 Conancenter를 확인합니다.
- npm 패키지의 경우 npmjs.com을 확인합니다.
- Python 패키지의 경우 PyPI를 확인합니다.
- NuGet 패키지의 경우 NuGet을 확인합니다.
- Go 패키지의 경우 pkg.go.dev를 확인합니다.
업스트림에서 라이선스가 unknown으로 표시되면 GitLab도 해당 의존성의 라이선스를 unknown으로 표시하는 것이 예상됩니다.
라이선스에 SPDX 라이선스 표현식이 포함됨#
SPDX 라이선스 표현식은 지원되지 않습니다. SPDX 라이선스 표현식이 있는 의존성은 unknown인 라이선스로 표시됩니다. SPDX 라이선스 표현식의 예는 (MIT OR CC0-1.0)입니다. 이슈 336878에서 자세히 읽어보세요.
패키지 메타데이터 DB에 패키지 버전이 없음#
의존성 패키지의 특정 버전이 패키지 메타데이터 데이터베이스에 존재해야 합니다. 그렇지 않으면 해당 의존성의 라이선스가 unknown으로 표시됩니다. Go 모듈에 대한 이슈 440218에서 자세히 읽어보세요.
패키지 이름에 특수 문자가 포함됨#
의존성 패키지 이름에 하이픈(-)이 포함된 경우 라이선스가 unknown으로 표시될 수 있습니다. 패키지가 requirements.txt에 수동으로 추가되거나 pip-compile이 사용될 때 발생할 수 있습니다. 이는 GitLab이 의존성에 대한 정보를 수집할 때 PEP 503의 정규화된 이름 지침에 따라 Python 패키지 이름을 정규화하지 않기 때문에 발생합니다. 이슈 440391에서 자세히 읽어보세요.
