## 安装说明 ### 推荐方式 ``` curl -sSfL https://raw.githubusercontent.com/xeol-io/xeol/main/install.sh | sh -s -- -b /usr/local/bin ``` 检查安装或检查 xeol 版本 ``` xeol version ``` 您还可以为安装选择其他目标目录和发布版本。目标目录不必是 `/usr/local/bin`，只需是用户 PATH 中存在且安装用户可写入的位置即可。 ``` curl -sSfL https://raw.githubusercontent.com/xeol-io/xeol/main/install.sh | sh -s -- -b ``` ### Homebrew ``` brew tap xeol-io/xeol brew install xeol ``` ### GitHub Actions 如果您使用 GitHub Actions，可以直接使用 [Xeol GitHub action](https://github.com/marketplace/actions/xeol-end-of-life-eol-scan) 在 CI 工作流中对代码或容器镜像运行 EOL 扫描。 ### 验证已下载版本的 SLSA 来源证明 我们从 v0.9.5 版本开始为所有 Xeol 版本生成 SLSA 来源证明。您可以按以下方式验证发布二进制文件的来源证明： 1. 安装 [slsa-framework/slsa-verifier#installation](https://github.com/slsa-framework/slsa-verifier#installation) 工具 2. 从 Xeol 发布版下载签名文件 `multiple.intoto.jsonl` 3. 下载您要验证的 Xeol 发布二进制文件 4. 运行 `slsa-verifier verify-artifact --provenance-path multiple.intoto.jsonl --source-uri=github.com/xeol-io/xeol` 如果发布二进制文件验证通过，您应该会看到类似以下的内容： ``` ➜ ~ slsa-verifier verify-artifact --provenance-path multiple.intoto.jsonl xeol_0.9.5_darwin_amd64.tar.gz --source-uri=github.com/xeol-io/xeol Verified signature against tlog entry index 44906341 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77a658e74e86e03e7aedcca39eebddebf59310b4d9c463b037951109186d73a5681 Verified build using builder "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0" at commit fdc6f5efca3f7277aacf25ef42f502355398f512 Verifying artifact xeol_0.9.5_darwin_amd64.tar.gz: PASSED PASSED: Verified SLSA provenance ``` ## 入门指南 [安装二进制文件](#installation)，并确保 `xeol` 在您的 PATH 中可用。要扫描镜像中的 EOL 软件包： ``` xeol ``` 上述命令扫描容器中可见的 EOL 软件包（即镜像的压缩表示）。要包含所有镜像层中的软件（无论其是否存在于最终镜像中），请提供 `--scope all-layers`： ``` xeol --scope all-layers ``` 要从 Docker 容器中运行 xeol 以扫描正在运行的容器，请使用以下命令： ``` docker run --rm \ --volume /var/run/docker.sock:/var/run/docker.sock \ --name xeol noqcks/xeol:latest \ $(ImageName):$(ImageTag) ``` ### 支持的来源 xeol 可以扫描 Docker 以外的多种来源。 ``` # 扫描容器镜像归档（来自 `docker image save ...`、`podman save ...` 或 `skopeo copy` 命令的结果） xeol path/to/image.tar # 扫描 Singularity Image Format (SIF) 容器 xeol path/to/image.sif # 扫描目录 xeol dir:path/to/dir ``` 可以使用 scheme 显式指定来源： ``` 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) 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) att:attestation.json --key cosign.pub explicitly use the input as an attestation ``` 使用 SBOM 可以在 xeol 中实现更快的 EOL 扫描： ``` # 然后根据需要频繁扫描新的 EOL 包 xeol sbom:./sbom.json # （您也可以将 SBOM 通过管道传递给 xeol） cat ./sbom.json | xeol ``` xeol 支持 [Syft](https://github.com/xeol-io/xeol)、[SPDX](https://spdx.dev/) 和 [CycloneDX](https://cyclonedx.org/) SBOM 格式的输入。如果 Syft 已生成这些文件类型中的任何一种，它们应包含与 xeol 正常配合使用所需的适当信息。 ### 前瞻匹配 默认情况下，xeol 将匹配任何 EOL 日期小于当前日期 + 30 天的软件包。要设置自定义前瞻匹配时间，可以使用 `--lookahead `。其中 `` 的格式如 `1w`、`30d` 或 `1y`。 ### 对发现的 EOL 软件包进行拦截 您可以让 xeol 在发现任何 EOL 软件包时以错误退出。这对于 CI/CD pipeline 非常有用。为此，请使用 `--fail-on-eol-found` CLI 标志。 ``` xeol --fail-on-eol-found ``` ## 什么是 EOL 软件？ End of Life（EOL，终止生命周期）意味着供应商已认定相关软件已达到其"有用生命周期"的终点。在此特定日期之后，制造商不再销售、提供技术支持、维护、增强或修复该产品。请注意，尽管不同供应商可能对这些术语的使用有所不同，但 xeol 将 End of Life（EOL）和 End of Support（EOS）视为同一概念。EOL 软件存在安全风险，因为它不再被维护，也不会再接收安全更新。 xeol 目前不支持扩展支持日期，仅匹配供应商的标准 EOL 支持日期。 ## xeol 的数据库 当 xeol 执行 EOL 软件包扫描时，它使用存储在本地文件系统上的数据库，该数据库通过从多个来源拉取数据构建： - 聚合器：endoflife.date - 软件包注册表：cargo、maven、npm、nuget、pypi、rubygems - 供应商软件包：Adobe、Broadcom、IBM、Ivanti、Microsoft、Oracle、UIPath、Wireshark - 浏览器：Chrome、Edge xeol 的数据库并非所有 EOL 软件包的完整列表，而是常用软件的精选列表。 默认情况下，xeol 会自动为您管理此数据库。xeol 会检查数据库的新更新，以确保每次扫描都使用最新的 EOL 信息。此行为可配置。有关更多信息，请参阅管理 xeol 数据库部分。 ### 数据库更新机制 xeol 的 EOL 数据库是一个名为 `xeol.db` 的 SQLite 文件。数据库更新是原子性的：整个数据库被替换，然后被 xeol 视为"只读"。 xeol 数据库更新的第一步是发现可供检索的数据库。xeol 通过从公共端点请求"列表文件"来实现： `https://data.xeol.io/xeol/databases/listing.json` 列表文件包含可供下载的每个数据库的条目。 以下是列表文件中条目的示例： ``` { "built": "2021-10-21T08:13:41Z", "version": 3, "url": "https://data.xeol.io/xeol/databases/eol-db_v3_2021-10-21T08:13:41Z.tar.gz", "checksum": "sha256:8c99fb4e516f10b304f026267c2a73a474e2df878a59bf688cfb0f094bfe7a91" } ``` 通过此信息，xeol 可以选择正确的数据库（使用当前 schema 版本最新构建的数据库），下载数据库，并使用列出的 `checksum` 值验证数据库的完整性。 ### 管理 xeol 的数据库 #### 本地数据库缓存目录 默认情况下，数据库缓存在本地文件系统的目录 `$XDG_CACHE_HOME/xeol/db//` 中。例如，在 macOS 上，数据库将存储在 `~/Library/Caches/xeol/db/3/` 中。（有关 XDG 路径的更多信息，请参阅 [XDG Base Directory Specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)。） 您可以使用环境变量 `XEOL_DB_CACHE_DIR` 设置缓存目录路径。 #### 数据过期 xeol 需要最新的信息才能提供准确的 EOL 匹配。默认情况下，如果本地数据库不是在过去 5 天内构建的，执行将失败。数据过期检查可通过环境变量 `XEOL_DB_MAX_ALLOWED_BUILT_AGE` 和 `XEOL_DB_VALIDATE_AGE` 或 `db` 下的字段 `max-allowed-built-age` 和 `validate-age` 进行配置。它使用 [golang 的时间持续时间语法](https://pkg.go.dev/time#ParseDuration)。将 `XEOL_DB_VALIDATE_AGE` 或 `validate-age` 设置为 `false` 可禁用过期检查。 #### 离线和气隙环境 默认情况下，xeol 在每次运行时通过互联网进行网络调用来检查新数据库。您可以通过将环境变量 `XEOL_DB_AUTO_UPDATE` 设置为 `false` 来告诉 xeol 不执行此检查。 只要您将 xeol 的 `xeol.db` 和 `metadata.json` 文件放置在预期 schema 版本的缓存目录中，xeol 就无需访问网络。此外，您可以在联机环境中从 `xeol db list` 命令获取可供下载的数据库归档列表，下载数据库归档，将其传输到离线环境，并使用 `xeol db import ` 以离线方式使用给定的数据库。 如果您希望在不手动使用 `db import` 的情况下在内部分发自己的 xeol 数据库，您可以利用 xeol 的数据库更新机制。为此，您可以制作自己的 `listing.json` 文件（类似于公开可用的文件，请参阅 `xeol db list -o raw` 查看我们公开的 `listing.json` 文件示例），并将下载 URL 更改为指向内部端点（例如私有 S3 存储桶、内部文件服务器等）。任何内部安装的 xeol 都可以通过将 `db.update-url`（与 `XEOL_DB_UPDATE_URL` 环境变量相同）配置为指向您托管的 `listing.json` 文件来自动接收数据库更新。 #### 数据库管理的 CLI 命令 xeol 为希望从命令行控制数据库的用户提供了特定于数据库的 CLI 命令。以下是一些有用的命令： `xeol db status` — 报告 xeol 数据库的当前状态（如其位置、构建日期和校验和） `xeol db check` — 查看数据库是否有可用更新 `xeol db update` — 确保最新数据库已下载到缓存目录（xeol 默认在每次扫描开始时执行此操作） `xeol db list` — 下载在 `db.update-url` 处配置的列表文件，并显示可供下载的数据库 `xeol db import` — 为 xeol 提供要显式使用的数据库归档（对离线数据库更新有用） 通过运行 `xeol db --help` 查找 xeol 数据库命令的完整信息。 ## Shell 自动补全 xeol 通过其 CLI 实现（[cobra](https://github.com/spf13/cobra/blob/master/shell_completions.md)）提供 Shell 自动补全。运行以下命令之一为您的 Shell 生成补全代码： - `xeol completion ` - `go run ./cmd/xeol completion ` 这会将 Shell 脚本输出到 STDOUT，然后可将其用作 xeol 的补全脚本。使用 `-h` 或 `--help` 标志运行上述任一命令将为您提供针对所选 Shell 的操作说明。 ## 私有注册表认证 ### 本地 Docker 凭据 当容器运行时不存在时，xeol 仍可利用常见凭据源（如 `~/.docker/config.json`）中配置的凭据。 它将使用这些凭据从私有注册表拉取镜像。该配置文件存储了您通过 `docker login` 等命令与私有注册表进行认证时存储的凭据。 有关更多信息，请参阅 `go-containerregistry` [文档](https://github.com/google/go-containerregistry/tree/main/pkg/authn)。 `config.json` 的示例如下： ``` // config.json { "auths": { "registry.example.com": { "username": "AzureDiamond", "password": "hunter2" } } } ``` 您可以运行以下命令作为示例。它详细说明了容器访问私有注册表所需的挂载/环境配置： `docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" noqcks/xeol:latest ` ### Kubernetes 中的 Docker 凭据 以下部分展示了如何将该配置文件作为 Secret 挂载到 Kubernetes 容器中的简单工作流。 1. 创建 Secret。`config.json` 的值很重要。它指的是[此处](https://github.com/google/go-containerregistry/tree/main/pkg/authn#the-config-file)详述的规范。 以下部分是该 Pod 配置将作为卷使用的 `secret.yaml` 文件。 键 `config.json` 很重要。当挂载到 Pod 中时，它将成为文件的名称。 # secret.yaml apiVersion: v1 kind: Secret metadata: name: registry-config namespace: xeol data: config.json: `kubectl apply -f secret.yaml` 2. 创建运行 xeol 的 Pod。环境变量 `DOCKER_CONFIG` 很重要，因为它指示在哪里查找凭据文件。 在下面的示例中，设置 `DOCKER_CONFIG=/config` 通知 xeol 凭据可以在 `/config/config.json` 中找到。 这就是为什么我们使用 `config.json` 作为 Secret 的键。当挂载到容器中时，Secret 的键将用作文件名。 `volumeMounts` 部分将我们的 Secret 挂载到 `/config`。`volumes` 部分命名我们的卷并利用我们在第一步中创建的 Secret。 # pod.yaml apiVersion: v1 kind: Pod spec: containers: - image: noqcks/xeol:latest name: xeol-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` 3. 用户现在可以运行 `kubectl logs xeol-private-registry-demo`。日志应显示为 Pod 配置中提供的 `` 的 xeol 分析结果。 使用上述信息，用户应能够配置对私有注册表的访问，而无需在 `xeol` 或 `syft` 配置文件中进行配置。 他们也不会依赖 Docker 守护进程（或其他运行时软件）进行注册表配置和访问。 ## 配置 配置搜索路径： - `.xeol.yaml` - `.xeol/config.yaml` - `~/.xeol.yaml` - `/xeol/config.yaml` ## 发音 Xeol 的发音为"zee-oh-el"，就像 EOL 但前面加了一个 Z :-) ## 帮助 加入我们的 [discord](https://discord.gg/xAePvPpEx5) 获取帮助或反馈！

标签：DevSecOps, EOL软件检测, EVTX分析, Google Gemini, Go语言, GPT, IT基础设施管理, SBOM, Vue, Web截图, 上游代理, 企业安全, 依赖项分析, 包管理, 子域名突变, 安全合规, 容器安全, 容器镜像扫描, 开源组件, 持续集成安全, 文件系统扫描, 日志审计, 漏洞管理, 硬件无关, 程序破解, 终端生命周期管理, 网络代理, 网络资产管理, 请求拦截, 跌倒检测, 软件合规性, 软件物料清单, 软件生命周期, 软件资产管理