責任共有モデル

Takumi Images は、安全なベースイメージを運用するための作業を減らします。 ただし、すべての責任が弊社に移るわけではありません。 ベースイメージのサプライチェーンには、ソフトウェア本体を開発する上流プロジェクト、それを検証してイメージとして提供する弊社 (GMO Flatt Security)、イメージの上にアプリケーションを載せて動かす利用者の三者がいます。 責任の境界も、この三者の間に引かれます。

全体像

三者の分担は次の表のとおりです。

領域	上流プロジェクト	Takumi Images (弊社)	利用者
ソフトウェア本体	開発と脆弱性修正の提供	修正の監視と取り込み	なし
ベースイメージ成果物	なし	ビルド、パッチ、テスト、署名、公開	イメージの選定と検証
追加レイヤー	なし	なし	アプリケーションコードと依存関係の保守
実行環境	なし	なし	secret、network、volume、権限などの設定
更新	修正のリリース	更新済みビルドと証跡の公開	digest の更新、検証、ロールアウト
ライフサイクル	サポート期限 (EOL) の決定	サポート中バージョンへのパッチ提供	EOL 前のバージョン移行

上流プロジェクトの責任

ソフトウェア本体を開発し、修正を提供するのは上流プロジェクトです。 イメージに含まれる curl や OpenSSL のようなソフトウェアは、弊社が開発しているものではありません。 脆弱性修正の一次的な供給元は上流であり、弊社が適用するパッチも上流の修正を土台にしています。

この構造には二つの帰結があります。

第一に、上流のサポート期限がそのままイメージの限界になります。 上流バージョンが EOL に達すると、パッチの土台になる修正が止まるため、弊社もそのバージョンの新しいパッチ済みビルドを原則として公開しません。 詳しくは 上流 EOL への対応 を参照してください。

第二に、ソフトウェア本体の挙動に起因するバグは上流の責任範囲です。 イメージへのパッケージングに起因する問題との切り分けは イメージの不具合 で説明します。

ただし、弊社は上流の成果物を無条件に信頼するわけではありません。 上流から取り込む前の監視と検証は、次に述べる弊社の責任範囲です。

Takumi Images (弊社) の責任

弊社が責任を持つのは、上流の成果物を検証して取り込み、images.flatt.tech で公開する digest の成果物にするまでの工程です。 具体的には、次の範囲を扱います。

• イメージに入る上流ソースを継続的に監視し、悪意ある変更の兆候や未公表の修正を検査すること。
• 上流の修正を、pin の更新またはパッケージ単位のパッチとしてイメージに反映すること。
• 固定した入力からイメージをビルドすること。
• 本番イメージを distroless な構成に保つこと。
• 公開前にイメージをテストすること。
• 署名、SBOM、SLSA Provenance、VEX を付与すること。
• 更新のたびに再ビルドと再スキャンを行い、更新済みビルドを公開すること。

この範囲には、上流側と利用者側の二つの境界があります。

上流側の境界は、上流の修正の有無です。 上流が修正を提供していない脆弱性を、弊社が単独で恒久的に修正し続けることはできません。 深刻な脆弱性について上流のリリース前に先行パッチを適用することはありますが、これは個別判断であり、すべての脆弱性への一律の約束ではありません。

利用者側の境界は、公開された digest の成果物です。 SBOM、Provenance、VEX はその成果物についての証跡であり、利用者が後から足したファイルやパッケージまでは説明しません。

利用者が追加するレイヤー

Takumi Images を Dockerfile のベースイメージとして使う場合、追加したレイヤーは弊社の管理下にはありません。 そのレイヤーに入るアプリケーションコード、パッケージ、言語依存、設定ファイル、生成物は、利用者の責任範囲です。

利用のしかた	利用者が負う責任
Dockerfile などでベースイメージとして拡張する	追加したアプリケーションと、その依存関係の保守
イメージをそのまま実行する	実行時の設定、シークレット、デプロイ設定などの運用

この違いはスキャン結果の見方にも影響します。 Takumi のベースイメージに含まれるコンポーネントの検出結果は、Takumi の再ビルド、パッチ適用、VEX の対象です。 一方、利用者のアプリケーションが追加した依存関係の検出結果は、利用者側のアプリケーションサプライチェーンに属します。

実行環境とデプロイ設定

Takumi Images は、コンテナが実際に動く環境までは制御しません。 Kubernetes manifest、seccomp や AppArmor の profile、Linux capability、volume mount、secret、network policy、resource limit などのデプロイ設定は、利用者の責任範囲です。

distroless なイメージは、コンテナ内で利用できる道具を減らします。 しかし、それは実行環境の hardening を置き換えるものではありません。 たとえば、機密性の高い host path を mount したり、不要な権限で実行したりするリスクは、イメージ本体ではなくデプロイ環境から生じます。

更新運用

Takumi は更新済みのイメージを公開しますが、実際のデプロイをいつそのイメージへ進めるかは利用者が決めます。 本番利用では、digest でデプロイ対象を固定し、Renovate や Dependabot のような更新ツールで digest 更新の提案を作り、CI と段階的なロールアウトを通してから反映することを推奨します。

古い digest を長期間固定したままにすると、新しいビルドに入った修正を受け取れません。 一方で、:latest を無検証で追随すると、自分の環境での回帰を見逃すおそれがあります。 digest で固定しつつ、固定する digest を定期的に更新し、更新ごとに検証する運用が前提です。

digest の更新に加えて、バージョンの移行も利用者の判断です。 上流 EOL が近づいたバージョンを使っている場合は、EOL 到達を待たずにサポート中のバージョンへ移行してください。