# 上流のゼロデイ修正検知 {#upstream-zeroday-detection}

Takumi Images は、上流ソースの差分から、まだ脆弱性 ID として公表されていない修正の兆候を探し、公表を待たずに更新へ反映することを目指しています。

## 同じ監視基盤で逆向きに問う {#same-monitoring-inverse-question}

[上流のマルウェア検知](/docs/ja/t/images/architecture/upstream-malware-detection)で使う監視の仕組みは、逆向きの問いにもそのまま使えます。
上流ソースの差分を継続的に取得している以上、その差分に「まだ CVE や GHSA などの脆弱性 ID として公表されていない修正」が含まれていないかも、同じ材料から調べられます。

## サイレントフィックスという空白期間 {#silent-fix-gap}

セキュリティ修正は、脆弱性 ID としての公表より先に、ただのコミットとして上流に現れることがしばしばあります。
これを**サイレントフィックス**（silent fix）と呼びます。
公表前のこの期間、公開済みの脆弱性 ID をもとに動くスキャナはまだ何も検知できません。
イメージの側がこの修正にまだ追従していなければ、公表されるまでのあいだ、この空白期間の影響を受け続けます。

## 差分からの検知 {#detection-from-diff}

取得した差分は AI で解析し、脆弱性修正に特徴的な兆候を探します。
境界チェックの追加、入力検証の強化、メモリ操作の修正といった特徴が見つかれば、そのコミットをセキュリティ修正の候補として扱います。
候補が見つかったときは、脆弱性 ID としての公表を待たずに、該当パッケージの更新を優先します。
更新そのものは、[既知脆弱性への対応](/docs/ja/t/images/architecture/known-vulnerability-patching)と同じ経路（pin の前進、または overlay によるパッチ）で届きます。

サイレントフィックスに特徴的な差分は、たとえば次のような形を取ります（説明のための一例であり、実在の脆弱性 ID や実際のコミットではありません）。

```diff
 int copy_header(char *dst, const char *src, size_t len) {
-  memcpy(dst, src, len);
+  if (len > MAX_HEADER_LEN) {
+    return -1;
+  }
+  memcpy(dst, src, len);
   return 0;
 }
```

コミットメッセージに `CVE` や `security` の語がなくても、境界チェックの追加そのものが、修正前は長さを検証せずにコピーしていた（バッファオーバーフローを起こしうる）ことを示唆します。
AI による解析は、こうした変更の前後を比較して、脆弱性修正である可能性を判定します。

## 利用者にとっての意味 {#implication-for-users}

条件がそろえば、脆弱性 ID が公表されスキャナが検知するより前に、修正済みのイメージがすでに提供されている状態になり得ます。
ただし、これは検知した候補が正しく判定され、更新が実際に間に合った場合の話であり、常にそうなると約束できるものではありません。
脆弱性対応の全体像は[脆弱性対応の省力化](/docs/ja/t/images/features/patching)にまとめています。