dasel v3.3.1 強化コンテナ

これは、dasel v3.3.1 のビルド時に CVE-2026-33320（YAML エイリアスの無制限展開）のパッチを適用した melange パッケージおよび apko コンテナイメージです。イメージはすべてローカルで生成された APK から構築されており、事前にビルドされた上流イメージは使用していません。

前提条件

• アーキテクチャ: x86_64 のみ
• 初期ビルドにはインターネットアクセスが必要（ソースの tarball、Go モジュール、Wolfi パッケージを取得）

Windows の要件

すべてのビルドおよびロードコマンドは任意のターミナル（PowerShell、CMD、bash）から実行できます。ただし、1つのステップでは Unix シェルが必要です。

• 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/                       # 生成ファイル、gitignore 対象
│   ├── melange.rsa
│   └── melange.rsa.pub
├── sbom/                       # 生成ファイル、gitignore 対象
│   ├── sbom-x86_64.spdx.json
│   └── sbom-index.spdx.json
├── packages/                   # 生成ファイル、gitignore 対象
│   └── x86_64/
│       ├── dasel-3.3.1-r0.apk
│       └── APKINDEX.tar.gz
└── README.md

ビルド

Make を使用

make build        # keygen（必要な場合）+ パッケージ + イメージ
make test         # パッケージテスト + イメージテスト
make all          # ビルド + テスト
make clean        # 生成されたアーティファクトをすべて削除
make help         # すべてのターゲットと変数を表示

手動コマンド

# 1. 署名鍵の生成（一度だけ）
docker compose run --rm melange keygen keys/melange.rsa

# 2. APK パッケージのビルド（ソースを取得、CVE パッチ適用、コンパイル）
docker compose run --rm melange build melange/dasel.yaml --arch x86_64 --signing-key keys/melange.rsa

# 3. OCI イメージのビルド（ローカル 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

# 例: JSON ファイルのクエリ
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 ケーパビリティ、権限昇格パスなし。

テスト

Make を使用

make test          # 全テスト（パッケージ + イメージ）
make package-test  # melange パッケージテストのみ
make image-test    # イメージテストのみ（bash が必要）

手動コマンド

# パッケージテスト
docker compose run --rm melange test melange/dasel.yaml --arch x86_64

# イメージテスト（Windows では Git Bash が必要）
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 リーダーに2つの保護策を追加しています。再帰的なエイリアスのネストを制限する展開深度制限（32）と、ドキュメントあたりのエイリアス展開総数を制限する展開予算（1000）です。どちらかの制限に達すると、デコードが即座にエラーを返します。

セキュリティ、再現性、最小性

• セキュリティ: CVE-2026-33320 はビルド時にパッチ適用済み。すべてのパッケージは署名済み。イメージには 3 つの APK パッケージのみ（wolfi-baselayout、ca-certificates-bundle、dasel）
• 再現性: パッケージとイメージの両方に宣言的な YAML を使用。ソース tarball は SHA256 で固定。すべてのツールバージョンが文書化。Go バイナリは -trimpath でビルドされ、ローカルビルドパスを除去
• 最小性: 最終イメージにシェルやパッケージマネージャなし - 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 DB、パッケージごとの 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）。これらは、インストールされた3つの APK パッケージをバージョン、CPE、ソースの来歴、Melange ビルド定義の参照とともに追跡します。ただし、dasel バイナリにコンパイルされた Go モジュールの依存関係は含まれていません。私はそれらをスキャンすることを決め、Syft を使用してバイナリの埋め込みメタデータからすべての32の Go モジュールを抽出することでこのギャップを埋めました。

本番環境では、SBOM 抽出を自動化し、定期的にポーリングする必要があります。そして、SBOM 結果を、サプライチェーン内の新たな脆弱性を見つけるために私が Golang で書いた https://github.com/nedlir/CVEnotifier のようなものに添付するかもしれません。

実行コマンドと結果

将来の改善点

• マルチアーキテクチャビルド - このコンテナの複数アーキテクチャ対応をサポート

• CI/CD パイプライン - GitHub Actions で melange/apko コンテナアクションを使用してビルド＋テストを自動化

• melange での Go レベル SBOM - melange ビルドパイプライン中に syft を実行し、Go モジュールの SBOM を APK と一緒に埋め込む