Help us learn about your current experience with the documentation. Take the survey.

安全术语表

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

本术语表提供了 GitLab 安全功能相关术语的定义。虽然某些术语在其他地方可能有不同的含义，但这些定义是特定于 GitLab 的。

Analyzer

执行扫描的软件。扫描会分析攻击面以发现漏洞，并生成包含发现的报告。报告遵循安全报告格式。

Analyzer 通过 CI job 集成到 GitLab 中。Analyzer 生成的报告在 job 完成后作为工件发布。GitLab 会处理此报告，使用户能够可视化和管理发现的漏洞。

许多 GitLab Analyzer 遵循使用 Docker 运行包装扫描器的标准方法。例如，镜像 semgrep 是一个包装了扫描器 Semgrep 的 Analyzer。

Attack surface

应用程序中易受攻击的不同位置。安全产品在扫描期间发现并搜索攻击面。每个产品对攻击面的定义不同。例如，SAST 使用文件和行号，而 DAST 使用 URL。

Component

构成软件项目一部分的软件组件。示例包括库、驱动程序、数据以及更多。

Corpus

模糊测试器运行时生成的有意义测试用例的集合。每个有意义的测试用例都会在被测试的程序中产生新的覆盖率。建议重用 corpus 并将其传递给后续运行。

CNA

CVE 编号机构 (CNAs) 是全球各地的组织，经 Mitre Corporation 授权，为其各自范围内的产品或服务中的漏洞分配 CVE。GitLab 是一个 CNA。

CVE

通用漏洞披露 (CVE®) 是公开已知网络安全漏洞的通用标识符列表。该列表由 Mitre Corporation 管理。

CVSS

通用漏洞评分系统 (CVSS) 是一个免费开放的行业标准，用于评估计算机系统安全漏洞的严重性。

CWE

通用弱点枚举 (CWE™) 是一个社区开发的常见软件和硬件弱点类型列表，这些弱点具有安全影响。弱点是软件或硬件实现、代码、设计或架构中的缺陷、故障、错误、漏洞或其他错误。如果未得到解决，弱点可能导致系统、网络或硬件易受攻击。CWE 列表及相关分类分类法可作为一种语言，用于根据 CWE 来识别和描述这些弱点。

Deduplication

当某个类别的流程认为发现项相同，或者它们足够相似以至于需要进行降噪时，只保留一个发现项，而删除其他项。有关去重过程的更多信息。

Dependency graph export

依赖关系图导出列出了项目使用的直接和间接依赖关系以及它们之间的关系。它与锁定文件不同，因为它可能不像 pipdeptree graph导出那样，在安装时被包管理器要求。

Duplicate finding

被多次报告的合法发现项。当不同的扫描器发现相同的发现项，或者单个扫描无意中多次报告相同的发现项时，可能会发生这种情况。

False positive

不存在但被错误报告为存在的发现项。

Finding

由 Analyzer 在项目中识别出的可能存在漏洞的资产。资产包括但不限于源代码、二进制包、容器、依赖项、网络、应用程序和基础设施。

发现项是扫描器在 MR/功能分支中识别的所有潜在漏洞项。只有合并到默认分支后，发现项才会成为vulnerability。

您可以通过两种方式与漏洞发现项进行交互。

  1. 您可以为漏洞发现项打开 issue 或 merge request。
  2. 您可以忽略漏洞发现项。忽略该发现项会使其在默认视图中隐藏。

Grouping

一种灵活且非破坏性的方式，用于在存在多个可能相关但不满足去重条件的发现项时，以组的形式可视化组织漏洞。例如，您可以包含需要一起评估、将通过相同操作修复或来自同一来源的发现项。漏洞的分组行为正在开发中，并在 issue 267588 中跟踪。

Insignificant finding

特定客户不关心的合法发现项。

Known affected component

符合漏洞可利用性要求的组件。例如，packageA@1.0.3 匹配 FAKECVE-2023-0001 的名称、包类型以及受影响版本或版本范围之一。

Location fingerprint

发现项的位置指纹是攻击面上每个位置唯一的文本值。每个安全产品根据其攻击面类型定义此值。例如，SAST 包含文件路径和行号。

Lock file

锁定文件详尽地列出了应用程序的直接和间接依赖关系，以确保包管理器能够重现构建。它也可能是依赖关系图导出，例如 Gemfile.lock 文件，但列出依赖关系不是必需的或保证的。

Package managers and package types

Package managers

包管理器是管理项目依赖关系的系统。

包管理器提供安装新依赖项（也称为"包"）的方法，管理包在文件系统上的存储位置，并提供发布自己包的功能。

Package types

每个包管理器、平台、类型或生态系统都有其自己的约定和协议来识别、定位和提供软件包。

下表是 GitLab 文档和软件工具中引用的一些包管理器和类型的非详尽列表。

包类型 包管理器
gem Bundler
Packagist Composer
Conan Conan
go go
maven Gradle
Maven
sbt
npm npm
yarn
NuGet NuGet
PyPI Setuptools
pip
Pipenv
Poetry

Pipeline Security tab

显示在关联 CI 管道中发现的发现项的页面。

Possibly affected component

可能受漏洞影响的软件组件。例如，在扫描项目以查找已知漏洞时，首先评估组件以查看它们是否匹配名称和包类型。在此阶段，它们可能受到漏洞影响，只有在确认它们属于受影响版本范围后，才会被确认为受影响。

Post-filter

后过滤器有助于减少扫描器结果中的噪音并自动化手动任务。您可以指定基于扫描器结果更新或修改漏洞数据的条件。例如，您可以将发现项标记为可能是误报，并自动解决不再检测到的漏洞。这些不是永久性行动，可以更改。

对自动解决发现项的支持在 epic 7478 中跟踪，对廉价扫描的支持在 issue 349926 中提出。

Pre-filter

在分析发生之前过滤掉目标的不可逆操作。这通常是为了允许用户减少范围和噪音以及加快分析速度。如果需要记录，不应执行此操作，因为我们不存储与跳过/排除的代码或资产相关的任何内容。

示例：DS_EXCLUDED_PATHS 应该"根据提供的路径排除文件和目录。"

Primary identifier

发现项的主要标识符是每个发现项唯一的值。发现项第一个标识符的外部类型和外部 ID 组合创建该值。

一个主要标识符示例是 CVE，用于 Trivy。标识符必须稳定。后续扫描必须为相同的发现项返回相同的值，即使位置略有变化。

Reachability

可达性表示项目中列为依赖关系的组件是否实际在代码库中使用。

Report finding

仅存在于 Analyzer 生成的报告中，尚未持久化到数据库的发现项。当报告发现项导入数据库后，它会成为vulnerability finding。

Scan type (report type)

描述扫描类型。这必须是以下之一：

  • api_fuzzing
  • container_scanning
  • coverage_fuzzing
  • dast
  • dependency_scanning
  • sast
  • secret_detection

随着扫描器的添加，此列表可能会更改。

Scanner

可以扫描漏洞的软件（例如 Trivy）。生成的扫描报告通常不是安全报告格式。

Secure product

一组与应用安全特定区域相关的功能，GitLab 提供一流的支持。

产品包括容器扫描、依赖关系扫描、动态应用程序安全测试 (DAST)、秘密检测、静态应用程序安全测试 (SAST) 和模糊测试。

这些产品通常包含一个或多个 Analyzer。

Secure report format

安全产品在创建 JSON 报告时遵循的标准报告格式。该格式由JSON schema描述。

Security Dashboard

提供项目、组或 GitLab 实例所有漏洞的概览。漏洞仅从项目默认分支上发现的发现项创建。

Seed corpus

作为模糊测试目标的初始输入给出的测试用例集合。这通常会显著加快模糊测试目标的运行速度。这可以是手动创建的测试用例，也可以是模糊测试目标本身从先前运行中自动生成的。

Vendor

维护 Analyzer 的方。因此，供应商负责将扫描器集成到 GitLab 中，并在其演进时保持兼容性。供应商不一定是扫描器的作者或维护者，例如在使用开源核心或 OSS 项目作为解决方案基础的情况下。对于作为 GitLab 发行版或 GitLab 订阅一部分包含的扫描器，供应商列为 GitLab。

Vulnerability

对其环境安全产生负面影响的缺陷。漏洞描述了错误或弱点，不描述错误的位置（参见发现项）。

每个漏洞映射到一个唯一的发现项。

漏洞存在于默认分支中。发现项（参见发现项）是扫描器在 MR/功能分支中识别的所有潜在漏洞项。只有合并到默认分支后，发现项才会成为漏洞。

Vulnerability finding

当报告发现项存储到数据库时，它就成为一个漏洞发现项。

Vulnerability tracking

处理跨扫描匹配发现项的责任，以便可以理解发现项的生命周期。工程师和安全团队使用此信息来决定是否合并代码更改，并查看未解决发现项及其引入时间。

漏洞通过比较位置指纹、主要标识符和报告类型进行跟踪。

Vulnerability occurrence

已弃用，参见发现项。