# 脆弱性対応の省力化 {#patching}

ベースイメージに脆弱性の修正が出たとき、利用者側の作業は、イメージを pull し直すことです。
Takumi Images は、上流の依存関係が更新されるたびに、該当イメージを再ビルドし、再スキャンします。
そのため、最新タグを pull し直せば、その時点で存在するパッチの適用はすでに完了しています。

この挙動は、`:latest` が指す digest を実際に確認すると具体的に把握できます。
`:latest` はタグであり、その指す先は再ビルドのたびに変わるからです。
たとえば curl イメージのタグが指す digest は、次のように確認できます。

```bash
$ crane digest images.flatt.tech/takumi/curl:latest
sha256:<digest>
```

curl の依存関係に修正が入って再ビルドされれば、同じコマンドは別の digest を返すようになります。
デプロイの挙動を固定したい場合は、その時点の digest を控えて `@sha256:...` の形で参照すれば、以後の再ビルドの影響を受けません。
反対に、修正を追従し続けたい場合は `:latest` を使い、定期的に pull し直す運用にします。

digest 固定と `:latest` 追従を具体的にどう使い分けるかは、[クイックスタートの digest 節](/docs/ja/t/images/quickstart#pin)を参照してください。

## 修正が届く2つの経路 {#how-fixes-land}

修正が届く経路は、2つあります。

ひとつは、ビルドの土台にしている固定ソース（pin）を新しい版へ進める経路です。
pin はカタログ全体で共有しているので、1 回進めることで、そのパッケージを使うすべてのイメージに修正が届きます。

もうひとつは、修正が上流にはあるものの、pin にはまだ取り込まれていないときに、そのパッケージだけへパッチ（overlay と呼びます）を当てる経路です。
overlay は、そのパッケージが現れるすべてのイメージに適用されるので、次の pin 更新を待つ必要はありません。
当てたパッチの中身は、そのイメージの SBOM の `pedigree.patches` に diff としてそのまま残ります。

どちらの経路も、利用者の側で個別のイメージにパッチを当てる作業を必要としません。
仕組みの詳細は[既知脆弱性への対応](/docs/ja/t/images/architecture/known-vulnerability-patching)を参照してください。

## 一般的な配布形態で背負う判断 {#typical-burden}

コンテナイメージを利用者側で運用すると、ベースイメージについて確認しておくべきことが増えます。
Takumi Images では、その判断を弊社の運用として引き受けます。

| 確認事項             | 一般的な配布形態                                                                                 | Takumi Images                                                                                    |
| -------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ |
| 修正の反映速度       | 公式イメージの更新が、パッケージ本体の修正より遅れることがあります。                             | 依存関係の更新にあわせて再ビルドするため、pull し直せば修正は反映済みです。                      |
| 提供元の管理体制     | 公式イメージがなく、非公式イメージの管理体制を利用者自身が評価しなければならないことがあります。 | 弊社が一貫して管理するカタログとして提供します。                                                 |
| ベースイメージの中身 | 不要なパッケージやツールが混入していないかを、利用者側で確認する必要があります。                 | [distroless](/docs/ja/t/images/features/distroless) な最小構成で、実行に不要なものを含みません。 |
| ビルド時刻の把握     | いつビルドされたイメージかを、利用者側で確認する必要があります。                                 | ビルドとスキャンの時刻がカタログ上に記録されます。                                               |

右列はどれも、利用者が個別のイメージについて調べる作業ではなく、カタログ全体に対する弊社側の運用です。

## 補足: トリアージの透明性 {#transparent-triage}

修正が公開される迄の間に残る検出結果も、無理な 0-CVE 化を避けるため、判断の根拠つきで残置します。このような判断の記録は、[VEX](/docs/ja/t/images/features/attestations/vex)として公開しているので、実際に対応が必要なものだけを、利用者側でも確認できます。