License Compliance

License Compliance

Introduced in 11.0.

如果您使用的是GitLab CI / CD ，则可以使用许可证合规性在项目依赖项中搜索其许可证.

您可以通过在现有的.gitlab-ci.yml文件中，或者隐式使用Auto DevOps提供的 许可证合规性来利用 .

GitLab 检查”许可证合规性”报告，比较源分支机构和目标分支机构之间的许可证，并在合并请求中显示信息. 拒绝许可证将有清晰可见的x红色图标旁边还有哪些需要从你决定新的许可证. 此外，您可以在项目的许可证合规性政策部分中手动允许或拒绝许可证.

注意：如果许可证合规性报告没有可比较的内容，则合并请求区域中将不会显示任何信息. 第一次在.gitlab-ci.yml添加license_scanning作业时就是这种情况. 连续的合并请求将具有可比性，并且许可证合规性报告将正确显示.

如果您是项目或组维护者，则可以单击许可证以选择允许或拒绝.

License approval decision

当 GitLab 检测到拒绝的许可证时，您可以在查看它.

您可以从” 选项卡查看和修改现有策略.

Edit Policy

Use cases

It helps you find what licenses your project uses in its dependencies, and decide for each of then whether to allow it or forbid it. For example, your application is using an external (open source) library whose license is incompatible with yours.

Supported languages and package managers

支持以下语言和程序包管理器.

Note:

不支持 Java 8 和 Gradle 1.x 项目.

以下语言和程序包管理器，这意味着报告的许可证可能不完整或不准确.

要运行许可证合规性扫描作业，您需要具有docker executor 的 GitLab Runner.

Configuration

对于 GitLab 12.8 及更高版本，要启用许可证合规性，您必须包括在 GitLab 安装过程中提供的 . 对于从 11.9 到 12.7 的较旧版本的 GitLab，您必须包括 . 对于 11.9 之前的 GitLab 版本，您可以复制和使用该模板中定义的作业.

注意： GitLab 13.0 删除了License-Management.gitlab-ci.yml模板. 请改用License-Scanning.gitlab-ci.yml .

将以下内容添加到您的.gitlab-ci.yml文件中：

The included template will create a license_scanning job in your CI/CD pipeline and scan your dependencies to find their licenses.

注意：在 GitLab 12.8 之前， license_scanning作业名为license_management . GitLab 13.0 删除了license_management作业，因此建议您迁移到license_scanning作业，并使用新的License-Scanning.gitlab-ci.yml模板.

结果将保存为” 许可证合规性”报告工件 ，您以后可以下载和分析该 . 由于实施限制，我们始终采用最新的许可证合规性工件. 在后台， GitLab 许可证合规性 Docker 映像用于检测语言/框架，进而分析许可证.

可以使用.gitlab-ci.yml的参数通过环境变量来更改许可合规性设置.

Available variables

可以使用环境变量来配置许可证合规性.

Installing custom dependencies

在 11.4 中引入.

license_management映像已经嵌入了许多自动检测脚本，语言和软件包. 但是，几乎不可能涵盖所有项目的所有案例. 这就是为什么有时需要安装额外的程序包，或在项目自动设置中进行额外步骤的原因，例如证书的下载和安装. 为此，可以将LICENSE_MANAGEMENT_SETUP_CMD环境变量与所需的命令一起传递到容器，以在许可证检测之前运行.

如果存在，则此变量将覆盖安装应用程序所有软件包所必需的设置步骤（例如：对于具有Gemfile的项目，设置步骤可以为bundle install ）.

例如：

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. variables:
  5.   LICENSE_MANAGEMENT_SETUP_CMD: sh my-custom-install-script.sh

在此示例中， my-custom-install-script.sh是项目根目录下的 shell 脚本.

Overriding the template

弃用：从 GitLab 13.0 开始，不再支持的使用. 覆盖模板时，必须使用rules .

如果要覆盖作业定义（例如，更改诸如variables或dependencies类的属性），则需要在包含模板之后声明一个license_scanning作业，并在其下指定任何其他键. 例如：

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. license_scanning:
  5.   variables:
  6.     CI_DEBUG_TRACE: "true"

Configuring Maven projects

许可证合规性工具提供了一个MAVEN_CLI_OPTS环境变量，该变量可以保存命令行参数，以传递给在MAVEN_CLI_OPTS执行的mvn install命令. 随意使用它来定制 Maven 执行. 例如：

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. license_scanning:
  5.   variables:
  6.     MAVEN_CLI_OPTS: --debug

mvn install过所有的运行构建生命周期前阶段的install ，包括test . 出于许可证扫描的目的，运行单元测试不是直接必要的，并且会浪费时间，因此可以通过将MAVEN_CLI_OPTS的默认值MAVEN_CLI_OPTS为-DskipTests跳过它. 如果要提供自定义的MAVEN_CLI_OPTS并同时跳过测试，请不要忘记将-DskipTests显式添加到您的选项中. 如果在mvn install期间仍然需要运行测试，则将-DskipTests=false添加到MAVEN_CLI_OPTS .

Using private Maven repos

如果您有需要登录凭据的私有 Maven 存储库，则可以使用环境变量.

阅读更多有关如何使用私有 Maven 仓库的信息 .

您还可以使用MAVEN_CLI_OPTS连接到使用自签名或内部受信任证书的受信任 Maven 存储库. 例如：

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. license_scanning:
  5.   variables:
  6.     MAVEN_CLI_OPTS: -Dmaven.wagon.http.ssl.allowall=true -Dmaven.wagon.http.ssl.ignore.validity.dates=true -Dmaven.wagon.http.ssl.insecure=true

或者，您可以使用 Java 密钥存储来验证 TLS 连接. 有关如何生成密钥存储文件的说明，请参阅《 .

Selecting the version of Python

  • 在 12.0 中引入 .
  • 在 ，Python 3.5 成为默认设置.
  • 在GitLab 12.7 中 ，Python 3.8 成为默认设置.

默认情况下，许可证合规性使用 Python 3.8 和 pip 19.1. 如果您的项目需要 Python 2，则可以通过将LM_PYTHON_VERSION环境变量设置为2来切换到 Python 2.7 和 pip 10.0.

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. license_scanning:
  5.   variables:
  6.     LM_PYTHON_VERSION: 2

您可以使用ADDITIONAL_CA_CERT_BUNDLE 提供自定义根证书来完成 TLS 验证.

要绕过 TLS 验证，可以使用自定义pip.conf文件来配置受信任的主机.

以下gitlab-ci.yml文件使用注入自定义pip.conf ：

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. license_scanning:
  5.   variables:
  6.     PIP_INDEX_URL: 'https://pypi.example.com/simple/'
  7.   before_script:
  8.     - mkdir -p ~/.config/pip/
  9.     - cp pip.conf ~/.config/pip/pip.conf

允许您指定受信任主机的列表：

  1. [global]

Using private Python repos

如果您拥有专用的 Python 存储库，则可以使用PIP_INDEX_URL 环境变量来指定其位置. 也可以提供自定义的pip.conf进行 .

Configuring NPM projects

您可以使用文件配置 NPM 项目.

Using private NPM registries

如果您有私有 NPM 注册表，则可以使用设置来指定其位置.

例如：

Custom root certificates for NPM

您可以使用ADDITIONAL_CA_CERT_BUNDLE 提供自定义根证书来完成 TLS 验证.

要禁用 TLS 验证，您可以提供strict-ssl设置.

例如：

  1. strict-ssl = false

Configuring Yarn projects

您可以使用.yarnrc.yml文件配置 Yarn 项目.

Using private Yarn registries

如果您有专用的 Yarn 注册表，则可以使用npmRegistryServer设置来指定其位置.

例如：

  1. npmRegistryServer: "https://npm.example.com"

Custom root certificates for Yarn

您可以使用ADDITIONAL_CA_CERT_BUNDLE 环境变量提供自定义根证书来完成 TLS 验证.

Configuring Bower projects

您可以使用.bowerrc文件配置 Bower 项目.

Using private Bower registries

如果您有专用的 Bower 注册表，则可以使用registry设置来指定其位置.

例如：

  1. {
  2.   "registry": "https://registry.bower.io"
  3. }

Custom root certificates for Bower

您可以使用ADDITIONAL_CA_CERT_BUNDLE 环境变量或在文件中指定ca设置来提供自定义根证书来完成 TLS 验证.

Using private Bundler registries

如果您有私人的 Bundler 注册表，则可以使用设置来指定其位置.

例如：

  1. source "https://gems.example.com"

Custom root certificates for Bundler

您可以使用ADDITIONAL_CA_CERT_BUNDLE 或在作业定义中指定BUNDLE_SSL_CA_CERT 来提供自定义根证书来完成 TLS 验证.

Configuring Conan projects

您可以通过将.conan目录添加到项目根目录来配置项目. 项目根用作CONAN_USER_HOME .

Consult the documentation for a list of settings that you can apply.

license_scanning作业在Debian 10 Docker 映像中运行. 提供的映像附带了一些构建工具，例如和GCC . 但是，默认情况下不支持所有项目类型. 要安装编译依赖关系所需的其他工具，请使用使用apt软件包管理器安装必要的构建工具. 有关完整列表，请参阅 .

默认的柯南配置将设置为ci_user ，并将CONAN_PASSWORD绑定到以用于正在运行的作业. 如果在.conan/remotes.json文件中指定了 GitLab 遥控器，则这允许 Conan 项目从GitLab 科南存储库中获取软件包.

要覆盖默认凭据，请指定一个与.conan/remotes.json文件中指定的远程名称匹配.

注意：不支持MSBuild项目. license_scanning映像随和MSBuild 一起提供 . 可能需要其他设置才能生成此项目配置的软件包.

Using private Conan registries

默认情况下， 柯南使用 conan-center遥控器. 例如：

  1. {  "remotes":  [  {  "name":  "conan-center",  "url":  "https://conan.bintray.com",  "verify_ssl":  true  }  ]  }

要从备用远程获取依赖项，请在.conan/remotes.json指定该远程. 例如：

  1. {  "remotes":  [  {  "name":  "gitlab",  "url":  "https://gitlab.com/api/v4/packages/conan",  "verify_ssl":  true  }  ]  }

如果需要使用凭据进行身份验证，则可以按照CONAN_LOGIN_USERNAME文档中描述的命名约定配置 .

Custom root certificates for Conan

您可以通过将.conan/cacert.pem文件添加到项目根目录并将设置为.conan/cacert.pem来提供自定义证书.

如果您指定ADDITIONAL_CA_CERT_BUNDLE 环境变量 ，则此变量的 X.509 证书将安装在 Docker 映像的默认信任库中，并且 Conan 配置为将其用作默认CA_CERT_PATH .

Configuring Go projects

要配置基于Go 模块的项目，请在.gitlab-ci.yml的license_scanning作业的部分中指定环境变量 .

如果项目已其模块，则使用vendor目录和mod.sum文件的组合来检测与 Go 模块依赖关系相关的软件许可证.

Using private Go registries

您可以使用和GOPROXY环境变量来控制模块的来源. 另外，您可以使用来供应项目的模块.

Custom root certificates for Go

您可以通过导出环境变量来指定-insecure标志. 例如：

  1. include:
  4. license_scanning:
  5.   variables:
  6.     GOFLAGS: '-insecure'

Using private NuGet registries

如果您拥有私有的 NuGet 注册表，则可以通过将其添加到nuget.config文件的部分中来将其添加为源.

Custom root certificates for NuGet

您可以使用ADDITIONAL_CA_CERT_BUNDLE 提供自定义根证书来完成 TLS 验证.

在 GitLab 12.8 中，引入了license_management作业的新名称. 进行此更改是为了提高扫描目的的清晰度，即扫描并收集项目依赖项中存在的许可证类型. GitLab 13.0 放弃了对license_management支持. 如果您使用自定义设置来实现”许可证合规性”，则需要相应地更新 CI 配置：

  1. 将 CI 模板更改为License-Scanning.gitlab-ci.yml .
  2. 将作业名称更改为license_scanning （如果在.gitlab-ci.yml提到了该.gitlab-ci.yml ）.
  3. 将工件名称更改为license_scanning ，并将文件名称更改为gl-license-scanning-report.json （如果在.gitlab-ci.yml中.gitlab-ci.yml ）.

例如，以下.gitlab-ci.yml ：

  1. include:
  2.   - template: License-Management.gitlab-ci.yml
  4. license_management:
  5.   artifacts:
  6.     reports:
  7.       license_management: gl-license-management-report.json

应更改为：

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. license_scanning:
  5.   artifacts:
  6.     reports:
  7.       license_scanning: gl-license-scanning-report.json

如果您在 GitLab 13.0 或更高版本中使用license_management工件，则”许可证合规性”作业将产生以下错误：

  1. WARNING: Uploading artifacts to coordinator... failed id=:id responseStatus=400 Bad Request status=400 Bad Request token=:sha
  3. FATAL: invalid_argument

如果遇到此错误，请按照本节中的说明进行操作.

Running License Compliance in an offline environment

对于在通过互联网有限，受限或间歇性访问外部资源的环境中进行自我管理的 GitLab 实例，需要进行一些调整才能成功运行许可合规性工作. 有关更多信息，请参阅 .

Requirements for offline License Compliance

要在离线环境中使用许可证合规性，您需要：

  • GitLab 亚军与 .
  • Docker 容器注册表，其中包含许可证合规性分析器映像的本地可用副本.

注意： GitLab Runner 的 ，这意味着即使本地副本可用，Runner 也会尝试从 GitLab 容器注册表中拉取 Docker 映像. 如果您只喜欢使用本地可用的 Docker 映像，则可以在离线环境pull_policy GitLab Runner 的 . 但是，如果不在离线环境中，我们建议将拉取策略设置保持为always ，因为这样可以在 CI / CD 管道中使用更新的扫描仪.

Make GitLab License Compliance analyzer images available inside your Docker registry

要使用所有许可证合规性检查，请将以下默认许可证合规性分析器映像从registry.gitlab.com导入到您的离线本地 Docker 容器注册表中 ：

  1. registry.gitlab.com/gitlab-org/security-products/license-management:latest

将 Docker 映像导入本地脱机 Docker 注册表的过程取决于您的网络安全策略 . 请咨询您的 IT 员工，以找到可以导入或临时访问外部资源的已接受和批准的流程. 请注意，这些扫描程序会使用新定义进行更新 ，因此请考虑您是否能够自己进行定期更新.

有关将 Docker 映像保存和传输为文件的详细信息，请参阅 Docker 有关 ， docker load ， 和docker import的文档.

Set License Compliance CI job variables to use local License Compliance analyzers

将以下配置添加到您的.gitlab-ci.yml文件. 您必须替换image以引用本地 Docker 容器注册表中托管的 License Compliance Docker 映像：

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. license_scanning:
  5.   image:
  6.     name: localhost:5000/analyzers/license-management:latest

现在，”许可证合规性”作业应使用”许可证合规性”分析器的本地副本来扫描您的代码并生成安全报告，而无需访问 Internet.

连接到私有 Bower 注册表 ， ， 私有 Conan 注册表 ， ， 私有 Maven 仓库 ， ， 私有 Python 仓库和 ，可能需要附加配置.

在脱机环境中运行时， 项目策略必须与名称完全匹配（ ）.

Introduced in 12.7.

许可证列表允许您查看项目的许可证以及有关许可证的关键详细信息.

为了使许可证出现在许可证列表下，必须满足以下要求：

  1. 必须为您的项目配置许可证合规性 CI 作业.
  2. 您的项目必须至少使用一种 .

设置完所有内容后，请在项目的侧边栏中导航至” 安全性和合规性”>”许可证合规性” ，您将看到显示的许可证，其中：

  • 名称：许可证名称.
  • Component: The components which have this license.
  • 违反政策：许可证的许可证政策标记为拒绝 .

Policies

in GitLab Ultimate 12.9.

通过” 策略”选项卡，您可以查看项目的软件许可证策略以及每个策略的关联分类.

可以由项目的维护者配置策略.

项目的开发人员可以查看项目中配置的策略.

Enabling License Approvals within a project

in GitLab Ultimate 12.3.

License-Check是一个批准规则，您可以启用它来允许批准人，个人或组批准包含denied许可证的合并请求.

您可以启用License-Check的两种方式之一：

  • 使用区分大小写的名称License-Check创建 .
  • 在项目策略部分中为许可合规创建批准组. 您必须将此批准组的所需批准数量设置为大于零. 在项目中启用该组后，将为所有合并请求启用批准规则.

任何代码更改都会导致重置所需的批准.

许可证报告如下时，需要批准：

  • 包含包含被denied的软件许可证的依赖项.
  • 在管道执行期间未生成.

许可证报告如下时，批准是可选的：

  • 不包含任何违反软件许可证的行为.
  • Contains only new licenses that are allowed or unknown.

Troubleshooting

ERROR -- : asdf: No preset version installed for command

当项目使用的工具的版本与license_scanning Docker 映像中可用的预安装工具的版本不匹配时，会发生此错误. license_scanning作业使用来激活项目所依赖的工具的适当版本. 例如，如果您的项目依赖于特定版本的Node.js或任何其他受支持的工具，则可以通过向项目中添加文件或使用适当的ASDF_<tool>_VERSION环境变量来激活所需的版本，从而指定所需的版本.适当的版本.

例如，以下.tool-versions文件将激活 12.16.3版和Ruby 的 2.6.6版.

  1. nodejs 12.16.3
  2. ruby 2.6.6

下一个示例显示如何通过使用项目的.gitlab-ci.yml文件中定义的环境变量来激活上述工具的相同版本.

  1. include:
  2.   - template: License-Scanning.gitlab-ci.yml
  4. license_scanning:
  5.   variables:
  6.     ASDF_NODEJS_VERSION: '12.16.3'
  7.     ASDF_RUBY_VERSION: '2.6.6'

完整的变量列表可以在找到.

要了解在license_scanning Docker 映像中预安装了哪些工具，请使用以下命令：

要与license_scanning运行时环境进行交互，请使用以下命令：

  1. $ docker run -it --entrypoint='' registry.gitlab.com/gitlab-org/security-products/analyzers/license-finder:3 /bin/bash -l