一个针对容器镜像和文件系统的漏洞扫描工具
作者：Sec-Labs | 发布时间：
项目地址
https://github.com/anchore/grype
项目名称：Grype
技术点
- 漏洞扫描
- Syft
- SBOM
- Docker
- OCI
- Singularity
项目用途
Grype是一个容器映像和文件系统的漏洞扫描器，通过与Syft（可用于容器映像和文件系统的SBOM工具）配合使用，查找容器映像和文件系统中已知的漏洞。它可以扫描多种主要操作系统包和语言特定的包，并支持Docker、OCI和Singularity镜像格式，可用于容器安全领域，帮助用户发现容器镜像和文件系统中的漏洞，提高安全性。安装简单，使用方便，可以通过curl命令进行安装。此外，Grype还可在GitHub Actions中使用，方便用户在CI工作流程中进行漏洞扫描。
Grype
Grype是一个针对容器镜像和文件系统的漏洞扫描器。您可以轻松地安装二进制文件并尝试使用它。它可以与Syft搭配使用，后者是容器镜像和文件系统的强大的软件物料清单（SBOM）工具。
加入我们的社区会议！
- 日历：https://calendar.google.com/calendar/u/0/r?cid=Y182OTM4dGt0MjRtajI0NnNzOThiaGtnM29qNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t
- 议程：https://docs.google.com/document/d/1ZtSAa6fj2a6KRWviTn3WoJm09edvrNUp4Iz_dOjjyY8/edit?usp=sharing（加入[这个组](https://groups.google.com/g/anchore-oss-community)以获得写入权限）
- 欢迎加入！
对于Syft或Grype商业支持选项，请联系Anchore。
特性
- 扫描容器镜像或文件系统的内容以查找已知漏洞。
- 查找主要操作系统软件包的漏洞：
- Alpine
- Amazon Linux
- BusyBox
- CentOS
- Debian
- Distroless
- Oracle Linux
- Red Hat (RHEL)
- Ubuntu
- 查找特定于语言的软件包的漏洞：
- Ruby（Gems）
- Java（JAR、WAR、EAR、JPI、HPI）
- JavaScript（NPM、Yarn）
- Python（Egg、Wheel、Poetry、requirements.txt/setup.py文件）
- Dotnet（deps.json）
- Golang（go.mod）
- PHP（Composer）
- Rust（Cargo）
- 支持Docker、OCI和Singularity镜像格式。
如果您遇到问题，请使用问题跟踪器告诉我们。
安装
推荐方式
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
您也可以选择另一个安装目录和发布版本。目标目录不需要是/usr/local/bin，它只需要是用户路径中的一个位置，并且安装Grype的用户具有该目录的写入权限即可。
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b <DESTINATION_DIR> <RELEASE_VERSION>
Homebrew
brew tap anchore/grype
brew install grype
MacPorts
在macOS上，还可以通过MacPorts从社区维护的端口安装Grype：
sudo port install grype
注意：目前，Grype仅为macOS和Linux构建。
从源代码安装
请参阅DEVELOPING.md以获取从源代码构建和运行的说明。
GitHub Actions
如果您正在使用GitHub Actions，则可以使用我们的基于Grype的操作在CI工作流程中运行漏洞扫描。## 入门指南
安装二进制文件，确保grype在您的路径中可用。要扫描镜像中的漏洞：
grype <image>
上述命令扫描容器中可见的漏洞（即镜像的压缩表示形式）。要在漏洞扫描中包含所有镜像层中的软件，而不管其是否存在于最终镜像中，请提供--scope all-layers：
grype <image> --scope all-layers
要从Docker容器中运行grype，以便它可以扫描运行中的容器，请使用以下命令：
docker run --rm \
--volume /var/run/docker.sock:/var/run/docker.sock \
--name Grype anchore/grype:latest \
$(ImageName):$(ImageTag)
支持的来源
Grype可以扫描除Docker以外的各种来源。
# 扫描容器镜像存档（来自`docker image save ...`，`podman save ...`或`skopeo copy`命令的结果）
grype path/to/image.tar
# 扫描Singularity Image Format（SIF）容器
grype path/to/image.sif
# 扫描目录
grype dir:path/to/dir
可以使用指定的方案显式提供来源：
podman:yourrepo/yourimage:tag 使用来自Podman守护程序的镜像
docker:yourrepo/yourimage:tag 使用来自Docker守护程序的镜像
docker-archive:path/to/yourimage.tar 从磁盘上的tarball中使用由“docker save”创建的存档
oci-archive:path/to/yourimage.tar 从磁盘上的tarball中使用OCI存档（来自Skopeo或其他方式）
oci-dir:path/to/yourimage 直接从磁盘上的OCI布局目录（来自Skopeo或其他方式）中读取
singularity:path/to/yourimage.sif 直接从磁盘上的Singularity Image Format（SIF）容器中读取
dir:path/to/yourproject 直接从磁盘上的路径（任何目录）中读取
sbom:path/to/syft.json 从磁盘上的路径中读取Syft JSON
registry:yourrepo/yourimage:tag 直接从注册表中拉取镜像（无需容器运行时）
如果未提供镜像源并且无法从给定参考中检测到镜像，则假定应该从Docker守护程序中拉取镜像。 如果不存在docker，则尝试使用Podman守护程序，然后是直接到镜像注册表的最后一步。
可以使用default-image-pull-source配置选项覆盖此默认行为（有关详细信息，请参见配置）。
在Grype中使用SBOM以获得更快的漏洞扫描：
# 然后根据需要频繁扫描新漏洞
grype sbom:./sbom.json
# （您也可以将SBOM导入Grype）
cat ./sbom.json | grype
Grype支持输入Syft，SPDX和CycloneDXSBOM格式。如果Syft已生成这些文件类型中的任何一个，则它们应该具有适当的信息以正确使用Grype。还可以使用由其他工具生成的SBOM，成功的程度各不相同。使Grype匹配更成功的两个因素是包含CPE和Linux发行版信息。如果SBOM不包含任何CPE信息，则可以使用--add-cpes-if-none标志使用软件包信息生成这些信息。要指定分发，请使用--distro <distro>:<version>标志。完整示例是：
grype --add-cpes-if-none --distro alpine:3.10 sbom:some-apline-3.10.spdx.json
处理证明
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
漏洞摘要
基本Grype漏洞数据格式
{
"vulnerability": {
...
},
"relatedVulnerabilities": [
...
],
"matchDetails": [
...
],
"artifact": {
...
}
}
```- **漏洞信息**：与被直接匹配的具体漏洞相关的所有信息（例如ID、严重程度、CVSS评分、修复信息、更多信息的链接）。
- **相关漏洞信息**：有关与主要报告的漏洞相关的漏洞的信息。也许我们匹配的漏洞是GitHub安全公告，它具有上游CVE（在权威的国家漏洞数据库中）。在这些情况下，我们在此列出上游漏洞。
- **匹配详细信息**：此部分试图解释我们在寻找匹配时搜索了什么，以及导致匹配的软件包和漏洞的确切详细信息。
- **构件信息**：这是我们所了解的软件包的信息的子集（与[Syft](https://github.com/anchore/syft) json输出相比，我们总结了元数据部分）。这包括我们在容器镜像或目录的哪个位置找到软件包、软件包的类型、许可信息、pURLs、CPE等信息。
### 排除文件路径
Grype可以使用glob表达式来排除源中要扫描的文件和路径，使用一个或多个`--exclude`参数：
grype --exclude './out/**/*.json' --exclude /etc
**注意：**在进行_image scanning_的情况下，由于扫描整个文件系统，因此可以使用绝对路径，例如`/etc`或`/usr/**/*.txt`，而_directory scans_则相对于指定的目录排除文件。例如：使用`--exclude ./package.json`扫描`/usr/foo`将排除`/usr/foo/package.json`，而`--exclude '**/package.json'`将排除`/usr/foo`下的所有`package.json`文件。对于_directory scans_，需要以`./`、`*/`或`**/`开头的路径表达式，这些路径表达式将相对于指定的扫描目录_解析_。请记住，您的shell可能会尝试展开通配符，因此将这些参数放在单引号中，例如：`'**/*.json'`。
### 外部数据源
Grype可以配置以整合外部数据源来增加漏洞匹配的准确性。该功能目前默认处于禁用状态。要启用此功能，请将以下内容添加到grype配置文件中：
```yaml
external-sources:
enable: true
maven:
search-upstream-by-sha1: true
base-url: https://search.maven.org/solrsearch/select
如果您使用的是其他注册表作为maven端点，则还可以配置base-url。
输出格式
Grype的输出格式也是可配置的：
grype <image> -o <format>
可用的格式为：
table：列汇总（默认）。cyclonedx：符合CycloneDX 1.4规范的XML报告。cyclonedx-json：符合CycloneDX 1.4规范的JSON报告。json：使用此选项可尽可能多地从Grype中获取信息！template：允许用户指定输出格式。参见下面的“使用模板”。
使用模板
Grype可以使用Go模板定义自定义输出格式。以下是其工作原理：
-
将您的格式定义为Go模板，并将此模板保存为文件。
-
将输出格式设置为“template”（
-o template）。 -
指定模板文件的路径（
-t ./path/to/custom.template）。 -
Grype的模板处理使用与
json输出格式相同的数据模型，因此如果您在编写模板时想知道可用的数据，可以使用grype <image> -o json的输出作为参考。
示例：您可以编写一个将Grype输出数据以CSV格式输出的Go模板，并运行grype <image> -o template -t ~/path/to/csv.tmpl。
请注意：模板可以访问有关运行它们的系统的信息，例如环境变量。您永远不应运行不受信任的模板。
以下是csv.tmpl文件的示例：
"Package","Version Installed","Vulnerability ID","Severity"
{{- range .Matches}}
"{{.Artifact.Name}}","{{.Artifact.Version}}","{{.Vulnerability.ID}}","{{.Vulnerability.Severity}}"
{{- end}}
这将产生如下输出：
"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"
...
Grype还包括大量来自sprig的实用程序模板函数，除默认的golang text/template外，还允许用户自定义Grype的输出。### 根据漏洞严重程度进行筛选
如果报告的漏洞在指定的严重程度及以上，则可以使Grype报错退出。这在脚本或CI管道中使用Grype时非常方便。要实现这一点，请使用--fail-on <severity> CLI标志。
例如，如果在“ubuntu：latest”镜像中发现任何严重程度为“中”或更高的漏洞，则可以触发CI管道失败：
grype ubuntu：latest --fail-on medium
指定要忽略的匹配项
如果您发现Grype在报告误报或其他您不想看到的漏洞匹配项时，可以通过在Grype配置文件（例如 ~/.grype.yaml）中指定一个或多个_“忽略规则”_来告诉Grype忽略匹配项。这将导致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:
# This is the full set of supported rule fields:
- vulnerability: CVE-2008-4318
fix-state: unknown
package:
name: libcurl
version: 1.5.1
type: npm
location: "/usr/local/lib/node_modules/**"
# We can make rules to match just by vulnerability ID:
- vulnerability: CVE-2014-54321
# ...or just by a single package field:
- package:
type: gem
如果任何规则适用于匹配项，则将忽略漏洞匹配项。仅当规则中指定的所有字段都适用于漏洞匹配项时，才认为规则适用于给定的漏洞匹配项。
在指定忽略规则的情况下运行 Grype 时，对于“已忽略”的漏洞匹配项，以下操作将发生：
-
忽略的匹配项在 Grype 的输出中完全隐藏，除非使用
json或template输出格式；但是，在这两个格式中，忽略的匹配项将从现有的matches数组字段中移除，并放置在新的ignoredMatches数组字段中。每个列出的忽略匹配项还有一个附加字段appliedIgnoreRules，其中包含导致 Grype 忽略此漏洞匹配项的任何规则的数组。 -
忽略的匹配项不会计入使用
--fail-on <severity>时 Grype 的退出状态决策中。例如，如果用户指定--fail-on critical，并且所有具有“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标志。（这会自动将忽略规则添加到Grype的配置中，以便忽略已修复的漏洞。）## Grype 的数据库
当 Grype 扫描漏洞时，会使用本地文件系统中存储的漏洞数据库进行扫描，该数据库由从多个公开可用的漏洞数据源中提取数据构建而成。这些数据源包括：
- Alpine Linux SecDB：https://secdb.alpinelinux.org/
- Amazon Linux ALAS：https://alas.aws.amazon.com/AL2/alas.rss
- RedHat RHSAs：https://www.redhat.com/security/data/oval/
- Debian Linux CVE Tracker：https://security-tracker.debian.org/tracker/data/json
- Github GHSAs：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/
- Suse Linux OVAL：https://ftp.suse.com/pub/projects/security/oval/
- Ubuntu Linux 安全：https://people.canonical.com/~ubuntu-security/
默认情况下，Grype 会自动为您管理该数据库。Grype 检查漏洞数据库的新更新，以确保每次扫描使用的漏洞信息是最新的。此行为是可配置的。有关更多信息，请参阅管理 Grype 的数据库 部分。
数据库更新的工作方式
Grype 的漏洞数据库是一个名为 vulnerability.db 的 SQLite 文件。数据库更新是原子性的：整个数据库被替换，然后由 Grype 作为“只读”处理。
Grype 在数据库更新的第一步是发现可用于检索的数据库。Grype 通过从公共端点请求“清单文件”来完成此操作：
https://toolbox-data.anchore.io/grype/databases/listing.json
清单文件包含可供下载的每个数据库的条目。
这是清单文件中条目的示例：
{
"built": "2021-10-21T08:13:41Z",
"version": 3,
"url": "https://toolbox-data.anchore.io/grype/databases/vulnerability-db_v3_2021-10-21T08:13:41Z.tar.gz",
"checksum": "sha256:8c99fb4e516f10b304f026267c2a73a474e2df878a59bf688cfb0f094bfe7a91"
}
有了这些信息，Grype 可以选择正确的数据库（使用当前模式版本的最近构建的数据库），下载数据库，并使用列出的 checksum 值验证数据库的完整性。
管理 Grype 的数据库
注意： 在正常使用过程中，用户无需管理 Grype 的数据库！ Grype 在后台管理其数据库。但是，对于需要更多控制的用户，Grype 提供了更明确地管理数据库的选项。
本地数据库缓存目录
默认情况下，数据库会在本地文件系统上缓存在目录 $XDG_CACHE_HOME/grype/db/<SCHEMA-VERSION>/ 中。例如，在 macOS 上，数据库将存储在 ~/Library/Caches/grype/db/3/ 中。 （有关 XDG 路径的更多信息，请参阅 XDG 基本目录规范。）
您可以使用环境变量 GRYPE_DB_CACHE_DIR 设置缓存目录路径。
数据陈旧
Grype 需要最新的漏洞信息才能提供准确的匹配。默认情况下，如果本地数据库未在过去 5 天内构建，则执行将失败。可以通过环境变量 GRYPE_DB_MAX_ALLOWED_BUILT_AGE 和 GRYPE_DB_VALIDATE_AGE 或字段 max-allowed-built-age 和 validate-age（在“db”下）进行配置。它使用 golang 的时间持续时间语法。将 GRYPE_DB_VALIDATE_AGE 或 validate-age 设置为 false 以禁用陈旧性检查。
离线和无网络环境
默认情况下，Grype 在每次运行时都会检查新数据库，通过互联网进行网络调用。您可以通过将环境变量 GRYPE_DB_AUTO_UPDATE 设置为 false，告诉 Grype 不执行此检查。
只要您将 Grype 的 vulnerability.db 和 metadata.json 文件放置在预期模式版本的缓存目录中，Grype 就不需要访问网络。此外，您可以从在线环境中使用 grype db list 命令获取可下载的数据库存档列表，下载数据库存档，将其传输到离线环境，并使用 grype db import <db-archive-path> 在离线环境中使用给定的数据库。
如果您想在不需要手动使用 db import 的情况下在内部分发自己的 Grype 数据库，则可以利用 Grype 的 DB 更新机制。为此，您可以创建自己的 listing.json 文件，类似于公共找到的文件（请参见 grype db list -o raw 以查看我们的公共 listing.json 文件的示例），并将下载 URL 更改为指向内部端点（例如私有 S3 存储桶、内部文件服务器等）。通过配置 db.update-url（与 GRYPE_DB_UPDATE_URL 环境变量相同）指向您制作的托管 listing.json 文件，任何内部安装的 Grype 都可以自动接收数据库更新。#### 数据库管理CLI命令
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 --help，了解有关Grype数据库命令的完整信息。
Shell自动完成
Grype通过其CLI实现（cobra）提供了Shell自动完成。通过运行以下命令之一为您的Shell生成完整代码：
grype completion <bash|zsh|fish>go run main.go completion <bash|zsh|fish>
这将在STDOUT中输出一个Shell脚本，然后可以将其用作Grype的完成脚本。使用上述命令之一以-h或--help标志运行将为您选择的Shell提供说明。
私有注册表身份验证
本地Docker凭据
当不存在容器运行时，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 <private_image>
Kubernetes中的Docker凭据
以下部分显示了如何将此配置文件作为机密挂载到kubernetes上的容器中的简单工作流程。
- 创建机密。
config.json的值很重要。它指的是这里详细说明的规范。下面是pod配置将作为卷使用的secret.yaml文件。config.json键很重要。当挂载到容器时，密钥将用作文件名。 ``` # secret.yaml
apiVersion: v1 kind: Secret metadata: name: registry-config namespace: grype data: config.json:
`kubectl apply -f secret.yaml`
2. 创建运行grype的pod。环境变量`DOCKER_CONFIG`很重要，因为它告知在哪里查找凭据文件。在下面的示例中，设置`DOCKER_CONFIG=/config`告诉Grype可以在`/config/config.json`找到凭据。这就是为什么我们使用`config.json`作为我们的密钥的原因。当挂载到容器中时，密钥将用作文件名。`volumeMounts`部分将我们的secret挂载到`/config`。`volumes`部分命名了我们的卷并利用了我们在第一步中创建的secret。
``` # pod.yaml
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:
- <private_image>
volumes:
- name: registry-config
secret:
secretName: registry-config
kubectl apply -f pod.yaml
- 用户现在可以运行
kubectl logs grype-private-registry-demo。日志应显示所提供的私有映像的Grype分析。
使用上述信息，用户应该能够配置私有注册表访问，而无需在grype或syft配置文件中这样做。他们也不会依赖于docker守护程序（或其他运行时软件）进行注册表配置和访问。## 配置
默认的配置文件搜索路径：
.grype.yaml.grype/config.yaml~/.grype.yaml<XDG_CONFIG_HOME>/grype/config.yaml
您还可以使用 --config / -c 标志提供自己的配置文件/路径：
grype <image> -c /path/to/config.yaml
配置选项（示例值为默认值）：
# enable/disable checking for application updates on startup
# same as GRYPE_CHECK_FOR_APP_UPDATE env var
check-for-app-update: true
# allows users to specify which image source should be used to generate the sbom
# valid values are: registry, docker, podman
# same as GRYPE_DEFAULT_IMAGE_PULL_SOURCE env var
default-image-pull-source: ""
# same as --name; set the name of the target being analyzed
name: ""
# upon scanning, if a severity is found at or above the given severity then the return code will be 1
# default is unset which will skip this validation (options: negligible, low, medium, high, critical)
# same as --fail-on ; GRYPE_FAIL_ON_SEVERITY env var
fail-on-severity: ""
# the output format of the vulnerability report (options: table, json, cyclonedx)
# same as -o ; GRYPE_OUTPUT env var
output: "table"
# suppress all output (except for the vulnerability list)
# same as -q ; GRYPE_QUIET env var
quiet: false
# write output report to a file (default is to write to stdout)
# same as --file; GRYPE_FILE env var
file: ""
# a list of globs to exclude from scanning, for example:
# exclude:
# - '/etc/**'
# - './out/**/*.json'
# same as --exclude ; GRYPE_EXCLUDE env var
exclude: []
# os and/or architecture to use when referencing container images (e.g. "windows/armv6" or "arm64")
# same as --platform; GRYPE_PLATFORM env var
platform: ""
# If using SBOM input, automatically generate CPEs when packages have none
add-cpes-if-none: false
# Explicitly specify a linux distribution to use as <distro>:<version> like alpine:3.10
distro:
external-sources:
enable: false
maven:
search-upstream-by-sha1: true
base-url: https://search.maven.org/solrsearch/select
db:
# check for database updates on execution
# same as GRYPE_DB_AUTO_UPDATE env var
auto-update: true
# location to write the vulnerability database cache
# same as GRYPE_DB_CACHE_DIR env var
cache-dir: "$XDG_CACHE_HOME/grype/db"
# URL of the vulnerability database
# same as GRYPE_DB_UPDATE_URL env var
update-url: "https://toolbox-data.anchore.io/grype/databases/listing.json"
# it ensures db build is no older than the max-allowed-built-age
# set to false to disable check
validate-age: true
# Max allowed age for vulnerability database,
# age being the time since it was built
# Default max age is 120h (or five days)
max-allowed-built-age: "120h"
search:
# the search space to look for packages (options: all-layers, squashed)
# same as -s ; GRYPE_SEARCH_SCOPE env var
scope: "squashed"
# search within archives that do contain a file index to search against (zip)
# note: for now this only applies to the java package cataloger
# same as GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES env var
indexed-archives: true
# search within archives that do not contain a file index to search against (tar, tar.gz, tar.bz2, etc)
# note: enabling this may result in a performance impact since all discovered compressed tars will be decompressed
# note: for now this only applies to the java package cataloger
# same as GRYPE_PACKAGE_SEARCH_UNINDEXED_ARCHIVES env var
unindexed-archives: false
# options when pulling directly from a registry via the "registry:" scheme
registry:
# skip TLS verification when communicating with the registry
# same as GRYPE_REGISTRY_INSECURE_SKIP_TLS_VERIFY env var
insecure-skip-tls-verify: false
# use http instead of https when connecting to the registry
# same as GRYPE_REGISTRY_INSECURE_USE_HTTP env var
insecure-use-http: false
# credentials for specific registries
auth:
- # the URL to the registry (e.g. "docker.io", "localhost:5000", etc.)
# same as GRYPE_REGISTRY_AUTH_AUTHORITY env var
authority: ""
# same as GRYPE_REGISTRY_AUTH_USERNAME env var
username: ""
# same as GRYPE_REGISTRY_AUTH_PASSWORD env var
password: ""
# note: token and username/password are mutually exclusive
# same as GRYPE_REGISTRY_AUTH_TOKEN env var
token: ""
- ... # note, more credentials can be provided via config file only
log:
# use structured logging
# same as GRYPE_LOG_STRUCTURED env var
structured: false
# the log level; note: detailed logging suppress the ETUI
# same as GRYPE_LOG_LEVEL env var
# Uses logrus logging levels: https://github.com/sirupsen/logrus#level-logging
level: "error"
# location to write the log file (default is not to have a log file)
# same as GRYPE_LOG_FILE env var
file: ""
match:
# sets the matchers below to use cpes when trying to find
# vulnerability matches. The stock matcher is the default
# when no primary matcher can be identified
java:
using-cpes: true
python:
using-cpes: true
javascript:
using-cpes: true
ruby:
using-cpes: true
dotnet:
using-cpes: true
golang:
using-cpes: true
stock:
using-cpes: true
未来计划
目前正在研究以下潜在的开发领域：
- 支持允许列表、软件包映射