格赖佩
0.83.0
针对容器镜像和文件系统的漏洞扫描器。轻松安装二进制文件来试用。与 Syft 配合使用，Syft 是用于容器映像和文件系统的强大 SBOM（软件物料清单）工具。
日历：https://calendar.google.com/calendar/u/0/r?cid=Y182OTM4dGt0MjRtajI0NnNzOThiaGtnM29qNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t
议程：https://docs.google.com/document/d/1ZtSAa6fj2a6KRWviTn3WoJm09edvrNUp4Iz_dOjjyY8/edit?usp=sharing（加入此群组以获得写入权限）
欢迎大家！
如需 Syft 或 Grype 的商业支持选项，请联系 Anchore
扫描容器映像或文件系统的内容以查找已知漏洞。
查找主要操作系统软件包的漏洞：
阿尔卑斯山
亚马逊Linux
忙碌盒
中央操作系统
CBL-水手
德班
无发行版
甲骨文Linux
红帽 (RHEL)
乌班图
沃尔菲
查找特定语言包的漏洞：
红宝石（宝石）
Java（JAR、WAR、EAR、JPI、HPI）
JavaScript（NPM、纱线）
Python（Egg、Wheel、Poetry、requirements.txt/setup.py 文件）
点网 (deps.json)
Go 语言 (go.mod)
PHP（作曲家）
铁锈（货物）
支持 Docker、OCI 和 Singularity 镜像格式。
OpenVEX 支持过滤和增强扫描结果。
如果您遇到问题，请使用问题跟踪器告知我们。
卷曲-sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
安装脚本选项：
-b ：指定自定义安装目录（默认为./bin ）
-d ：更详细的日志记录级别（ -d用于调试， -dd用于跟踪）
-v ：安装前验证下载的工件的签名（需要安装cosign ）
grrype 的巧克力分发是社区维护的，而不是由anchore 团队分发的。
choco 安装 grype -y
酿造龙头锚 酿造安装 grype
在 macOS 上，还可以通过 MacPorts 从社区维护的端口安装 Grype：
sudo 端口安装 grype
注意：目前，Grype 仅适用于 macOS 和 Linux。
有关从源代码构建和运行的说明，请参阅 DEVELOPING.md。
如果您使用 GitHub Actions，则可以在 CI 工作流程期间使用我们基于 Grype 的操作对您的代码或容器映像运行漏洞扫描。
校验和应用于所有工件，并使用 cosign 对生成的校验和文件进行签名。
您需要以下工具来验证签名：
联合签名
验证步骤如下：
从发布页面下载所需的文件以及 checksums.txt、checksums.txt.pem 和 checksums.txt.sig 文件：
验证签名：
cosign verify-blob--certificate --signature --certificate-identity-regexp 'https://github.com/anchore/grype/.github/workflows/.+' --certificate-oidc-issuer“https://token.actions.githubusercontent.com”
确认签名有效后，您可以继续验证 SHA256 总和是否与下载的工件一致：
sha256sum --ignore-missing -c checksums.txt
安装二进制文件，并确保grype在您的路径中可用。要扫描图像中的漏洞：
grype
上述命令扫描容器中可见的漏洞（即图像的压缩表示）。要将来自所有映像层的软件包含在漏洞扫描中，无论其是否存在于最终映像中，请提供--scope all-layers ：
grype--scope all-layers
要从 Docker 容器运行 grype 以便扫描正在运行的容器，请使用以下命令：
docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock --name Grypeanche/grype:latest$(ImageName):$(ImageTag)
Grype 可以扫描 Docker 之外的各种源。
# scan a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands) grype path/to/image.tar # scan a Singularity Image Format (SIF) container grype path/to/image.sif # scan a directory grype dir:path/to/dir
可以通过方案明确提供源：
podman:yourrepo/yourimage:tag use images from the Podman daemon docker:yourrepo/yourimage:tag use images from the Docker daemon docker-archive:path/to/yourimage.tar use a tarball from disk for archives created from "docker save" oci-archive:path/to/yourimage.tar use a tarball from disk for OCI archives (from Skopeo or otherwise) oci-dir:path/to/yourimage read directly from a path on disk for OCI layout directories (from Skopeo or otherwise) singularity:path/to/yourimage.sif read directly from a Singularity Image Format (SIF) container on disk dir:path/to/yourproject read directly from a path on disk (any directory) file:path/to/yourfile read directly from a file on disk sbom:path/to/syft.json read Syft JSON from path on disk registry:yourrepo/yourimage:tag pull image directly from a registry (no container runtime required)
如果未提供图像源并且无法从给定的引用中检测到图像源，则假定应从 Docker 守护程序中提取图像。如果 docker 不存在，则接下来尝试使用 Podman 守护进程，最后直接访问镜像注册表。
可以使用default-image-pull-source配置选项覆盖此默认行为（有关更多详细信息，请参阅配置）。
使用 SBOM 在 Grype 中进行更快的漏洞扫描：
# Then scan for new vulnerabilities as frequently as needed grype sbom:./sbom.json # (You can also pipe the SBOM into Grype) cat ./sbom.json | grype
Grype 支持 Syft、SPDX 和 CycloneDX SBOM 格式的输入。如果 Syft 生成了任何这些文件类型，它们应该具有适当的信息以便与 Grype 正常工作。还可以使用其他工具生成的 SBOM，并取得不同程度的成功。使 Grype 匹配更加成功的两件事是包含 CPE 和 Linux 发行版信息。如果 SBOM 不包含任何 CPE 信息，则可以使用--add-cpes-if-none标志根据包信息生成这些信息。要指定发行版，请使用--distro 标志。一个完整的例子是：
grype --add-cpes-if-none --distro alpine:3.10 sbom:some-alpine-3.10.spdx.json
不支持 v0.40.1 之前的任何 Grype 版本。不受支持的版本将不会收到任何软件更新或漏洞数据库更新。您仍然可以使用以前版本的 vunnel 来收集上游数据，并使用 grype-db 为不受支持的架构构建数据库，从而为不受支持的 Grype 版本构建漏洞数据库。
Grype 支持通过 stdin 扫描 SBOM 作为输入。用户可以使用 cosign 来验证以 SBOM 作为其内容的证明，以扫描图像是否存在漏洞：
COSIGN_EXPERIMENTAL=1 cosign verify-attestation caphill4/java-spdx-tools:latest | jq -r .payload | base64 --decode | jq -r .predicate.Data | grype
{“漏洞”：{ ...
}, "相关漏洞": [ ...
], "比赛详情": [ ...
]， “人工制品”： { ...
}
}漏洞：有关直接匹配的特定漏洞的所有信息（例如 ID、严重性、CVSS 评分、修复信息、更多信息的链接）
相关漏洞：与已发现的与主要报告的漏洞相关的漏洞的信息。也许我们匹配的漏洞是一个 GitHub 安全公告，它有一个上游 CVE（在权威的国家漏洞数据库中）。在这些情况下，我们在此处列出了上游漏洞。
MatchDetails ：本节试图解释我们在寻找匹配项时搜索的内容以及导致匹配的包和漏洞的详细信息。
Artifact ：这是我们所了解的有关包的信息的子集（与 Syft json 输出相比，我们总结了元数据部分）。其中包含有关我们在容器映像或目录中找到包的位置、包的类型、许可信息、pURL、CPE 等的信息。
Grype 可以通过使用带有一个或多个--exclude参数的 glob 表达式来排除源中扫描的文件和路径：
grype--exclude './out/**/*.json' --exclude /etc
注意：在图像扫描的情况下，由于扫描整个文件系统，因此可以使用绝对路径，例如/etc或/usr/**/*.txt而目录扫描则排除相对于指定目录的文件。例如：使用--exclude ./package.json扫描/usr/foo将排除/usr/foo/package.json ，而--exclude '**/package.json'将排除/usr/foo下的所有package.json文件/usr/foo 。对于目录扫描，需要以./或**/开始路径表达式，所有这些都将相对于指定的扫描目录*/解析。请记住，您的 shell 可能会尝试扩展通配符，因此请将这些参数放在单引号中，例如： '**/*.json' 。
Grype 可以配置为合并外部数据源，以提高漏洞匹配的保真度。目前此功能默认处于禁用状态。要启用此功能，请将以下内容添加到 grype 配置中：
外部源：启用：true maven：search-upstream-by-sha1：true 基本网址：https://repo1.maven.org/maven2
如果您使用另一个注册表作为 Maven 端点，您还可以配置 base-url。
Grype 的输出格式也是可配置的：
grype-o
可用的格式有：
table ：柱状摘要（默认）。
cyclonedx ：符合 CycloneDX 1.6 规范的 XML 报告。
cyclonedx-json ：符合 CycloneDX 1.6 规范的 JSON 报告。
json ：使用它从 Grype 获取尽可能多的信息！
sarif ：使用此选项获取 SARIF 报告（静态分析结果交换格式）
template ：让用户指定输出格式。请参阅下面的“使用模板”。
Grype 允许您使用 Go 模板定义自定义输出格式。它的工作原理如下：
将您的格式定义为 Go 模板，并将该模板保存为文件。
将输出格式设置为“模板”( -o template )。
指定模板文件的路径 ( -t ./path/to/custom.template )。
Grype 的模板处理使用与json输出格式相同的数据模型 - 因此，如果您想知道在创作模板时有哪些数据可用，您可以使用grype 的输出作为参考。
请注意：模板可以访问有关其运行的系统的信息，例如环境变量。您永远不应该运行不受信任的模板。
Grype 源的 templates 目录中有几个示例模板，可以作为自定义输出格式的起点。例如，csv.tmpl 生成 CSV（逗号分隔值）格式的漏洞报告：
"Package","Version Installed","Vulnerability ID","Severity"
"coreutils","8.30-3ubuntu2","CVE-2016-2781","Low"
"libc-bin","2.31-0ubuntu9","CVE-2016-10228","Negligible"
"libc-bin","2.31-0ubuntu9","CVE-2020-6096","Low"
...您还可以在同一位置找到默认“表”输出格式的模板。
除了默认的 golang 文本/模板之外，Grype 还包括来自 sprig 的大量实用模板函数，以允许用户自定义 Grype 的输出。
如果报告的任何漏洞达到或高于指定的严重性级别，您可以让 Grype 退出并返回错误。在脚本或 CI 管道中使用 Grype 时，这会派上用场。为此，请使用--fail-on CLI 标志。
例如，如果在ubuntu:latest映像中发现任何严重性为“中”或更高的漏洞，您可以通过以下方式触发 CI 管道故障：
grype ubuntu:latest --fail-on medium
如果您看到 Grype 报告误报或您不想看到的任何其他漏洞匹配，您可以通过在 Grype 配置文件（例如~/.grype.yaml ）。这会导致 Grype 不会报告任何符合任何忽略规则指定条件的漏洞匹配项。
每个规则可以指定以下条件的任意组合：
漏洞 ID（例如"CVE-2008-4318" ）
命名空间（例如"nvd" ）
修复状态（允许值： "fixed" 、 "not-fixed" 、 "wont-fix"或"unknown" ）
包名称（例如"libcurl" ）
软件包版本（例如"1.5.1" ）
包语言（例如"python" ；这些值在此处定义）
包类型（例如"npm" ；这些值在此处定义）
包位置（例如"/usr/local/lib/node_modules/**" ；支持 glob 模式）
下面是一个示例~/.grype.yaml ，演示了忽略规则的预期格式：
ignore: # 这是支持的规则字段的完整集合： - 漏洞：CVE-2008-4318 修复状态：未知 # 当 Grype 读取 vex 数据时应用 VEX 字段：vex-status：not_affected vex-justification：vulnerable_code_not_present package：name：libcurl version：1.5.1 type：npm location：“/ usr/local/lib/node_modules/**" # 我们可以制定规则仅通过漏洞 ID 进行匹配： - 漏洞：CVE-2014-54321 # ...或仅通过单个包字段： - 包装：类型：宝石
如果任何规则适用于匹配，则漏洞匹配将被忽略。仅当规则中指定的所有字段都适用于漏洞匹配时，该规则才被视为适用于给定漏洞匹配。
当您在指定忽略规则时运行 Grype 时，“忽略”的漏洞匹配会发生以下情况：
忽略的匹配项在 Grype 的输出中完全隐藏，除非使用json或template输出格式；但是，在这两种格式中，忽略的匹配项将从现有的matches数组字段中删除，并将它们放置在新的ignoredMatches数组字段中。每个列出的被忽略的匹配项还有一个附加字段appliedIgnoreRules ，它是导致 Grype 忽略此漏洞匹配的任何规则的数组。
使用--fail-on 时，忽略的匹配不会影响 Grype 的退出状态决策。例如，如果用户指定--fail-on critical ，并且所有与“严重”严重性匹配的漏洞都被忽略，Grype 将退出零。
注意：请继续报告您看到的任何误报！即使您可以使用忽略规则可靠地过滤掉误报，如果我们尽可能多地了解 Grype 的误报，这对 Grype 社区也非常有帮助。这有助于我们不断改进 Grype！
如果您只希望 Grype 报告已确认修复的漏洞，则可以使用--only-fixed标志。 （这会自动将忽略规则添加到 Grype 的配置中，以便忽略未修复的漏洞。）
例如，这是 Alpine 3.10 的扫描：
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical libcrypto1.1 1.1.1k-r0 CVE-2021-3711 Critical libcrypto1.1 1.1.1k-r0 CVE-2021-3712 High libssl1.1 1.1.1k-r0 CVE-2021-3712 High libssl1.1 1.1.1k-r0 CVE-2021-3711 Critical
...这是相同的扫描，但添加了标志--only-fixed ：
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
如果您希望 Grype 仅报告尚未确认修复的漏洞，则可以使用--only-notfixed标志。或者，您可以使用--ignore-states标志来过滤具有特定状态（例如wont-fix的漏洞的结果（有关有效修复状态的列表，请参阅--help ）。这些标志会自动将忽略规则添加到 Grype 的配置中，以便忽略已修复或不会修复的漏洞。
Grype 可以使用 VEX（漏洞利用交换）数据来过滤误报或提供额外的上下文，从而增强匹配。扫描容器镜像时，您可以使用--vex标志指向一个或多个 OpenVEX 文档。
VEX 语句将产品（容器映像）、漏洞和 VEX 状态关联起来，以表达漏洞影响的断言。 VEX 状态有四种： not_affected 、 affected 、 fixed和under_investigation 。
这是一个简单的 OpenVEX 文档的示例。 （提示：使用vexctl生成您自己的文档）。
{“@context”：“https://openvex.dev/ns/v0.2.0”，“@id”：“https://openvex.dev/docs/public/vex-d4e9020b6d0d26f131d535e055902dd6ccf3e2088bce3079a8cd3588a4b14c78”，“作者”：“ Grype 用户 ", "timestamp": "2023-07-17T18:28:47.696004345-06:00", "version": 1, "statements": [
{“漏洞”：{“名称”：“CVE-2023-1255”
}， “产品”： [
{“@id”：“pkg：oci/alpine@sha256％3A124c7d2707904eea7431fffe91522a01e5a861a624ee31d03372cc1d138a3126”，“子组件”：[
{ "@id": "pkg:apk/alpine/[email protected]" },
{“@id”：“pkg：apk/alpine/[email protected]”}
]
}
], "状态": "已修复"
}
]
} 默认情况下，Grype将使用指定VEX文档中状态为not_affected或fixed的任何语句将匹配移动到忽略集。
使用--show-suppressed时，会标记由于 VEX 语句而忽略的任何匹配：
libcrypto3 3.0.8-r3 3.0.8-r4 apk CVE-2023-1255 Medium (suppressed by VEX)
仅当使用GRYPE_VEX_ADD环境变量或在配置文件中明确请求时，才会考虑使用affected或under_investigation状态的语句来扩充结果集。
可以编写忽略规则来控制 Grype 如何遵守 VEX 语句。例如，要将 Grype 配置为仅在理由为vulnerable_code_not_present时对 VEX 语句执行操作，您可以编写如下规则：
- -忽略： - vex-status：not_affected vex-justification：vulnerable_code_not_present
有关详细信息，请参阅理由列表。您可以将vex-status和vex-justification与其他忽略规则参数混合使用。
当 Grype 执行漏洞扫描时，它会使用存储在本地文件系统上的漏洞数据库来执行此操作，该数据库是通过从各种公开可用的漏洞数据源提取数据而构建的。这些来源包括：
Alpine Linux SecDB：https://secdb.alpinelinux.org/
亚马逊Linux ALAS：https://alas.aws.amazon.com/AL2/alas.rss
Chainguard SecDB：https://packages.cgr.dev/chainguard/security.json
Debian Linux CVE 跟踪器：https://security-tracker.debian.org/tracker/data/json
GitHub 安全公告 (GHSA)：https://github.com/advisories
国家漏洞数据库 (NVD)：https://nvd.nist.gov/vuln/data-feeds
Oracle Linux OVAL：https://linux.oracle.com/security/oval/
RedHat Linux 安全数据：https://access.redhat.com/Hydra/rest/securitydata/
红帽 RHSA：https://www.redhat.com/security/data/oval/
SUSE Linux OVAL：https://ftp.suse.com/pub/projects/security/oval/
Ubuntu Linux 安全：https://people.canonical.com/~ubuntu-security/
Wolfi SecDB：https://packages.wolfi.dev/os/security.json
默认情况下，Grype 会自动为您管理该数据库。 Grype 检查漏洞数据库的新更新，以确保每次扫描都使用最新的漏洞信息。此行为是可配置的。有关更多信息，请参阅管理 Grype 的数据库部分。
Grype的漏洞数据库是一个SQLite文件，名为vulnerability.db 。对数据库的更新是原子的：整个数据库被替换，然后被 Grype 视为“只读”。
Grype 数据库更新的第一步是发现可检索的数据库。 Grype 通过从公共端点请求“列表文件”来实现此目的：
https://toolbox-data.anchore.io/grype/databases/listing.json
列表文件包含每个可供下载的数据库的条目。
以下是列表文件中的条目示例：
{“构建”：“2021-10-21T08：13：41Z”，“版本”：3，“url”：“https://toolbox-data.anchore.io/grype/databases/vulnerability-db_v3_2021-10- 21T08:13:41Z.tar.gz","校验和":"sha256:8c99fb4e516f10b304f026267c2a73a474e2df878a59bf688cfb0f094bfe7a91"}有了这些信息，Grype 就可以选择正确的数据库（具有当前架构版本的最近构建的数据库）、下载数据库并使用列出的checksum和值验证数据库的完整性。
注意：正常使用时，用户无需管理Grype的数据库！ Grype 在幕后管理其数据库。然而，对于需要更多控制的用户，Grype 提供了更明确地管理数据库的选项。
默认情况下，数据库缓存在本地文件系统的$XDG_CACHE_HOME/grype/db/目录中。例如，在 macOS 上，数据库将存储在~/Library/Caches/grype/db/3/中。 （有关 XDG 路径的更多信息，请参阅 XDG 基本目录规范。）
您可以使用环境变量GRYPE_DB_CACHE_DIR设置缓存目录路径。如果单独设置该变量不起作用，则可能还需要设置TMPDIR环境变量。
Grype 需要最新的漏洞信息来提供准确的匹配。默认情况下，如果最近5天内没有构建本地数据库，则会执行失败。数据过时检查可通过环境变量GRYPE_DB_MAX_ALLOWED_BUILT_AGE和GRYPE_DB_VALIDATE_AGE或db下的字段max-allowed-built-age和validate-age进行配置。它使用 golang 的持续时间语法。将GRYPE_DB_VALIDATE_AGE或validate-age设置为false以禁用过时检查。
默认情况下，Grype 在每次运行时都会通过 Internet 进行网络调用来检查新数据库。您可以通过将环境变量GRYPE_DB_AUTO_UPDATE设置为false来告诉 Grype 不要执行此检查。
只要将Grype的vulnerability.db和metadata.json文件放置在预期schema版本的缓存目录中，Grype就无需访问网络。此外，您可以在在线环境中通过grype db list命令获取可供下载的数据库存档列表，下载数据库存档，将其传输到离线环境，然后使用grype db import 以离线方式使用给定的数据库。
如果您想在内部分发自己的 Grype 数据库而不需要手动使用db import ，您可以利用 Grype 的数据库更新机制。为此，您可以制作自己的listing.json文件，类似于公开找到的文件（请参阅grype db list -o raw以获取我们的公开listing.json文件的示例），并将下载 URL 更改为指向内部端点（例如私有 S3 存储桶、内部文件服务器等）。 Grype 的任何内部安装都可以通过配置db.update-url （与GRYPE_DB_UPDATE_URL环境变量相同）指向您制作的托管listing.json文件来自动接收数据库更新。
Grype 为想要从命令行控制数据库的用户提供特定于数据库的 CLI 命令。以下是提供的一些有用命令：
grype db status — 报告 Grype 数据库的当前状态（例如其位置、构建日期和校验和）
grype db check — 查看数据库是否有可用更新
grype db update — 确保最新的数据库已下载到缓存目录（Grype 默认在每次扫描开始时执行此操作）
grype db list — 下载在db.update-url配置的列表文件并显示可供下载的数据库
grype db import — 为 grype 提供数据库存档以供显式使用（对于离线数据库更新很有用）
grype db providers - 提供数据库提供商的详细列表
通过运行grype db --help查找有关 Grype 数据库命令的完整信息。
Grype 通过其 CLI 实现 (cobra) 提供 shell 补全。通过运行以下命令之一生成 shell 的完成代码：
grype completion
go run ./cmd/grype completion
这会将 shell 脚本输出到 STDOUT，然后可以将其用作 Grype 的完成脚本。使用-h或--help标志运行上述命令之一将提供有关如何为您选择的 shell 执行此操作的说明。
当容器运行时不存在时，grype 仍然可以使用公共凭证源（例如~/.docker/config.json ）中配置的凭证。它将使用这些凭据从私有注册表中提取图像。配置文件是通过诸如docker login之类的命令向私有注册表进行身份验证时存储凭据的位置。有关更多信息，请参阅go-containerregistry文档。
config.json示例如下所示：
// config.json
{
"auths": {
"registry.example.com": {
"username": "AzureDiamond",
"password": "hunter2"
}
}
}您可以运行以下命令作为示例。它详细说明了容器访问私有注册表所需的安装/环境配置：
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest
以下部分显示了如何将此配置文件作为机密安装到 kubernetes 上的容器中的简单工作流程。
创造一个秘密。 config.json的值很重要。它指的是此处详细说明的规范。此部分下方是 pod 配置将作为卷使用的secret.yaml文件。关键的config.json很重要。当安装到 Pod 中时，它最终将成为文件的名称。
apiVersion: v1
kind: Secret
metadata:
name: registry-config
namespace: grype
data:
config.json:
```
`kubectl apply -f secret.yaml` 创建运行 grype 的 pod。 env DOCKER_CONFIG很重要，因为它通告在哪里查找凭证文件。在下面的示例中，设置DOCKER_CONFIG=/config通知 grype 可以在/config/config.json找到凭据。这就是为什么我们使用config.json作为我们的秘密的密钥。当安装到容器中时，秘密的密钥将用作文件名。 volumeMounts部分将我们的密钥安装到/config 。 volumes部分命名我们的卷并利用我们在第一步中创建的秘密。
apiVersion: v1
kind: Pod
spec:
containers:
- image: anchore/grype:latest
name: grype-private-registry-demo
env:
- name: DOCKER_CONFIG
value: /config
volumeMounts:
- mountPath: /config
name: registry-config
readOnly: true
args:
-
volumes:
- name: registry-config
secret:
secretName: registry-config
```
`kubectl apply -f pod.yaml` 用户现在可以运行kubectl logs grype-private-registry-demo 。日志应显示 pod 配置中提供的
使用上述信息，用户应该能够配置私有注册表访问，而无需在grype或syft配置文件中执行此操作。它们也不会依赖于 docker 守护进程（或其他一些运行时软件）来进行注册表配置和访问。
默认配置搜索路径（使用grype config locations查看所有内容）：
.grype.yaml
.grype/config.yaml
~/.grype.yaml
使用grype config将示例配置文件打印到标准输出。将所有值加载到标准输出后，使用grype config --load打印当前配置。
您可以使用--config / -c标志直接指定文件来提供您自己的配置文件/路径：
grype-c /path/to/config.yaml
配置选项（示例值为默认值）：
# 启用/禁用在启动时检查应用程序更新# 与 GRYPE_CHECK_FOR_APP_UPDATE 相同 env varcheck-for-app-update: true# 允许用户指定应使用哪个映像源来生成 sbom# 有效值为：registry、docker、podman#与 GRYPE_DEFAULT_IMAGE_PULL_SOURCE 相同 env vardefault-image-pull-source: ""# 与 --name 相同；设置正在分析的目标的名称name: ""# 扫描时，如果发现严重性等于或高于给定严重性，则返回代码将为 1# 默认未设置，这将跳过此验证（选项：可忽略、低、中） , 高, 关键)# 与 --fail-on 相同; GRYPE_FAIL_ON_SEVERITY env varfail-on-severity: ""#漏洞报告的输出格式（选项：table、template、json、cyclonedx）#当使用template作为输出类型时，还必须为'output-template-提供一个值file'# 与 -o 相同； GRYPE_OUTPUT env varoutput: "table"# 如果使用模板输出，则必须提供 Go 模板文件的路径# 有关模板输出的更多信息，请参阅 https://github.com/anchore/grype#using-templates# 默认路径模板文件是当前工作目录#output-template-file: .grype/html.tmpl#将输出报告写入文件(默认是写入stdout)#与--file相同; GRYPE_FILE env varfile: ""# 从扫描中排除的 glob 列表，例如：# except:# - '/etc/**'# - './out/**/*.json'# 与 -- 相同排除 ; GRYPE_EXCLUDE env varexinclude: []# 包含与上游内核包相匹配的内核头包上的匹配项# 如果为 'false'，则任何此类匹配项都将标记为被忽略match-upstream-kernel-headers: false# 时使用的操作系统和/或体系结构引用容器镜像（例如“windows/armv6”或“arm64”）#与--platform相同； GRYPE_PLATFORM env varplatform: ""# 如果使用 SBOM 输入，则当软件包没有时自动生成 CPEadd-cpes-if-none: false# 显式指定用作: 的 linux 发行版，如 alpine:3.10distro:external -sources: enable: false maven: search-upstream-by-sha1: true base-url: https://repo1.maven.org/maven2db: # 在执行时检查数据库更新 # 与 GRYPE_DB_AUTO_UPDATE 相同 env var auto-update: true # 写入漏洞数据库缓存的位置;默认为 $XDG_CACHE_HOME/grype/db # 与 GRYPE_DB_CACHE_DIR 相同 env var cache-dir: "" # 漏洞数据库的 URL # 与 GRYPE_DB_UPDATE_URL 相同 env var update-url: "https://toolbox-data.anchore.io/grype /databases/listing.json" # 确保数据库构建不早于 max-allowed-built-age # 设置为 false 以禁用检查 validate-age: true # 漏洞数据库允许的最大年龄， # 年龄是从那时起的时间它已构建 # 默认最大期限为 120 小时（或五天） max-allowed-built-age: "120h" # 下载 GRYPE_DB_UPDATE_URL 超时以查看是否需要下载数据库 # 截至 2024 年 4 月，该文件约为 156KiB -17 所以下载应该很快；根据需要调整 update-available-timeout: "30s" # 下载实际漏洞数据库的超时 # 截至 2024 年 4 月 17 日，数据库约为 156MB，因此较慢的连接可能会超过默认超时；根据需要调整 update-download-timeout: "120s"search: # 查找包的搜索空间（选项：全层、压缩） # 与 -s 相同； GRYPE_SEARCH_SCOPE env var range: "squashed" # 在包含要搜索的文件索引 (zip) 的档案中搜索 # 注意：目前这只适用于 java 包编目器 # 与 GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES 相同 env var indexed-archives: true # 搜索在不包含要搜索的文件索引的档案中（tar、tar.gz、tar.bz2 等） # 注意：启用此功能可能会导致性能影响，因为所有发现的压缩 tar 都将被解压缩 # 注意：目前此功能仅适用于 java 包编目器 # 与 GRYPE_PACKAGE_SEARCH_UNINDEXED_ARCHIVES 相同 env var unindexed-archives: false# 通过“registry:”直接从注册表拉取时的选项 schemaregistry: # 与注册表通信时跳过 TLS 验证 # 与 GRYPE_REGISTRY_INSECURE_SKIP_TLS_VERIFY 相同 env var insecure -skip-tls-verify: false # 连接到注册表时使用 http 而不是 https # 与 GRYPE_REGISTRY_INSECURE_USE_HTTP 相同 env var insecure-use-http: false # CA 证书的文件路径（或包含 *.crt、*.cert、 *.pem) 用于生成客户端证书 # GRYPE_REGISTRY_CA_CERT env var ca-cert: "" # 特定注册表的凭据 auth: # 注册表的 URL（例如“docker.io”、“localhost:5000”等） # GRYPE_REGISTRY_AUTH_AUTHORITY 环境变量 - Authority: "" # GRYPE_REGISTRY_AUTH_USERNAME env var username: "" # GRYPE_REGISTRY_AUTH_PASSWORD env var password: "" # 注意：令牌和用户名/密码是互斥的 # GRYPE_REGISTRY_AUTH_TOKEN env var token: "" # 用于 TLS 身份验证的客户端证书的文件路径到注册表 # GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert: "" # 用于对注册表进行 TLS 身份验证的客户端密钥的文件路径 # GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key: "" # - ... # 注意，可以通过以下方式提供更多凭据仅配置文件（不是环境变量）log: # 抑制所有输出（漏洞列表除外） # 与 -q 相同； GRYPE_LOG_QUIET env var Quiet: false # 增加详细程度 # 与 GRYPE_LOG_VERBOSITY 相同 env var verbosity: 0 # 日志级别；注意：详细日志记录抑制 ETUI # 与 GRYPE_LOG_LEVEL 相同 env var # 使用 logrus 日志记录级别：https://github.com/sirupsen/logrus#level-logging level: "error" # 写入日志文件的位置（默认不是）拥有日志文件） # 与 GRYPE_LOG_FILE 相同 env var file: ""match: # 设置下面的匹配器，以便在尝试查找漏洞匹配时使用 cpes。当无法识别主要匹配器时，库存匹配器是默认值。 java: using-cpes: false python: using-cpes: false javascript: using-cpes: false ruby: using-cpes: false dotnet: using-cpes: false golang: using-cpes: false # 即使禁用 CPE 匹配，扫描“stdlib”时例外。 always-use-cpe-for-stdlib: true # 允许主模块伪版本（可能只是 Syft“猜测”）用于漏洞匹配allow-main-module-pseudo-version-comparison: false stock : 使用 cpes: true
目前正在研究以下潜在发展领域：
支持白名单、包映射
