ローカル推論ソフトの更新を、「当てた」で終わらせずに検算できる形で残す方法を書きます。
観測する項目は、修正の公開から適用までの日数です。
記録するのは、版、適用日、到達確認の結果、そして分子と分母です。

なぜ「公開から適用までの日数」を観測するのか

LiteLLMは2026年10月27日の公式ブログ（Director of Security・CEO・CTOの連名）で、こう書いています。

この前提に立つと、修正の公開日が攻撃の始まりになります。
なので僕は、公開から適用までの日数を観測項目にします。

ただし、パッチ差分からAIで脆弱性を特定する攻撃が実際に増えた、という数字はブログにありません。
観測した件数や事例も示されていません。
言えるのは「当事者がそう判断して、配り方を変えた」までです。

同じ月に出たローカル推論ソフトの修正

同じ10月には、ローカル推論で使うソフトにも修正が出ています。
悪用の手順はここでは扱いません。

ソフト	CVE	概要	対象範囲	修正版	公開
Ollama	CVE-2026-103663	/api/pullのパストラバーサル	0.34.2以上0.35.0未満	0.35.0	CERT Polska、10月8日
llama.cpp	CVE-2026-107183	llama-serverのuse-after-free	b8227以上b11393未満	b11393	VulnCheck、10月7日

手元で動かしているから安全、ではありません。
手元で動かしているなら、更新するのも自分たちです。

1件の修正につき、1行を残します。

率だけを書かず、適用済み / 対象ホスト の形で書きます。
分母が分からないまま「全台適用」とは書けません。
分母と分子の差には、必ず未適用の理由を書きます。

LiteLLMはブログで、うまくいかなかったことも3つ挙げています。

修正を作るより、届けて当ててもらうほうが難しかった。
これを手順の側に置き換えると、記録が効くのは「届いたか」「当たったか」の確認です。
この記録で分かるのは、数えたホストの状態までです。
数えていないホストのことは分かりません。

何日以内が妥当かは、使い方と、外から届くかどうかで変わります。
判断するのは、運用する人です。

Cor.はISO/IEC 27001について、2026年10月に第2段階審査を終え、2026年12月ごろの認証登録を見込んでいます。
推論ソフトの更新を、担当・期限・記録の枠に入れる話は、その運用と同じ線の上にあります。

以下は参考にした資料であり、認証・適合を示すものではありません。