GitLab Secure

原文：https://docs.gitlab.com/ee/user/application_security/

GitLab Secure

GitLab 可以检查您的应用程序是否存在安全漏洞，这些漏洞可能导致未经授权的访问，数据泄漏，服务拒绝等. GitLab 在合并请求中报告漏洞，因此您可以在合并之前修复它们. 安全仪表板提供了在项目，管道和组中检测到的漏洞的高级视图. “ 威胁监视”页面提供了应用程序环境的运行时安全性度量. 使用提供的信息，您可以立即开始风险分析和补救.

有关 GitLab 的应用程序安全性的概述，请参阅Security Deep Dive .

Quick start

通过将以下内容添加到.gitlab-ci.yml ，可以快速开始进行依赖项扫描，许可证扫描，静态应用程序安全测试（SAST）和秘密检测.

  1. include:
  2.   - template: Dependency-Scanning.gitlab-ci.yml
  3.   - template: License-Scanning.gitlab-ci.yml
  4.   - template: SAST.gitlab-ci.yml
  5.   - template: Secret-Detection.gitlab-ci.yml

要添加动态应用程序安全测试（DAST）扫描，请将以下内容添加到.gitlab-ci.yml ，并将https://staging.example.com替换为登台服务器的网址：

  1. include:
  2.   - template: DAST.gitlab-ci.yml
  4. variables:
  5.   DAST_WEBSITE: https://staging.example.com

为确保 DAST 扫描程序在将应用程序部署到登台服务器之后运行，请查阅DAST 完整文档 .

要添加容器扫描，请遵循容器扫描文档中列出的步骤.

要进一步配置任何其他扫描仪，请参阅每个扫描仪的文档.

Override the default registry base address

默认情况下，GitLab 安全扫描程序使用registry.gitlab.com/gitlab-org/security-products/analyzers作为 Docker 映像的基址. 您可以通过将变量SECURE_ANALYZERS_PREFIX设置到另一个位置来全局覆盖此位置. 请注意，这会同时影响所有扫描仪.

Security scanning tools

GitLab 使用以下工具来扫描和报告项目中发现的已知漏洞.

安全扫描工具 Description
Container Scanning 扫描 Docker 容器中的已知漏洞.
Dependency List 查看项目的依存关系及其已知漏洞.
Dependency Scanning 分析您的依赖项是否存在已知漏洞.
Dynamic Application Security Testing (DAST) 分析运行中的 Web 应用程序是否存在已知漏洞.
Secret Detection 分析 Git 历史记录以了解泄露的机密.
Security Dashboard 查看所有项目和组中的漏洞.
Static Application Security Testing (SAST) Analyze source code for known vulnerabilities.

Security Scanning with Auto DevOps

启用自动 DevOps 时 ，将使用默认设置配置所有 GitLab 安全扫描工具.

虽然您无法直接自定义 Auto DevOps，但可以在项目的.gitlab-ci.yml文件中包括 Auto DevOps 模板 .

Maintenance and update of the vulnerabilities database

扫描工具和漏洞数据库会定期更新.

安全扫描工具 漏洞数据库更新
Container Scanning 使用clair . 通过运行latest Docker image 标签 ，每个作业都使用最新的clair-db版本. 根据作者的说法， clair-db数据库每天进行更新 .
Dependency Scanning 依赖于bundler-audit （对于 Ruby gems）， retire.js （对于 NPM 软件包）和gemnasium （GitLab 自己的所有库工具）. bundler-audit和retire.js从 GitHub 存储库中获取漏洞数据，因此添加到ruby-advisory-db和retire.js立即可用. 如果有新版本，工具本身每月更新一次. Gemnasium 数据库至少每周更新一次. 请参阅我们当前从发布 CVE 到更新我们产品的时间度量 .
Dynamic Application Security Testing (DAST) 扫描引擎会定期更新. 请参阅基础工具zaproxy的版本 . 扫描规则在扫描运行时下载.
Static Application Security Testing (SAST) Relies exclusively on the tools GitLab wraps. The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools.

当前，您不必更新 GitLab 即可从最新的漏洞定义中受益. 安全工具作为 Docker 映像发布. 供应商的职位定义使他们能够使用根据语义版本控制的主要发行标签. 工具的每个新版本都会覆盖这些标签. Docker 映像已更新为与以前的 GitLab 版本匹配，因此用户无需执行任何操作即可自动获取最新版本的扫描工具. 但是，这种方法存在一些已知问题，并且有解决这些问题的计划 .

Interacting with the vulnerabilities

在GitLab Ultimate 10.8 中引入.

合并请求报告或” 安全仪表板”中的每个安全漏洞都是可操作的. 单击一个条目以查看具有多个选项的详细信息：

  • 消除漏洞 ：消除漏洞可在删除线中设置样式.
  • 创建问题 ：创建一个新问题，其标题和说明已预先填充了漏洞报告中的信息. 默认情况下，此类问题是机密的 .
  • 解决方案 ：对于某些漏洞，提供了有关如何修复该漏洞的解决方案.

Interacting with security reports

View details of a DAST vulnerability

DAST 检测到的漏洞在实时 Web 应用程序中发生. 纠正这些类型的漏洞需要特定的信息. DAST 提供了调查和纠正根本原因所需的信息.

要查看 DAST 漏洞的详细信息，请执行以下操作：

  1. 要查看检测到的所有漏洞：

    • 在一个项目中，转到该项目的 安全和合规性页面.
    • 仅在合并请求中，转到合并请求的” 安全性”选项卡.

  2. 单击漏洞的描述. 提供以下详细信息：

    | Field | Description | | —- | —- | | Description | Description of the vulnerability. | | Project | 检测到漏洞的名称空间和项目. | | Method | 用于检测漏洞的 HTTP 方法. | | URL | 检测到漏洞的 URL. | | 请求标题 | 请求的标题. | | 回应状态 | 从应用程序收到的响应状态. | | 响应标题 | 从应用程序收到的响应的标头. | | Evidence | 数据证据证明该漏洞. 通常是请求或响应的摘要，可以用来帮助验证发现是否为漏洞. | | Identifiers | 漏洞的标识符. | | Severity | 漏洞的严重性. | | 扫描仪类型 | 漏洞报告的类型. | | Links | 链接到检测到的漏洞的更多详细信息. | | Solution | 推荐的漏洞解决方案的详细信息（可选）. |

Hide sensitive information in headers

HTTP 请求和响应标头可能包含敏感信息，包括 cookie 和授权凭证. 默认情况下，特定标头的内容在 DAST 漏洞报告中被屏蔽. 您可以指定要屏蔽的所有标题的列表. 有关详细信息，请参阅隐藏敏感信息 .

Dismissing a vulnerability

要消除漏洞，必须将其状态设置为”消除”. 请按照以下步骤操作：

  1. 在”安全仪表板”中选择漏洞.
  2. 从右上方的状态选择器菜单中选择”已关闭” .

您可以通过从同一菜单中选择其他状态来撤消此操作.

Adding a dismissal reason

在GitLab Ultimate 12.0 中引入.

消除漏洞时，提供这样做的理由通常很有帮助. 将漏洞的状态设置为”已撤消”后，将出现一个文本框，供您添加有关撤消的评论. 添加后，您可以对其进行编辑或删除. 随着时间的推移，这使您可以添加和更新漏洞的上下文.

Dismissed vulnerability comment

Dismissing multiple vulnerabilities

在GitLab Ultimate 12.9 中引入.

您可以提供多个可选原因，一次消除多个漏洞. 选中列表中每个漏洞旁边的复选框，将选择该单个漏洞. 或者，您可以通过选择表标题中的复选框来选择列表中的所有漏洞. 取消选中标题中的复选框将取消选择列表中的所有漏洞. 选择了某些漏洞后，表格顶部会显示一个菜单，您可以通过该菜单选择解雇原因. 按下”关闭选定的漏洞”按钮将立即消除所有选定的漏洞，并说明您选择的原因.

Multiple vulnerability dismissal

Creating an issue for a vulnerability

您可以通过从漏洞模式中选择” 创建问题”按钮，或使用组安全性仪表板中漏洞行右侧的”操作”按钮来创建漏洞问题.

这在漏洞来自的项目中创建了一个机密问题 ，并使用从漏洞报告中获取的一些有用信息对其进行了预填充. 创建问题后，您将重定向到该问题，以便您可以对其进行编辑，分配或评论.

返回组安全性仪表板后，该漏洞现在在名称旁边具有一个关联的问题.

Linked issue in the group security dashboard

Solutions for vulnerabilities (auto-remediation)

Introduced in GitLab Ultimate 11.7.

可以通过应用 GitLab 自动生成的解决方案来修复某些漏洞. 支持以下扫描仪：

Manually applying the suggested patch

可以通过应用由 GitLab 自动生成的补丁来修复某些漏洞. 要应用此修复程序：

  1. 单击漏洞.
  2. 下载并查看补丁文件remediation.patch .
  3. 确保本地项目的签出提交与生成补丁的提交相同.
  4. Run git apply remediation.patch.
  5. 验证并将更改提交到您的分支.

Apply patch for dependency scanning

Creating a merge request from a vulnerability

Introduced in GitLab Ultimate 11.9.

在某些情况下，GitLab 允许您创建一个合并请求以自动修复漏洞. 具有解决方案的任何漏洞都可以创建合并请求以自动解决问题.

如果可以使用此操作，则漏洞模式将包含” 创建合并请求”按钮. 单击此按钮创建合并请求，以将解决方案应用于源分支.

Create merge request from vulnerability

Security approvals in merge requests

Introduced in GitLab Ultimate 12.2.

可以将合并请求批准配置为在合并请求引入以下安全问题之一时，需要安全团队成员的批准：

  • 一个安全漏洞
  • 违反软件许可证规定

安全漏洞阈值定义为high ， critical或unknown严重性. Vulnerability-Check批准者组必须批准包含漏洞的合并请求.

当 GitLab 可以评估漏洞的严重性时，等级可以是以下之一：

  • unknown
  • low
  • medium
  • high
  • critical

unknown等级表明基础扫描仪不包含或没有提供严重等级.

Enabling Security Approvals within a project

要启用安全批准，必须使用区分大小写的名称Vulnerability-Check创建项目批准规则 . 该批准组必须设置为所需的批准数量大于零. 您必须具有维护者或所有者权限才能管理批准规则.

  1. 导航到您项目的 设置>常规，然后展开合并请求批准 .
  2. 单击添加批准规则 ，或单击编辑 .
    • 将规则名称添加或更改为Vulnerability-Check （区分大小写）.

Vulnerability Check Approver Rule

将这个组添加到您的项目后，将为所有合并请求启用批准规则.

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

当安全报告：

  • 包含high ， critical或unknown严重性的新漏洞，无论被解雇如何.
  • 在管道执行期间未生成.

在安全报告中，批准是可选的：

  • 不包含任何新漏洞.
  • 仅包含严重程度low或medium新漏洞.

Enabling License Approvals within a project

Introduced in GitLab Ultimate 12.3.

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

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

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

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

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

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

  • 不包含任何违反软件许可证的行为.
  • 仅包含allowed或未知的新许可证.

Working in an offline environment

当未连接到 Internet 时，有时会在脱机，受限连接，局域网（LAN），Intranet 或”气隙”环境中运行大多数 GitLab 安全扫描程序.

阅读如何在离线环境中操作安全扫描仪 .

Using private Maven repos

如果您有需要登录凭据的私有 Apache Maven 存储库，则可以使用MAVEN_CLI_OPTS环境变量来传递用户名和密码. 您可以在项目的设置下进行设置，以免凭据在.gitlab-ci.yml .

如果用户名是myuser并且密码非常verysecret则可以在项目的设置下设置以下变量 ：

Type Key Value
Variable MAVEN_CLI_OPTS --settings mysettings.xml -Drepository.password=verysecret -Drepository.user=myuser 
  1. <!-- mysettings.xml -->
  2. <settings>
  3.     ...
  4.     <servers>
  5.         <server>
  6.             <id>private_server</id>
  7.             <username>${private.username}</username>
  8.             <password>${private.password}</password>
  9.         </server>
  10.     </servers>
  11. </settings>

Outdated security reports

在 GitLab 12.7 中引入 .

当为合并请求生成的安全报告过时时，合并请求会在安全小部件中显示警告消息，并提示您采取适当的措施.

这可能在两种情况下发生：

  1. Your source branch is behind the target branch.
  2. The target branch security report is out of date.

Source branch is behind the target branch

这意味着目标分支和源分支之间的最新公共祖先提交不是目标分支上的最新提交. 到目前为止，这是最常见的情况.

在这种情况下，您必须重新设置基础或合并以合并来自目标分支的更改.

Incorporate target branch changes

Target branch security report is out of date

发生这种情况的原因有很多，包括工作失败或新的咨询. 当合并请求显示安全报告已过期时，必须在目标分支上运行新管道. 您可以按照提供的超链接运行新管道来快速完成此操作.

Run a new pipeline

Troubleshooting

Getting error message sast job: stage parameter should be [some stage name here]

当包括诸如SAST.gitlab-ci.yml的.gitlab-ci.yml模板时，根据您的 GitLab CI / CD 配置，可能会发生以下错误：

  1. Found errors in your .gitlab-ci.yml:
  3. * sast job: stage parameter should be unit-tests

如果未在.gitlab-ci.yml声明包含作业的阶段（名为test ），则会出现此错误. 要解决此问题，您可以：

  • 在.gitlab-ci.yml添加一个test阶段.

  • 更改包含的安全作业的默认阶段. 例如，使用 SpotBugs（SAST）：

    1. include:
    2.   template: SAST.gitlab-ci.yml
    4. spotbugs-sast:
    5.   stage: unit-tests

了解有关覆盖 SAST 作业的更多信息 . 所有安全扫描工具都定义了它们的阶段，因此，所有这些工具都可能发生此错误.

Getting error message sast job: config key may not be used with 'rules': only/except

当包括诸如SAST.gitlab-ci.yml的.gitlab-ci.yml模板时，根据您的 GitLab CI / CD 配置，可能会发生以下错误：

  1. Found errors in your .gitlab-ci.yml:
  3.     jobs:sast config key may not be used with `rules`: only/except

当only使用已弃用的或except语法except 覆盖了包含作业的rules配置时，将出现此错误. 若要解决此问题，您必须：

Learn more on overriding SAST jobs.

Transitioning your only/except syntax to rules

覆盖模板以控制作业执行时， only或except先前实例不再兼容，必须转换为rules语法 .

如果您的替代旨在将作业限制为仅在master运行，则先前的语法类似于：

  1. include:
  2.   - template: SAST.gitlab-ci.yml
  4. # Ensure that the scanning is only executed on master or merge requests
  5. spotbugs-sast:
  6.   only:
  7.     refs:
  8.       - master
  9.       - merge_requests

要将上面的配置转换为新的rules语法，重写将如下编写：

  1. include:
  2.   - template: SAST.gitlab-ci.yml
  4. # Ensure that the scanning is only executed on master or merge requests
  5. spotbugs-sast:
  6.   rules:
  7.     - if: $CI_COMMIT_BRANCH == "master"
  8.     - if: $CI_MERGE_REQUEST_ID

如果您的覆盖旨在限制作业仅在分支而不是标签上运行，则其外观类似于：

  1. include:
  2.   - template: SAST.gitlab-ci.yml
  4. # Ensure that the scanning is not executed on tags
  5. spotbugs-sast:
  6.   except:
  7.     - tags

为了过渡到新的rules语法，重写将被重写为：

  1. include:
  2.   - template: SAST.gitlab-ci.yml
  4. # Ensure that the scanning is not executed on tags
  5. spotbugs-sast:
  6.   rules:
  7.     - if: $CI_COMMIT_TAG == null

Learn more on the usage of rules.

Pin your templates to the deprecated versions

为了确保获得最新支持，我们强烈建议您迁移到rules .

如果您无法立即更新 CI 配置，则有几种解决方法，其中涉及固定到以前的模板版本，例如：

  1.  include:
  2.     remote: 'https://gitlab.com/gitlab-org/gitlab/-/raw/12-10-stable-ee/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml'

此外，我们提供了一个专用项目，其中包含版本控制的旧版模板. 这对于脱机设置或希望使用Auto DevOps 的任何人很有用.

旧版模板项目中提供了说明.