라이선스 컴플라이언스
라이선스: Ultimate
GitLab CI/CD를 사용하는 경우, 라이선스 컴플라이언스(License Compliance)를 사용하여 라이선스에 대한 프로젝트의 의존성을 검색할 수 있습니다. 그런 다음 각 라이선스의 사용을 허용할지 거부할지를 결정할 수 있습니다. 예를 들어, 애플리케이션이 라이선스와 호환되지 않는 외부(오픈 소스) 라이브러리를 사용하는 경우, 해당 라이선스의 사용을 거부할 수 있습니다.
다음 중 하나를 통해 라이선스 컴플라이언스를 활용할 수 있습니다.
- 기존
.gitlab-ci.yml파일에 라이선스를 스캐닝하는 Job을 포함합니다. (include키워드를 사용하여License-Scanning.gitlab-ci.yml템플릿을 추가) - Auto DevOps에서 제공하는 Auto License Compliance를 암묵적으로 사용합니다.
사용 중인 라이선스를 감지하기 위해 License Compliance는 CI/CD 파이프라인의 일부로 실행되는 License Finder 스캔 도구를 사용 합니다. Job을 활성화하려면 License Finder가 프로젝트 디렉터리에서 호환되는 패키지 정의를 찾아야 합니다. 자세한 내용은 License Finder 문서의 Activation 섹션을 참조하십시오. GitLab은 License Compliance 보고서를 확인하고, 소스 브랜치와 타겟 브랜치 간의 라이선스를 비교하여, Merge Request에 정보를 바로 보여줍니다. 거부된 라이선스는 사용자의 결정이 필요한 새 라이선스와 함께 라이선스 옆에 빨간색 x 아이콘으로 표시됩니다. 또한, 프로젝트의 라이선스 컴플라이언스 섹션에 있는 정책 탭에서 라이선스를 수동으로 허용하거나 거부할 수 있습니다. 거부된 라이선스가 새 커밋에서 감지되면, GitLab은 해당 커밋이 포함된 모든 Merge Request를 차단하고 개발자에게 라이선스를 제거하도록 지시합니다.
라이선스 컴플라이언스 보고서에 비교할 항목이 없으면, Merge Request 영역에 정보가 표시되지 않습니다. 처음으로 .gitlab-ci.yml에 license_scanning Job을 추가하는 경우입니다. 연속적인 Merge Request에는 비교할 대상이 있으며 라이선스 컴플라이언스 보고서가 제대로 표시됩니다.
라이선스를 선택하면 더 많은 정보를 볼 수 있습니다.
GitLab이 거부된 라이선스를 감지하면 라이선스 목록에서 확인할 수 있습니다.
Polices 탭에서 기존 정책을 보고 수정할 수 있습니다.
라이선스 표현식
GitLab은 복합 라이선스에 대한 지원이 제한적 입니다. 라이선스 컴플라이언스는 여러 라이선스를 읽을 수 있지만, 항상 AND 연산자를 사용하여 결합된 것으로 간주합니다. 예를 들어, 의존성에 두 개의 라이선스가 있고 그 중 하나는 허용되고 다른 하나는 프로젝트 정책에 의해 거부되는 경우, GitLab은 복합 라이선스를 거부된 것으로 평가합니다. 이것이 더 안전한 옵션이기 때문입니다. 다른 라이선스 표현식 연산자(예: OR, WITH)를 지원하는 기능은 이 에픽에서 추적됩니다.
지원되는 언어 및 패키지 매니저
다음 언어 및 패키지 매니저가 지원됩니다.
Gradle 1.x 프로젝트는 지원되지 않습니다. Maven의 최소 지원 버전은 3.2.5입니다.
| 언어 | 패키지 매니저 | 비고 |
|---|---|---|
| JavaScript | Bower, npm(7 이전) | |
| Go | Godep (deprecated), go mod | |
| Java | Gradle, Maven | |
| .NET | NuGet | .NET Framework는 Mono 프로젝트를 통해 지원됩니다. 그러나 몇 가지 제한 사항이 있습니다. 스캐너는 Windows 고유의 의존성을 지원하지 않으며 프로젝트에 나열된 의존성의 의존성을 보고하지 않습니다. 또한 스캐너는 항상 모든 의존성에 대해 감지된 라이선스를 unknown로 표시합니다. |
| Python | pip | Python은 requirements.txt 및 Pipfile.lock을 통해 지원됩니다. |
| Ruby | gem |
실험적 지원
다음 언어 및 패키지 관리자가 실험적으로 지원됩니다.
보고된 라이선스가 불완전하거나 정확하지 않을 수 있습니다.
| 언어 | 패키지 매니저 |
|---|---|
| JavaScript | Yan |
| Go | go get, gvt, glide, dep, trash, govendor |
| Erlang | Rebar |
| Objective-C, Swift | Carthage, CocoaPods (v0.39 이하) |
| Elixir | Mix |
| C++/C | Conan |
| Rust | Cargo |
| PHP | Composer |
요구사항
라이선스 컴플라이언스 스캔은 컴파일러 및 인터프리터의 런타임 설치를 지원하지 않습니다.
라이선스 컴플라이언스 스캔 Job을 실행하려면 Docker executor를 사용하는 GitLab Runner가 필요합니다.
구성
GitLab 12.8 이상의 경우, 라이선스 컴플라이언스를 활성화하려면 GitLab 설치의 일부로 제공되는 License-Scanning.gitlab-ci.yml 템플릿을 include 해야 합니다. 11.9에서 12.7까지의 GitLab 이전 버전의 경우 License-Management.gitlab-ci.yml 템플릿을 include 해야 합니다. GitLab 11.9 이전 버전의 경우, 해당 템플릿에 정의된 대로 Job을 복사하여 사용할 수 있습니다.
.gitlab-ci.yml 파일에 다음을 추가합니다.
include:
- template: Security/License-Scanning.gitlab-ci.yml
include된 템플릿은 CI/CD 파이프라인에 license_scanning Job을 생성하고 의존성을 스캔하여 라이선스를 찾습니다.
GitLab 12.8 이전에는 license_scanning Job 이름이 license_management이었습니다. GitLab 13.0에서 license_management Job이 제거되었으므로 license_scanning Job으로 마이그레이션하고 새로운 License-Scanning.gitlab-ci.yml 템플릿을 사용해야 합니다.
결과는 나중에 다운로드하고 분석할 수 있는 라이선스 컴플라이언스 리포트 아티팩트로 저장됩니다. 구현 제한으로 인해 항상 사용 가능한 최신 라이선스 컴플라이언스 아티팩트를 사용합니다. 이면에서는 GitLab License Compliance Docker 이미지를 사용하여 언어/프레임워크를 감지하고 라이선스를 분석합니다.
라이선스 컴플라이언스 설정은 .gitlab-ci.yml의 variables 파라미터를 사용하여 CI/CD 변수를 통해 변경할 수 있습니다.
라이선스 컴플라이언스 실행 시
GitLab License-Scanning.gitlab-ci.yml 템플릿을 사용할 때, 라이선스 컴플라이언스 Job은 다른 단계(stage)가 완료될 때까지 기다리지 않습니다.
사용 가능한 CI/CD 변수
라이선스 컴플라이언스는 CI/CD 변수를 사용하여 구성할 수 있습니다.
| CI/CD 변수 | 필수 여부 | 설명 |
|---|---|---|
ADDITIONAL_CA_CERT_BUNDLE | 아니요 | 신뢰할 수 있는 CA 인증서 번들 (현재 Pip, Pipenv, Maven, Gradle, Yarn 및 npm 프로젝트에서 지원됨) |
ASDF_JAVA_VERSION | 아니요 | 스캔에 사용할 Java 버전 |
ASDF_NODEJS_VERSION | 아니요 | 스캔에 사용할 Node.js 버전 |
ASDF_PYTHON_VERSION | 아니요 | 스캔에 사용할 Python 버전 |
ASDF_RUBY_VERSION | 아니요 | 스캔에 사용할 Ruby 버전 |
GRADLE_CLI_OPTS | 아니요 | Gradle Executable에 대한 추가 인수. 제공하지 않으면, 기본값은 --exclude-task=test |
LICENSE_FINDER_CLI_OPTS | 아니요 | license_finder Executable에 대한 추가 인수. 예를 들어, 중첩된 디렉토리에 여러 프로젝트가 있는 경우 .gitlab-ci.yml 템플릿을 업데이트하여 LICENSE_FINDER_CLI_OPTS: '--recursive'와 같은 재귀 스캔을 지정할 수 있습니다. |
LM_JAVA_VERSION | 아니요 | Java 버전. 11로 설정하면 Maven 및 Gradle은 Java 8 대신 Java 11을 사용합니다. |
LM_PYTHON_VERSION | 아니요 | Python 버전. 3로 설정하면 Python 2.7 대신 Python 3을 사용하여 의존성이 설치됩니다. |
MAVEN_CLI_OPTS | 아니요 | mvn Executable에 대한 추가 인수. 제공하지 않으면 기본값은 -DskipTests |
PIP_INDEX_URL | 아니요 | Python 패키지 인덱스의 기본 URL (기본값 : https://pypi.org/simple/) |
SECURE_ANALYZERS_PREFIX | 아니요 | Analyzer를 다운로드할 Docker Registry의 베이스 주소를 설정 |
SETUP_CMD | 아니요 | 의존성 설치를 위한 사용자 지정 설정 (시험적) |
사용자 정의 의존성 설치
license_finder 이미지에는 이미 많은 자동 감지 스크립트, 언어 및 패키지가 포함되어 있습니다. 그렇기는 하지만 모든 프로젝트의 모든 사례를 다루는 것은 거의 불가능합니다. 그렇기 때문에 때때로 추가 패키지를 설치하거나 인증서 다운로드 및 설치와 같은 프로젝트 자동화 설정에 추가 단계가 필요합니다. 이를 위해 SETUP_CMD CI/CD 변수는 라이선스 감지 전에 실행해야 하는 필수 명령과 함께 컨테이너에 전달할 수 있습니다.
이 변수가 있으면 애플리케이션의 모든 패키지를 설치하는 데 필요한 설정 단계를 재정의합니다. (예 : Gemfile가 있는 프로젝트의 경우, 설정 단계는 bundle install가 될 수 있음)
예를 들어 :
include:
- template: Security/License-Scanning.gitlab-ci.yml
variables:
SETUP_CMD: sh my-custom-install-script.sh
이 예에서 my-custom-install-script.sh는 프로젝트의 루트 디렉토리에 있는 셸 스크립트입니다.
Monorepo 관련 작업
언어에 따라 LICENSE_FINDER_CLI_OPTS 변수를 사용하여 모노레포(여러 개의 프로젝트를 하나의 리포지터리에 저장하는 방식)의 개별 프로젝트에 대한 경로를 지정해야 할 수도 있습니다. 프로젝트 경로를 전달하면 --recursive license_finder 옵션을 사용하는 것보다 빌드 속도가 훨씬 빨라질 수 있습니다.
include:
- template: Security/License-Scanning.gitlab-ci.yml
variables:
LICENSE_FINDER_CLI_OPTS: '--aggregate_paths=relative-path/to/sub-project/one relative-path/to/sub-project/two'
템플릿 재정의
GitLab 13.0부터 only 및 except 사용은 더 이상 지원되지 않습니다. 템플릿을 재정의할 때 대신 rules를 사용해야 합니다.
Job 정의(예 : variables 또는 dependencies 같은 속성 변경)를 재정의하려면, 템플릿 include 한 후 license_scanning Job을 선언하고 그 아래에 추가 키를 지정해야 합니다.
예를 들어 :
include:
- template: Security/License-Scanning.gitlab-ci.yml
license_scanning:
variables:
CI_DEBUG_TRACE: 'true'
라이선스 목록
라이선스 목록을 통해 프로젝트의 라이선스 및 라이선스에 대한 주요 세부 정보를 볼 수 있습니다.
라이선스 목록에 라이선스가 표시되려면 다음 요구 사항이 충족되어야 합니다.
- 라이선스 컴플라이언스 CI Job이 프로젝트에 구성되어야 합니다.
- 프로젝트는 지원되는 언어 및 패키지 매니저를 하나 이상 사용해야 합니다.
모든 설정이 완료되면, 왼쪽 사이드바에서 Security & Compliance > License Compliance를 선택합니다.
라이선스 목록에 다음 항목이 표시됩니다.
- Name : 라이선스 의 이름
- Component : 이 라이선스가 있는 컴포넌트
- Policy Violation : 라이선스에 Deny로 표시된 라이선스 정책이 있습니다.
정책
정책을 사용하면 프로젝트에서 allowed 또는 denied 되는 라이선스를 지정할 수 있습니다. denied 라이선스가 새로 커밋되면 Merge Request를 차단하고 개발자에게 제거하도록 지시합니다. Merge Request는 denied 라이선스가 제거될 때까지 Merge할 수 없습니다. License-Check 승인 규칙을 추가하면, 지정된 승인자가 denied 라이선스가 포함된 Merge Request를 승인한 다음 머지할 수 있습니다.
프로젝트의 License Compliance 섹션에 있는 Policies 탭에는 프로젝트의 라이선스 정책이 표시됩니다. 프로젝트 Maintainer 권한이 있는 사용자는 이 섹션에서 정책을 지정할 수 있습니다.
프로젝트 Developer 권한이 있는 사용자는 프로젝트에 구성된 정책을 볼 수 있습니다.
프로젝트 내에서 라이선스 승인 활성화
전제 조건 :
- Maintainer 또는 Owner 권한
License-Check는 개인 또는 그룹이 denied 라이선스가 포함된 Merge Request를 승인하도록 허용할 수 있는 Merge Request 승인 규칙입니다.
다음 두 가지 방법 중 하나로 License-Check를 활성화할 수 있습니다.
- 상단 바에서 Menu > Projects로 이동하여 프로젝트를 찾습니다.
- 왼쪽 사이드 바에서 Settings > General을 선택합니다.
- Merge request approvals을 확장합니다.
- Enable 또는 Edit을 선택합니다.
- Rule name 필드에
License-Check(대소문자 구분)를 추가하거나 변경합니다.
- 라이선스 컴플라이언스에 대한 프로젝트 정책 섹션에서 승인 그룹을 생성합니다. 이 승인 그룹의 필요한 승인 수를 0보다 크게 설정해야 합니다. 프로젝트에서 이 그룹을 활성화하면 모든 Merge Request에 대해 승인 규칙이 활성화됩니다.
코드가 변경되면 승인이 재설정되어야 합니다.
라이선스 보고 시 다음과 같은 경우에는 승인이 필요합니다.
denied소프트웨어 라이선스를 가지는 의존성을 포함하는 경우- 파이프라인 실행 중에 생성된 라이선스가 아닌 경우
라이선스 보고 시 다음과 같은 경우에 승인은 선택 사항입니다.
- 소프트웨어 라이선스 위반이 포함되어 있지 않은 경우
allowed또는unknown인 새로운 라이선스만 포함하는 경우
주의사항
모든 컨테이너의 최신 버전과 지원되는 모든 패키지 매니저 및 언어의 최신 버전을 사용하는 것이 좋습니다. 이전 버전을 사용하면 지원되지 않는 버전이 활성 보안 보고 및 보안 수정 사항의 백포팅의 이점을 더 이상 얻을 수 없기 때문에 보안 위험이 증가합니다.
GitLab 원문 보기⚠️ 사전 동의 없이 2차 가공 및 영리적인 이용을 금하며, 온·오프라인에 무단 전재 또는 유포할 수 없습니다.