- 应用范围
- 数据隐私
- 漏洞扫描器维护
- 使用 Auto DevOps 进行安全扫描
- 不使用 Auto DevOps 进行安全扫描
- 安全扫描
- 查看安全扫描信息
- 合并请求中的安全审核
- 使用自定义扫描阶段
- 私有化部署安装选项
- 安全报告验证
- 和漏洞交互
- 安全扫描配置指南
- 自定义安全规则
- 技术支持
应用程序安全
极狐GitLab 可以检查您的应用程序是否存在安全漏洞,包括:
- 越权存取。
- 数据泄露。
- 拒绝服务攻击。
合并请求中包含有关漏洞的统计信息和详细信息。在合并更改之前,提供可操作的信息,使您能够积极主动。
为了帮助管理和解决漏洞的任务,极狐GitLab 提供了一个安全仪表盘,您可以从您的项目或群组访问。有关更多详细信息,请参阅安全仪表盘。
应用范围
极狐GitLab 分析应用程序的各种细节,无论是作为 CI/CD 流水线的一部分还是在计划中的内容。覆盖范围包括:
- 源代码。
- 项目或容器镜像中的依赖项。
- 正在运行的 Web 应用程序中的漏洞。
- 基础设施即代码配置。
每个极狐GitLab 应用程序安全工具都与功能开发工作流程的特定阶段相关。
- Commit
- SAST
- 密钥检测
- IaC 扫描
- 依赖项扫描
- 覆盖率引导的模糊测试
- Build
- 容器扫描
- Test
- API 安全
- DAST
- Deploy
- 运营容器扫描
源码分析
每次代码提交时都会进行源代码分析。合并请求中提供了检测到的漏洞的详细信息。
源代码分析可以:
- 分析源代码的漏洞 - 静态应用程序安全测试 (SAST)。
- 分析 Git 仓库的 secret 历史记录 - 密钥检测。
分析正在运行的 Web 应用程序
每次代码提交时都会对 Web 应用程序进行分析。作为 CI/CD 流水线的一部分,您的应用程序将被构建、部署到测试环境,并接受以下测试:
- 测试已知应用程序向量 - 动态应用程序安全测试 (DAST)。
- 分析已知攻击向量的 API - DAST API。
- 分析 Web API 的未知错误和漏洞 - API fuzzing。
依赖分析
每次代码提交时都会进行依赖分析。您的应用程序的依赖项会根据已知漏洞的数据库进行整理和检查。
依赖分析可以运行:
有关更多详细信息,请参阅依赖扫描与容器扫描对比。
此外,可以定期或有周期地分析运营中的容器镜像的依赖关系是否存在漏洞。
基础设施分析
您的应用程序的基础设施是潜在漏洞的来源。为了帮助防御这种情况,每个合并请求都会进行基础架构分析:
- 定义应用程序部署环境的基础架构即代码 (IaC) 配置文件 - 基础架构即代码 (IaC) 扫描。
数据隐私
为了考虑安全扫描器的数据隐私问题,极狐GitLab 处理源代码并在极狐GitLab Runner 上本地执行分析。没有数据被传输到极狐GitLab 基础设施(服务器和运行器)之外。
我们的扫描器访问互联网也仅仅是为了下载最新的签名、规则和补丁。如果你更喜欢扫描器不访问互联网,请考虑使用离线环境。
漏洞扫描器维护
以下的漏洞扫描器和它们的数据库会进行常规更新:
安全扫描工具 | 漏洞数据库更新 |
---|---|
容器扫描 | 有一个作业每天都会运行,以使用上游扫描器的最新漏洞数据库来构建镜像。GitLab 通过内部告警来监控此作业,并告知工程师团队数据库已经超过 48h 未更新。更多详情,可查阅漏洞数据库更新。 |
依赖项扫描 | 依赖 GitLab Advisory 数据库。依赖于 GitLab 安全公告数据库。它以美国国家漏洞数据库(NVD)、ruby-advisory-db 以及 GitHub 安全公告数据库的数据作为数据源,每天进行更新。 |
动态应用程序安全测试(DAST) | DAST 分析器周期性进行更新。 |
密钥检测 | GitLab 维护检测规则并接受社区贡献。如果相关的更新可用,则检测引擎会每月至少更新一次。 |
静态应用程序安全测试(SAST) | 扫描规则源取决于每一种受支持的编程语言使用了哪种分析器。GitLab 会维护基于 Semgrep 分析器的一个规则集并基于内部研究和用户反馈进行常规更新。对于其他分析器,规则集源来自于开源扫描器。如果相关的更新可用,则每种分析器都会每月至少更新一次。 |
极狐GitLab 使用相同版本的分析器版本中,你不需要更新它们就可以获得最新的漏洞定义。安全工具作为 Docker 镜像发布。启用它们的预定义作业使用根据语义版本控制的主版本标签。每次新版本的工具发布时,这些标签都会被覆盖。
使用 Auto DevOps 进行安全扫描
要启用所有的极狐GitLab 安全扫描工具,并使用默认设置,则启用Auto DevOps:
当你无法直接自定义 Auto DevOps 时,你可以将 Auto DevOps 模板包含在你项目的 .gitlab-ci.yml
文件中。
不使用 Auto DevOps 进行安全扫描
要为所有的极狐GitLab 安全扫描工具启用自定义设置选项,则要将极狐GitLab CI/CD 模板添加到你的 .gitlab-ci.yml
文件中。
要启用静态应用安全测试、依赖扫描和秘密检测,请添加:
include:
- template: Jobs/Dependency-Scanning.gitlab-ci.yml
- template: Jobs/SAST.gitlab-ci.yml
- template: Jobs/Secret-Detection.gitlab-ci.yml
要启用动态应用安全测试(DAST)扫描,请将以下内容添加到你的 .gitlab-ci.yml
中。将 https://staging.example.com
替换为一个 staging 服务器的 Web 地址:
include:
- template: Jobs/DAST.gitlab-ci.yml
variables:
DAST_WEBSITE: https://staging.example.com
覆盖默认的镜像仓库基础地址
默认情况下,极狐GitLab 安全扫描器使用 registry.gitlab.cn/security-products
作为 Docker 镜像的基础地址。你可以通过设置 CI/CD 变量 SECURE_ANALYZERS_PREFIX
来覆盖它。这会影响所有扫描器。
容器扫描 分析器是个例外,它不使用 SECURE_ANALYZERS_PREFIX
变量。要覆盖它的 Docker 镜像,请参阅在离线环境中运行容器扫描。
模板版本
大多数极狐GitLab 应用安全工具具有两个模板版本:
- 稳定(Stable):稳定模板是默认模板。它提供了一个可靠和一致的应用安全体验。你应该为大多数用户和项目使用稳定模板,这些用户和项目需要稳定性以及可预测的 CI/CD 流水线行为。
-
最新(Latest):最新模板是为那些想要访问和测试最新特性的用户准备的。它在模板名称中标识为
latest
。它被认为不稳定,可能包含计划在下一次主要版本中引入的破坏性更改。这个模板允许你尝试新功能和更新,然后再成为稳定版本的一部分。
和合并请求流水线一起使用安全扫描工具
默认情况下,应用程序安全作业被配置为仅针对分支流水线运行。要与合并请求流水线一起使用,必须引用它们的 latest
版本模板。
比如,要同时运行 SAST 和依赖项扫描,使用如下的模板:
include:
- template: Jobs/Dependency-Scanning.latest.gitlab-ci.yml
- template: Jobs/SAST.latest.gitlab-ci.yml
安全扫描
对于在 CI/CD 流水线中运行的安全扫描来说,结果取决于:
- 哪些安全扫描作业在流水线中运行。
- 每个作业的状态。
- 每个作业的输出。
流水线中的安全作业
CI/CD 流水线中运行的安全扫描作业由如下标准来决定:
-
包含的安全扫描模板
安全扫描作业的选择首先由包含哪些模板来决定。模板可以通过 AutoDevOps、扫描执行策略或
.gitlab-ci.yml
配置文件来包含。 -
规则的计算
每个模板定义了规则,这些规则决定了是否运行分析器。
比如,密钥检测模板包括以下规则。该规则表明密钥检测应在分支流水线中运行。在合并请求流水线的情况下,密钥检测不会运行。
rules: - if: $CI_COMMIT_BRANCH
-
分析器逻辑
如果模板的规则决定运行该作业,那么就会在模板中指定的流水线阶段中创建一个作业。但是,每个分析器都有自己的逻辑,决定是否运行分析器本身。
比如,如果依赖扫描在默认深度下没有检测到支持的文件,则不会运行分析器,并且不会输出任何工件。
成功完成后,每个作业都会输出产物。这些产物经过处理,结果在极狐GitLab 中可用。只有在所有作业完成后,结果才会显示,包括手动作业。此外,对于某些功能,只有在流水线在默认分支上运行时,才会显示结果。
作业状态
如果作业能够完成扫描,则作业会通过。 pass 结果不表示它们是否发现漏洞。唯一的例外是覆盖率模糊测试,如果它发现漏洞,则会失败。
如果作业无法完成扫描,则作业会失败。你可以查看流水线日志以获取更多信息。
所有作业默认允许失败。这意味着如果它们失败,它不会使整个流水线失败。
如果要防止漏洞被合并,你应该通过添加合并请求中的安全批准来实现,这将防止未知、高或关键漏洞被合并,而无需特定人员的批准。
我们不建议更改作业 allow_failure
设置,因为这会使整个流水线失败。
作业产物
安全扫描作业可能会生成一个或多个产物。从极狐GitLab 17.0 开始,这些产物被限制为 developer
角色。
由安全分析器生成的安全报告产物包含目标分支上发现的所有发现,无论它们之前是否被发现、被忽略,还是完全新发现(它把所有它发现的都放进去)。
查看安全扫描信息
安全扫描信息会出现在多个位置,并有多种格式:
- 合并请求
- Pipeline 安全选项卡
- 安全仪表板
- 漏洞报告
- 极狐GitLab VS Code Workflow 扩展
合并请求
所有启用的应用程序安全工具的输出都会显示在合并请求小部件中。你可以使用此信息来管理源分支中发现的任何问题的风险。
所有层级
运行安全扫描的合并请求让你知道生成的报告可用。要下载报告,请选择 下载结果,然后选择所需的报告。
安全扫描生成至少一个CI artifacts:reports
类型:
artifacts:reports:api_fuzzing
artifacts:reports:container_scanning
artifacts:reports:coverage_fuzzing
artifacts:reports:dast
artifacts:reports:dependency_scanning
artifacts:reports:sast
artifacts:reports:secret_detection
在免费版本中,极狐GitLab 不会解析上述的报告。结果就是,小部件不会根据安全扫描的结果而改变。
旗舰版
包含安全小部件的合并请求会展示 新的 结果的摘要。新的结果是通过比较合并请求的结果和目标分支上最近完成的流水线(success
、failed
、canceled
或 skipped
)的提交时的发现来确定的。
当从目标分支创建特性分支时,极狐GitLab 会检查该提交对应的最近 10 个流水线,以找到一个包含安全报告的流水线,用于比较逻辑。如果在创建特性分支时,目标分支的最近 10 个已完成的流水线中都未运行过安全扫描,那就没有可供比较的基准。合并请求安全小部件中,来自合并请求检测结果的漏洞将被列为“新出现的”。我们建议你在为开发人员启用特性分支扫描之前,先对“默认”(目标)分支运行一次扫描。
当决定合并请求是否需要审批,且当同时从源和目标分支对比结果时,合并请求安全部件会考虑所有支持的流水线源(基于 CI_PIPELINE_SOURCE
变量)。流水线源 webide
和 parent_pipeline
不受支持。
合并请求安全部件仅展示在生成的 JSON 产物中的一部分漏洞,因为它同时包含新的和既有的漏洞。
从合并请求安全部件中,选择 展开 来打开部件,展示任何新的以及不再被检测(被移除)的漏洞。
对每一种安全报告类型,部件会展示前 25 个新增的和 25 个已修复的漏洞,按照严重程度进行分类。这是通过比较源分支和目标分支流水线中的安全报告来决定的。
比如,使用这些扫描结果来考虑两种流水线:
- 源分支流水线检测到两个漏洞,分别标记为
V1
和V2
。 - 目标分支流水线检测到两个漏洞,分别标记为
V1
和V3
。 -
V2
将在合并请求小部件中显示为“添加”。 -
V3
将在合并请求小部件中显示为“修复”。 -
V1
存在于两个分支中,不会在合并请求小部件中显示。
要查看合并请求源分支上的所有漏洞,请选择 查看完整报告,直接转到最新源分支流水线中的 安全 选项卡。
流水线安全选项卡
流水线安全选项卡能够列举出流水线作业产物中的安全报告中的所有发现。更多信息请参见流水线中的漏洞报告。
安全仪表盘
安全仪表盘显示项目默认分支上的漏洞。数据每 24 小时更新一次。由于任何功能分支引入的新漏洞合并到默认分支后,都会包含在每日数据刷新中,因此漏洞计数更新结果。
更多详情,可查阅安全仪表盘.
漏洞报告
漏洞报告会展示默认分支上最近完成的流水线的结果。每次流水线完成都会更新数据。所有检测到的漏洞都会显示出来,任何在最新扫描中不再检测到的先前漏洞也会显示出来。不再检测到的漏洞可能已被修复或以其他方式删除,因此在适当验证后,可以将其标记为 Resolved
。不再检测到的漏洞会用图标标记,以便过滤和审查。
默认情况下,漏洞报告不会显示 dismissed
或 resolved
状态的漏洞,因此你可以专注于打开的漏洞。你可以更改状态过滤器以查看这些漏洞。
Read more about the Vulnerability report.
GitLab VS Code Workflow 扩展
通过使用GitLab VS Code Workflow 扩展,你现在可以直接在 VS Code 上看到安全漏洞,就像你在合并请求中看到的一样。
合并请求中的安全审核
- 在极狐GitLab 15.0 中移除了漏洞检查功能。
- 在极狐GitLab 16.0 中移除了许可证检查功能。
你可以强制执行合并请求的额外审核,该合并请求将引入以下安全问题:
- 安全漏洞。更多详情,可查阅合并请求审批策略。
使用自定义扫描阶段
当使用在没有 Auto DevOps 中的安全扫描中描述的 CI/CD 模板来启用安全扫描时,扫描作业默认使用预定义的 test
阶段。如果您在 .gitlab-ci.yml
文件中指定自定义阶段而不包含 test
阶段,则会发生错误。
比如,下面的示例尝试使用 unit-tests
阶段:
include:
- template: Jobs/Dependency-Scanning.gitlab-ci.yml
- template: Jobs/SAST.gitlab-ci.yml
- template: Jobs/Secret-Detection.gitlab-ci.yml
stages:
- unit-tests
custom job:
stage: unit-tests
script:
- echo "custom job"
上面的 .gitlab-ci.yml
会引发一个 lint 错误:
Unable to create pipeline
- dependency_scanning job: chosen stage test does not exist; available stages are .pre
- unit-tests
- .post
出现错误是因为安全扫描作业使用的 test
阶段没有在 .gitlab-ci.yml
文件中被声明。要修复此问题,你可以:
-
在你的
.gitlab-ci.yml
文件中添加test
阶段:include: - template: Jobs/Dependency-Scanning.gitlab-ci.yml - template: Jobs/SAST.gitlab-ci.yml - template: Jobs/Secret-Detection.gitlab-ci.yml stages: - test - unit-tests custom job: stage: unit-tests script: - echo "custom job"
-
覆盖每个安全作业中的默认阶段。比如,要使用预定义的
unit-tests
阶段:include: - template: Jobs/Dependency-Scanning.gitlab-ci.yml - template: Jobs/SAST.gitlab-ci.yml - template: Jobs/Secret-Detection.gitlab-ci.yml stages: - unit-tests dependency_scanning: stage: unit-tests sast: stage: unit-tests .secret-analyzer: stage: unit-tests custom job: stage: unit-tests script: - echo "custom job"
关于覆盖安全作业的更多详情,可查阅:
所有的安全扫描工具都定义了它们的阶段,所以这个错误可能发生在所有的工具上。
私有化部署安装选项
对于私有化部署安装,你可以选择在不连接互联网的情况下运行大多数极狐GitLab 安全扫描器。
私有化部署还可以在 OpenShift 中运行的极狐GitLab Runner上运行安全扫描器。
安全报告验证
极狐GitLab 15.0 在漏洞提取前加强了对安全报告产物的验证。此举主要是为了防止漏洞数据被错误地提取到数据库中。极狐GitLab 会根据报告中声明的架构版本对报告进行验证,验证时会参考报告架构。
流水线的 安全 选项卡会列出任何验证失败的报告产物,以及验证错误消息。
验证取决于在安全报告产物中声明的 schema 版本:
- 如果你的安全报告指定了一个受支持的 schema 版本,极狐GitLab 将使用该版本进行验证。
- 如果您的安全报告使用的是已弃用的版本,极狐GitLab 将尝试对该版本进行验证,并在验证结果中添加弃用警告。
- 如果您的安全报告使用的是受支持的 MAJOR-MINOR 版本的报告架构,但 PATCH 版本与任何已发布的版本不匹配,极狐GitLab 将尝试使用最新发布的 PATCH 版本的架构进行验证。
- 比如:安全报告使用版本 14.1.1,但最新发布的版本是 14.1.0。极狐GitLab 将使用 14.1.0 版本的架构进行验证。
- 如果您的安全报告使用不受支持的版本,极狐GitLab 将尝试使用您安装的极狐GitLab 中最早可用的架构版本进行验证,但不会摄取报告。
- 如果您的安全报告未指定 schema 版本,极狐GitLab 将尝试使用极狐GitLab 中最早可用的 schema 版本进行验证。由于
version
属性是必需的,因此在这种情况下验证始终会失败,但可能还会出现其他验证错误。
你可以在源代码中找到支持和启用了的 schema 版本。
和漏洞交互
你可以在多个位置和安全扫描工具中的发现结果进行交互:
对于你可以查看漏洞的更多位置详情,请查阅相应的链接。每个页面都详细介绍了你如何与漏洞进行交互。例如,在大多数情况下,漏洞最初的状态是 detected。
你有选项:
- 修改状态。
- 创建议题。
- 链接到现有议题。
- 如果已知解决方案,请解决漏洞。
安全扫描配置指南
每个极狐GitLab 安全扫描工具都有默认的CI/CD 配置文件,也就是所谓的 模板。
当自定义配置时:
- 包含扫描工具的 CI/CD 模板。不要 复制 模板的内容。
- 为生产环境使用每个模板的稳定版本。稳定版本的变更较少,只有在主要版本之间才会发生破坏性变更。最新版本包含最新的变更,但在次要版本之间可能会有显著的变更。
- 仅在需要时覆盖模板中的值。所有其他值都从模板继承。
强制扫描执行
安全和合规团队必须确保安全扫描:
- 定期对所有项目运行。
- 不能被开发者禁用。
极狐GitLab 提供了两种方式来实现此目的,每一个都有优缺点。
-
当遇到如下情况,推荐合规框架流水线:
- 需要为使用极狐GitLab 模板的任何扫描器强制执行扫描执行,诸如 SAST IaC、DAST、依赖想扫描、API 模糊测试或基于覆盖率的模糊测试。
- 需要为外部扫描器强制执行扫描执行。
- 为自定义作业而不是安全扫描强制执行扫描执行。
-
当遇到如下情况,推荐扫描执行策略:
- 需要为使用 DAST 站点或扫描配置文件的 DAST 强制执行扫描执行。
- 需要为 SAST、SAST IaC、密钥检测、依赖项扫描 或 容器扫描强制执行扫描执行,且项目有特定的变量自定义。要实现这一点,用户必须为每个项目创建一个单独的安全策略。
- 需要定期或按计划执行的扫描。
-
当遇到如下情况,推荐使用任何解决方案:
- 为没有特定变量自定义的容器扫描强制执行扫描执行。
关于两种方案的不同点如下所示:
合规框架流水线 | 扫描执行策略 | |
---|---|---|
灵活性 | 支持在 CI 文件中完成任何事情。 | 仅限于极狐GitLab 显式支持的一些项目。诸如,DAST、SAST、SAST IaC、密钥检测、依赖项目扫描以及容器扫描。 |
易用性 | 需要 CI YAML 知识。 | 遵循 rules 和基于 actions 的 YAML 结构。 |
包含在 CI 流水线中 | 执行合规流水线而不是项目的 .gitlab-ci.yml 文件。要包含项目的 .gitlab-ci.yml 文件,使用 include 语法。定义的变量不允许被包含项目 YAML 文件中定义的变量所覆盖。 |
强制将新作业包含到 CI 流水线中。必须按每个项目进行定制的动态应用安全测试(DAST)作业定义项目级别的站点配置文件和扫描配置文件。为了确保指责分离,当在扫描执行策略中引用这些文件时,它们必须是不可修改的。所有作业都可以作为安全策略本身的一部分进行定制,使用的变量与通常可供 CI 作业使用的变量相同。 |
可计划的 | 在每个项目上通过定时流水线来进行计划。 | 可以通过策略配置本身进行原生计划。 |
指责分离 | 仅有群组所有者可以创建合规框架标签。仅有项目所有者可以将合规框架标签应用到项目。对于合规流水线定义的变更或变更审核能力仅限于能够访问包含合规流水线项目的个体。 | 仅有项目所有者可以定义链接的安全策略项目。对于安全策略的变更和变更审核能力仅限于能够访问安全策略项目的个体。 |
将单个标准应用到多个项目的能力 | 在单个群组内,相同的合规框架标签可以被应用到多个项目中。 | 相同的安全策略项目可以被实例中的多个项目所使用,这些项目不要求位于同一群组内。 |
自定义安全规则
你可以为需要访问应用程序安全功能的安全团队创建一个自定义角色,诸如漏洞管理、安全策略或依赖项。这种方法允许组织遵循最小特权原则,为安全团队成员提供他们需要的权限,而无需将他们提升为群组或项目的开发人员或维护人员。
比如,自定义安全角色可能具有以下权限:
- 名称:自定义安全角色
- 描述:管理漏洞并链接安全策略项目。
- 基本角色:报告者(或任何默认角色)
- 权限:
admin_vulnerability
、read_dependency
、manage_security_policy_link
技术支持
如果您在使用此功能的过程中遇到任何问题,您可以在极狐GitLab 官方论坛上发帖求助,您也可以直接扫描下方二维码咨询专业人员: