dasel v3.3.1 加固容器

这是一个针对 dasel v3.3.1 的 melange 包和 apko 容器镜像，包含针对 CVE-2026-33320（无限制的 YAML 别名扩展）的构建时补丁。该镜像完全由本地生成的 APK 构建——不使用任何预构建的上游镜像。

前提条件

• 架构：仅 x86_64
• 首次构建需要互联网访问（获取源码 tarball、Go 模块、Wolfi 包）

Windows 要求

所有构建和加载命令都可以在任何终端（PowerShell、CMD 或 bash）中运行。但有一个步骤仍需要 Unix shell：

• bash tests/test.sh — 该测试脚本使用 bash 和 coreutils（timeout、grep、sed）

在运行镜像测试之前，请安装 Git Bash（随 Git for Windows 一起提供）。

项目结构

.
├── .github/
├── melange/
│   ├── dasel.yaml
│   └── CVE-2026-33320.patch
├── apko/
│   └── dasel.yaml
├── tests/
│   └── test.sh
├── Makefile
├── compose.yaml
├── keys/                       # Generated, gitignored
│   ├── melange.rsa
│   └── melange.rsa.pub
├── sbom/                       # Generated, gitignored
│   ├── sbom-x86_64.spdx.json
│   └── sbom-index.spdx.json
├── packages/                   # Generated, gitignored
│   └── x86_64/
│       ├── dasel-3.3.1-r0.apk
│       └── APKINDEX.tar.gz
└── README.md

构建

使用 Make

make build        # keygen (if needed) + package + image
make test         # package tests + image tests
make all          # build + test
make clean        # remove all generated artifacts
make help         # list all targets and variables

手动命令

# 1. Generate signing keys (one-time)
docker compose run --rm melange keygen keys/melange.rsa

# 2. Build the APK package (fetches source, applies CVE patch, compiles)
docker compose run --rm melange build melange/dasel.yaml --arch x86_64 --signing-key keys/melange.rsa

# 3. Build the OCI image (consumes the local APK)
docker compose run --rm apko build apko/dasel.yaml dasel:3.3.1 dasel.tar --arch x86_64 --sbom-path sbom/

第 2 步会自动生成并签名 packages/x86_64/APKINDEX.tar.gz。

运行

加载镜像后，运行 dasel：

docker load --input dasel.tar

# Example: query a JSON file
echo '{"name": "dasel"}' | docker run --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  -i dasel:3.3.1-amd64 \
  -i json 'name'

这些标志强制执行 镜像加固 中描述的纵深防御策略的运行时层：不可变的根文件系统、零 Linux capabilities 以及无权限提升路径。

测试

使用 Make

make test          # all tests (package + image)
make package-test  # melange package tests only
make image-test    # image tests only (requires bash)

手动命令

# Package tests
docker compose run --rm melange test melange/dasel.yaml --arch x86_64

# Image tests (requires Git Bash on Windows)
docker load --input dasel.tar
bash tests/test.sh

测试脚本验证以下内容：

• 镜像可加载且 dasel version 报告 v3.3.1
• JSON 键提取（-i json 'test'）
• JSON 转 YAML（-i json -o yaml --root）
• CVE 补丁：恶意的 billion-laughs YAML 会触发 "yaml expansion budget exceeded"，而不是挂起

CVE-2026-33320 修复

该漏洞允许通过指数级嵌套的 YAML 别名（billion laughs 攻击）造成无限制的 CPU/内存消耗。melange/CVE-2026-33320.patch 中的补丁为 dasel 的 YAML 读取器添加了两项保护措施：扩展深度限制（32），用于限制递归别名嵌套；以及扩展预算（1000），用于限制每个文档的别名解引用总数。当任一限制被触发时，解码会立即返回错误。

安全性、可复现性与最小化

• 安全性：CVE-2026-33320 已在构建时修补。所有软件包均已签名。镜像仅包含 3 个 APK 软件包（wolfi-baselayout、ca-certificates-bundle、dasel）
• 可复现性：软件包和镜像均使用声明式 YAML。源码 tarball 通过 SHA256 固定。所有工具版本均已记录。Go 二进制文件使用 -trimpath 构建，以剥离本地构建路径
• 最小化：最终镜像中没有 shell、没有包管理器——只有 dasel 二进制文件、CA 证书和 baselayout

镜像加固

该镜像在最小化打包之外还应用了纵深防御：

漏洞扫描

使用行业标准工具对构建的镜像（dasel.tar）进行了扫描，以验证除 CVE 补丁本身之外的安全态势。

Syft（SBOM 生成）

Syft 通过检查 Go 二进制的模块元数据，从镜像中提取了 36 个软件包：

• 3 个 APK 软件包：wolfi-baselayout 20230201-r29、ca-certificates-bundle 20260413-r0、dasel 3.3.1-r0
• 32 个 Go 模块：包括 go.yaml.in/yaml/v4、github.com/hashicorp/hcl/v2、github.com/pelletier/go-toml/v2、github.com/goccy/go-json、github.com/charmbracelet/bubbletea、golang.org/x/sys、golang.org/x/text、stdlib go1.25.9，以及另外 25 个
• 19 个文件已清点：/usr/bin/dasel、/etc/ssl/certs/ca-certificates.crt、APK 数据库、各软件包的 SBOM 以及 baselayout 配置文件

Grype（漏洞扫描器）

我生成的 SBOM 已使用 Grype 进行了检查，在全部 32 个 Go 模块或 3 个 APK 软件包中没有发现其他漏洞。

提交

假设

• 仅 x86_64 - 单架构构建。多架构需要额外的 --arch 参数
• 一次性签名密钥 - 在本地生成并被 gitignore。在生产环境中，私密签名密钥应存储在密钥管理器中，而不是本地文件系统上，因为即使被 gitignore 的文件也可能通过备份工具、容器卷挂载或受感染的工作站暴露。
• Wolfi OS 依赖 - 构建和最终镜像都依赖于 Wolfi 软件包（busybox、go、ca-certificates-bundle）。如果这些上游软件包中的任何一个被发现漏洞，也会影响此镜像。在生产环境中，需要保持 Wolfi 软件包更新或订阅其安全公告。
• Docker Compose 包装器 - melange 和 apko 通过 compose.yaml 作为 Docker 容器运行。这是在 Kali 2025.3 上开发的，并在装有 Docker Desktop 29.3.1 的 Windows 10 上验证通过。
• 测试脚本需要 bash - tests/test.sh 使用 timeout（coreutils）和 Docker CLI。所有其他命令都是纯 docker 命令，可以在 PowerShell 或 CMD 中运行。在 Windows 上，请从 Git Bash 运行测试脚本（参见 Windows 要求）。

SBOM 覆盖缺口

apko 会在构建时自动生成 SPDX SBOM 到 sbom/ 文件夹（sbom/sbom-x86_64.spdx.json、sbom/sbom-index.spdx.json）。这些 SBOM 记录 3 个已安装的 APK 软件包，包括版本、CPE、来源出处和 Melange 构建定义引用。但是，它们不包含编译进 dasel 二进制的 Go 模块依赖。我决定对它们进行扫描，并使用 Syft 通过提取二进制内嵌元数据中的全部 32 个 Go 模块来填补这一缺口。

对于生产环境，应该有某种 SBOM 提取的自动化，定期轮询。然后可以用类似我用 Golang 编写的 https://github.com/nedlir/CVEnotifier 的工具附加 SBOM 结果，以发现供应链中的新型漏洞。

执行的命令和结果

未来的改进

• 多架构构建 - 支持构建此容器的多种架构。

• CI/CD 流水线 - 在 GitHub Actions 中使用 melange/apko 容器操作自动化构建和测试

• 在 melange 中生成 Go 级 SBOM - 在 melange 构建流水线期间运行 syft，并将 Go 模块 SBOM 与 APK 一起嵌入