修正計画と修正PRの開発

状態: 最小版の実装を完了
開始日: 2026年10月8日
最終更新: 2026年10月15日

目的

脆弱性を通知するだけでは、利用者が直し方を調べ、変更を用意する手間は減らない。稼働中のコンテナのスキャン結果を起点に、直し方の候補を自動で選び、修正計画として通知する。

明示的に有効にした場合は、GitHub に修正の PR を作る。PR の本文には、元と候補を同じ条件で再スキャンし、消える・残る・新たに出る所見を比較して載せる。ソース上で直る見込みと、本番のイメージで直ったことは分けて示す。

方針

最小限の範囲を一通り動く形で作る
- 最小版では Compose のタグ、Dockerfile のベースイメージ、言語パッケージを対象に修正計画から PR までをつなぎ、使ってもらった反応で対象を広げる
- 利用者のセットアップを増やさないため、既存の依存更新ツールに頼らず KestreLynx 自身で作る
他人のコードを動かさない
- 依存の更新にソースのビルドなどが必要なら、自動処理せず手動での対応にする
確認できた範囲を超えて「直った」と扱わない
- 比較できないものは比較不能とし、所見が消えたとは判断しない
- ソース上の修正見込みを、本番での解消として扱わない

調査内容

Renovate と Dependabot が PR を作る仕組みを、公式ドキュメントとソースで確認した。

どちらも、依存の抽出、新しい版の検索、ファイルの書き換え、必要な lockfile の作り直し、ブランチとコミットの作成、PR の作成という流れを持つ。lockfile は、依存として実際に使うパッケージと版を記録するファイルである。Renovate の処理の流れ

観点	Renovate	Dependabot
PR の重複と閉鎖	ブランチ名などで既存の PR を照合し、閉じられた PR と同じ更新は原則として作り直さない	ブランチ名などで重複を防ぎ、特定の更新を止めるときは PR へのコメントのコマンドで指定する
パッケージマネージャーの実行	Renovate 自身と同じ権限で動かす	GitHub への書き込み権限を持たない使い捨ての環境で動かし、通信先を制限する
コンテナイメージ	Docker・Compose のタグ更新を扱うが、イメージの脆弱性を起点にした PR には対応しない	Docker・Compose のタグ更新を扱うが、イメージの脆弱性を起点にした PR には対応しない

PR の扱いと実行権限は、Renovate の PR の説明、Renovate の権限の説明、Dependabot の通信先制限の説明にも記載されている。

間接的に入る依存の更新には制約がある
- あるパッケージを入れた結果、そのパッケージが必要とする別のパッケージも入る関係を、推移的な依存と呼ぶ
- 両ツールとも原則として、依存の定義で許された範囲内で lockfile を更新するところまでを扱い、親のパッケージを上げる対応は Dependabot の npm に限られる
lockfile の作り直しでも他人のコードが動くことがある
- Python のソース配布物をビルドする場合など、版の一覧を更新するだけに見える処理でもコードが実行されることがある

親のパッケージの更新に関する制約は、Dependabot のセキュリティ更新の説明で確認できる。

決定事項

対象と有効化

項目	対象・扱い
実行環境	Docker Compose
修正先	GitHub、リポジトリを絞ったトークンでアクセスする
配布元	公開のコンテナイメージ、公開の npm と PyPI
Dockerfile のベースイメージ	自分でビルドするイメージが使う公開のベースイメージ
言語パッケージ	Node.js の npm・pnpm、Python の pip・uv
修正計画の通知	読むだけの機能として有効にする
PR の作成	書き込みを伴う機能として、修正計画とは別に明示的に有効にする

配布イメージの候補

postgres:16 や latest は、同じタグのまま新しい中身を指すことがある。こうした書き方と、nginx:1.25.3 のように版を固定した書き方で、候補の選び方を分ける。

書き方	候補	通知・PR
`postgres:16`、`latest` など	同じタグの新しい中身	再スキャンして「pull し直すと直る所見」を通知し、ファイルが変わらないため PR は作らない
`nginx:1.25.3` など	同じメジャー・マイナーの最新のパッチ版で、接尾辞が同じもの	タグを書き換える PR を作る

Dockerfile のベースイメージ

個人開発のイメージは、Compose の build: でローカルの Dockerfile からビルドされることが多く、Compose のタグ更新の対象にならない。ベースイメージのレイヤーにある所見は言語パッケージの更新では直らないため、Dockerfile のベースイメージの更新を最小版に含める。

Compose の対応付けがあれば、build: から Dockerfile とビルド対象のステージを見つけるため、追加の設定はいらない。対象ステージは target の指定があればそのステージ、省略時は最後のステージとする。FROM が前のステージを指す場合は、公開のベースイメージを指す FROM までたどり、そのタグだけを更新する。

書き方	候補	通知・PR
`python:3.12.3-slim` など、版を固定したタグ	同じメジャー・マイナーの最新のパッチ版で、接尾辞が同じもの	`FROM` のタグを書き換える PR を作る
`python:3.12-slim` など、中身が動くタグ	更新候補は作らない	PR の作成と件数の比較は行わず、`docker compose build --pull` などで最新のベースを取得してビルドし直す手順だけを案内し、改善を確認したとは扱わない

稼働イメージのレイヤーの先頭がベースイメージのレイヤーと一致する場合だけ、そのベースから作られたものとして比較する。所見ごとに Trivy が報告するレイヤーを使い、確認済みのベースのレイヤーにある所見をベース由来の候補として扱う。後段のレイヤーにある所見や、レイヤーが報告されない所見は対象に数えない。

言語パッケージとソースとの対応

利用者が設定でリポジトリとファイルを指定し、スキャン結果にある名前と版を照合する。一致したものは修正先の候補として扱い、名前と版の一致だけでビルド元と確定しない。候補が複数あるものは手動での対応にする。

対象	扱い
推移的な依存	依存の定義の範囲内での lockfile 更新に限る
範囲内で直らない推移的な依存	「手動での対応が必要」と通知する
pip で `==` により版を固定した行	版を書き換える PR の対象にする
pip で範囲を指定した行	「ビルドし直せば直る見込み」と通知する
ソース配布物のビルドや、手元のフォルダー・Git のリポジトリを指す依存など、他人のコードを動かす必要があるもの	手動での対応にする

直接依存の名前や許可する版を記述する package.json、pyproject.toml などのファイルを manifest と呼ぶ。lockfile が実際に使う版を記録するのに対し、manifest は使ってよい版の条件を記録する。

修正版の情報から、少なくともどの版まで更新するかを決める
- 稼働中のイメージの所見から、修正版があることを示すスキャン状態 fixed と、具体的な修正版の情報がそろっているものを選ぶ
- 所見ごとに、報告された修正版のうち、稼働中の版より新しい最小の版を選ぶ
- 同じパッケージに複数の所見がある場合は、それぞれについて選んだ版のうち最も新しいものを、更新先の下限とする
- 修正版の情報がない所見はこの選定に含めず、更新先を選んだだけでは脆弱性の解消を確認したことにしない
- PR の作成が有効な場合は、更新後の依存関係のファイルを別途検査し、更新前後のスキャン結果から修正しようとした脆弱性が検出されなくなったことを確かめる
- 更新によってメジャー版が変わる場合は、PR 本文と通知に注意を記載する
直接依存の版の指定が修正版を許さない場合は、その指定も書き換える
- KestreLynx が manifest を編集し、== や ^ など、版の条件を表す記号を維持したまま版の部分だけを書き換える
- uv の urllib3 ==1.26.4 から ==2.8.0 への更新のように、固定した版では修正版を使えない場合もこの方法で対応する
- npm・pnpm は 1.2.3・=1.2.3・^1.2.3・~1.2.3、uv は ==・~= の書き方に対応し、それ以外の書き方で編集が必要な場合は手動での対応にする
パッケージマネージャーごとの制約に合わせて、自動更新できる範囲を決める
- pnpm の推移的依存の更新
  - pnpm 11 以降は推移的依存の更新時に版を指定できないため、版を指定せずに更新し、実際に選ばれた版を検査する
- pnpm が自動で追加する設定ファイル
  - pnpm には公開から24時間以内の版を避ける既定の制限があり、その期間内の版を入れる際には、例外を認める設定ファイルが自動で追加されることがある
  - その設定ファイルを PR に含めず lockfile だけを更新すると、利用者の CI で同じ依存をインストールするときに制限にかかり、失敗する可能性がある
  - このように、あらかじめ更新で扱うと決めたファイル以外が作られた場合は、自動で PR を作らず手動での対応にする
- uv が使う Python と lockfile の形式
  - uv は lockfile を作り直す際に、プロジェクトが対応する版の Python を必要とする
  - 対応する Python の版は pyproject.toml の requires-python に記述されており、作業用イメージには Python 3.13 だけを含むため、3.13 を許さないプロジェクトは手動での対応にする
  - uv.lock は、更新時にファイル形式まで書き換わるのを避けるため、形式の改訂番号が revision 5 のものだけに対応する
- pip でのインストール可否の確認
  - 稼働中のイメージの Python の版と、OS・CPU に対応する wheel のタグを使い、依存パッケージの組み合わせを決められることを確かめる
  - wheel は Python パッケージのビルド済み配布形式で、そのタグはインストールできる環境を表す
- 依存パッケージを同梱するパッケージ
  - bundleDependencies で依存を同梱するパッケージや、依存の版を固定する shrinkwrap ファイルを同梱するパッケージが依存するものは、実際に入る版を確認できないため手動での対応にする

PR が開いている間は、更新元の依存関係のファイルが変わらず、次の実行でも同じ更新が候補になることがある。そのたびにパッケージマネージャーを動かすと、同じ変更を作り直すために時間と処理枠を使い、まだ PR のない更新に進めなくなる。このため、既存の PR で提案済みの更新は作り直さず、1回に試す更新の数と実行時間にも上限を設ける。

更新の数は、同じリポジトリ・ブランチ・ディレクトリにある、同じパッケージマネージャーの依存関係のファイルをまとめて更新する処理を1件として数える。パッケージの数や、作業用コンテナの数を数えるわけではない。

提案済みの更新を繰り返さない
- 更新元の依存関係のファイルの内容と、更新するパッケージ・現在の版・更新目標が、開いている PR を作ったときと同じなら、更新処理を省いて既存の PR に対応付ける
- 例えば minimist 1.2.5 から 1.2.8 への更新を提案する PR があり、元のファイルと更新内容が変わっていなければ、同じ変更を作り直さず、その PR を修正案として扱う
- 処理を省いた更新は、1回に試す更新件数の上限に数えない
更新件数と実行時間を制限する
- 1回の処理サイクルで試す更新件数は remediation.limits.dependency_jobs_per_cycle で設定し、既定値は3件とする
- pip の更新や manifest の編集を伴う更新では、1件の更新に複数の作業用コンテナを使うことがある
- 各コンテナの作成から実行、結果の回収までの制限時間は remediation.limits.job_timeout で設定し、既定値は6分、設定できる範囲は1分〜60分30秒とする
- コンテナの削除などの後片付けには、別途30秒の制限時間を設ける

比較と修正の確認

元と候補は、同じスキャナーと同じ脆弱性データベースの中身を使い、同じ条件で比べる。

確認できたこと	扱い
元と候補のスキャンが成功し、同じ条件で比較できた	消える・残る・新たに出る所見を示す
どちらかのスキャンが失敗した、または条件をそろえられない	比較不能とし、解消とは扱わない
ソース上で修正が見込める	本番のイメージで直ったこととは分けて示す

配布イメージの PR には、イメージを再スキャンした比較を載せる。Dockerfile のベースイメージの PR には、今のベースと候補のベースを同じ条件で再スキャンした結果を「ベースイメージ単体の比較」として載せる。Trivy のレイヤーの報告は由来の確証とはせず、ビルドし直した最終イメージは未検証であることを明記する。言語パッケージの PR では、ソース上の比較とイメージの修正見込みを示し、本番での解消を確認したとは扱わない。

更新処理の実行場所

パッケージマネージャーは使い捨てのコンテナで動かす
- KestreLynx が作業のたびに Docker の API でコンテナを作り、作業後に消す
- 作業用コンテナには、トークン・本体の設定・Docker のソケットを渡さない
権限と実行範囲を制限する
- 非 root で動かし、ルートファイルシステムを読み取り専用にして、時間と資源に制限をかける
- 出力は検査してからコミットする

この機能に伴い、KestreLynx が Docker の API で作業用コンテナを作成するようになる。

ただし、現在の実装では、Docker の設定上はルートファイルシステムを書き込み可能にしている。読み取り専用にすると、メモリー上に置く一時的なファイルシステムである tmpfs が転送先でも、Docker がコンテナへのファイル転送を拒否するためである。この挙動は Docker 29.1.3 で確認した。

その代わり、配布する作業用イメージのファイルの所有者と権限を設定し、非 root ユーザーで動く更新処理が、イメージの書き込みレイヤーのどこにも書けないようにする。書き込みレイヤーはコンテナごとのファイル変更を保存する場所だが、ここに結果を書かせると、書き込める量に上限を設けられない。このため、更新処理が書き込める場所を、容量を制限した tmpfs に限定する。

remediation.worker.image で別の作業用イメージを指定する場合も、同じ所有者と権限の制約が必要である。イメージの指定形式や、中身を識別するハッシュ値である digest は検証するが、それによってイメージ内の全ファイルの権限まで実行時に検査するわけではない。

ツールの版を固定し、書き込み先を制限する
- Node.js 24.21.0、npm 11.19.0、pnpm 12.10.1、Python 3.13.16、pip 26.2.1、uv 0.13.0 を含む専用イメージを、digest で中身を固定して使う
- 更新元のファイルはコンテナの起動前に root 所有の作業ディレクトリへ置き、更新処理からは読み取りだけを許可する
- 配布する作業用イメージの所有者と権限の設定により、非 root ユーザーの書き込み先を容量制限付きの tmpfs に限定する
- パッケージマネージャーはパッケージに含まれるスクリプトの実行を無効にして動かし、トークン・KestreLynx 本体の設定・Docker ソケットを渡さない
- remediation.worker.image には、digest を含むイメージの指定だけを受け付ける
結果は標準出力から回収する
- 更新処理は結果を標準出力に書き、KestreLynx が処理の終了後にコンテナのログから読み取る
- 結果を回収したらコンテナの削除を試み、その後に KestreLynx が回収した結果を検査する
- 削除に失敗した場合は記録して後の後片付けで再試行し、結果を回収できていれば検査を続ける場合がある
作業用コンテナの出力をそのまま信用せず、KestreLynx が検査する
- 変更された依存パッケージについて、公開の npm・PyPI の配布サービスである registry が示す配布物の URL と、中身の一致を確認するための integrity または SHA-256 の値を照合する
- 更新するパッケージが依存関係のファイル内に複数回記録されている場合は、すべての記録で修正版以上になっていることを確かめる
- manifest は KestreLynx が編集した箇所以外に変更がなく、依存関係の差分も、修正しようとしたパッケージの更新によって説明できることを確かめる
- 更新前後の依存関係のファイルを、同じ脆弱性データベースを使って Trivy のファイル検査機能である fs スキャンにかけ、修正しようとした脆弱性が消えたことを確かめる
- 出力の大きさと検査にかける処理量に上限を設ける
検査で確認できることと、保証できないことを示す
- 対応するファイル形式で検出できる、版や配布物の情報と registry の情報との不一致は、検査で拒否する
- 作業用コンテナが使う資源、読み込むファイルや出力の大きさ、KestreLynx 本体の処理量に上限を設ける
- 作業用コンテナでの処理の失敗、結果の一部しかない出力、個々の手順の結果と全体の成功・失敗の食い違いは、更新成功として扱わない
- 依存パッケージの組み合わせが registry の宣言と完全に一致することと、出力ファイルがインストーラに受け付けられる形式であることは、可能な範囲で検査するが保証はしない
- この確認範囲の限界を PR 本文の Not verified（未検証）に記載し、lockfile を使ってインストールする利用者の CI を最後の確認とする

PR の作成と置き換え

項目	扱い
作成方法	リポジトリを clone せず、GitHub の API でコミットと PR を作る
既存のブランチ	上書きしない
新しい候補	新しい PR で出す
古い PR	新しい PR が修正対象をすべて引き継ぐときだけ閉じる
同じファイルの複数の箇所	まとめて1つの PR にする
マージと本番への反映	自動では行わない

実装後に変わった点

修正計画と修正 PR は、修正関係モデルの考え方の一部を使っており、モデルの型をそのまま実装したものではない。

更新処理の実行環境

公式イメージとツールの取得
- 専用イメージを廃止し、中身を固定した公式 Node・Python イメージに KestreLynx の作業プログラムを渡す方式に変更
- npm・pnpm・uv はプロジェクトが指定する版を KestreLynx が取得・照合し、キャッシュから再利用するときも検査する
- 版の指定に矛盾がある場合や、未対応の指定、サポートが終了した実行環境だけを要求する場合は手動での対応にする
書き込み先の制限
- 専用イメージの権限設定に代えて、書き込み先を容量制限付きの一時領域に封じ込め、実行時にも制限を検査する

言語パッケージの更新方法と対象

lockfile の作り直し
- npm・pnpm は更新対象の記録を取り除いて lockfile を作り直す方式に変更し、この方式に対応できない pnpm 12 は手動での対応にする
- uv は更新対象ごとに更新先の版を指定する
- 更新に伴う依存先や注記の変更も、検査で説明できる範囲で許可し、PR 本文に示す
設定ファイルのある pnpm プロジェクト
- pnpm 10 以降で、ビルドを許可するパッケージや対応する CPU などの設定だけを書いた pnpm-workspace.yaml があるプロジェクトも更新対象にする
- 複数のパッケージをまとめる workspace の定義や、未対応の設定がある場合は引き続き手動での対応にする
部分 PR
- npm・pnpm・uv は、依存の指定の制約などで脆弱性を直した版まで上げられないパッケージを除き、検証に通った更新だけで PR を作れるようにする
- 除外したパッケージは手動での対応として示し、pip の更新は部分化しない

イメージの候補の探し方

公開イメージに限る制約を改め、非公開のイメージレジストリへの認証に対応する
タグの取得を対象系列に絞って効率化しつつ、不完全な一覧から候補を選ばない
ローカルビルドの稼働イメージは配布元への問い合わせ前に除外し、判定できない場合も配布元を推測して検索しない

Slack の通知

修正計画を脆弱性通知から独立したメッセージにし、部分 PR から除外したパッケージや手動での対応が必要な内容も示す

PR 本文の整理と日本語化

言語パッケージの PR は実行・検査の結果と利用者の CI での確認の案内を中心にし、Not verified や理由の節を削除する
Dockerfile の PR はベースイメージ単体の比較とレイヤー帰属の限界を示し、「最終イメージは未検証」という明示文を削除する
通知の言語設定を PR 本文にも適用し、日本語で表示できるようにする

検証結果

npm・pnpm・uv・pip の言語パッケージを更新する PR の作成を実装した。Compose のタグと Dockerfile のベースイメージの更新と合わせて、最小版で予定した範囲の実装がそろった。

Compose のタグ更新

検証用の GitHub リポジトリで Compose のタグを更新する PR の動作を確認した
- 対象のタグの行だけを書き換える PR ができる
- 繰り返し動かしても PR が重複しない
- 閉じた PR と同じ更新は、ブランチを消しても作り直さない
- 利用者が手を入れたブランチに触らない
- ローカルの記録を失っても PR 本文の印から記録を復元する
- 読み取りだけの権限では書き込みが失敗し、何も残らずに通知される

以前の作業用イメージでの言語パッケージ更新

検証用の GitHub リポジトリで言語パッケージを更新する PR の動作を確認した
- 次の更新で計4件の PR を作成した
  - npm・pnpm それぞれで、推移的依存の minimist 1.2.5 から 1.2.8 への更新
  - pip で、配布物を照合するハッシュ値を記載した urllib3 1.26.4 から 2.8.0 への更新
  - uv で、manifest の編集も伴う urllib3 ==1.26.4 から ==2.8.0 への更新
- 繰り返し実行しても PR は重複せず、更新元のファイルや更新内容が変わらなければ、更新処理も再実行されなかった
- 作業用コンテナは脆弱性スキャンの対象に含まれず、毎回削除された
実際のプロジェクトに近い規模の依存関係で確認した
- express と axios、vite、fastapi と httpx、requests を使う依存関係で古い推移的依存を更新し、8件中7件が PR の候補になった
- 残る1件は uv 自身が依存パッケージの組み合わせを決められず、手動での対応になった
- これらの検証では、正しい出力を検査が拒否した例はなかった
エミュレーションでの arm64 の動作を確認した
- x86_64 上で別の CPU の動作を再現する QEMU を使って arm64 の作業用イメージをビルドし、4種のパッケージマネージャーで更新結果が同じになることを確かめた

公式イメージとツールの取得を使う方式での確認

実際に運用しているプロジェクトで確認した
- バックエンドとフロントエンドの依存ファイルを使い、宣言された pnpm 10.34.4 の取得から公式 node:24 での更新、出力の照合とソースの再スキャンまでを確認した
- 設定だけを書いた pnpm-workspace.yaml があるプロジェクトの更新と、脆弱性を直した版まで上げられないパッケージを除いた部分更新を確認した
- 本番運用で修正 PR の作成とマージまでを確認した

以前の作業用イメージでの4種のパッケージマネージャーや QEMU の検証結果は、今の方式で同じ範囲を確認した記録には含めない。

プロジェクトの宣言に合わせた実行環境の選定

npm・pnpm が使う Node.js をプロジェクトの宣言から選ぶ
- .nvmrc・.node-version・engines.node・devEngines.runtime・engines.runtime を読み取り、パッケージマネージャーの条件も満たす作業用イメージを選ぶ
- 版ファイルがあればその系列、範囲指定だけなら条件を満たす最も古いサポート中の系列、宣言がなければその時点で LTS に入っている最新の系列を優先する
- 追加・変更した依存の engines.node が、プロジェクトの宣言で許された最低の Node.js の版を許すかを確かめ、許さなければ手動での対応にする
uv・pip の処理をプロジェクトや稼働イメージの Python に合わせる
- uv は .python-version と requires-python の条件を満たす最も古いサポート中の Python の系列を選ぶ
- pip は依存解決の検証対象を稼働イメージの Python に合わせ、Python 3.10 以下なら手動での対応にする
同梱の表にあるサポート中の系列をすべて対象にする
- 対象は現時点で Node.js 22・24・26、Python 3.11〜3.15 とし、サポートが終了した系列での更新は手動での対応にする
- 新しい系列は、その系列での結合テストが通ってから表に加える
2026年10月14日に、実際に運用しているプロジェクトで確認した
- KestreLynx の起動時に、作業用イメージの対象として Node.js 22・24・26、Python 3.11〜3.15 を読み込んだ
- Node.js の宣言がないバックエンドでは、既定の Node.js 24（LTS）を選び、宣言された pnpm 10.34.4 で更新を実行した
- 複数系列を対象として読み込む処理と、宣言がない場合に最新の LTS を選んで指定されたパッケージマネージャーで更新する処理が、実環境で機能することを確認した

pnpm 12.10.0 以上での依存更新

pnpm 12.10.0 以上では、lockfile の作り直しに --fix-lockfile を指定して自動更新する
- npm・pnpm は、更新対象の記録を lockfile から取り除いて作り直す方式で更新する
- pnpm 12 はそのままでは対象を取り除いた lockfile を受け付けず、エラーで止まるため、作り直す処理に、取り除いた記録を解決し直す --fix-lockfile を加える
- pnpm 12.10.0・12.11.0・12.11.2・12.13.0 で、対象とそれを参照する親の記述だけが変わり、lockfile を固定した検査も通ることを確認した
- pnpm 12.10.0 より前の 12 系列は、指定がない版、指定しても失敗する版、lockfile の形式が変わる版があるため、手動での対応にする
実際のプロジェクトに近い依存関係で、変更が対象の更新に限られることを確認した
- 約2,000行の lockfile で、推移的依存・peer の接尾辞付きの依存・直接依存・複数の対象の同時更新を確かめ、いずれも対象とそれを参照する親の記述以外は変わらなかった
- 何も取り除いていない lockfile に --fix-lockfile を指定しても、変更はなかった
公式イメージの作業用コンテナで、PR の候補まで進むことを確認した
- pnpm 12.11.2 と Node.js 24・26 の結合テストで、minimist 1.2.5 から 1.2.8 への更新が PR の候補になった

未検証・次の作業

実行環境と上限の確認
- 本番で運用している実際のプロジェクトでの pnpm 12 の更新は未検証
- Node.js 24 以外の系列と Python の各系列での、実際のプロジェクトでの更新は未検証
- 今の方式での arm64 実機と、管理者権限なしで Docker 自体を動かす rootless Docker での動作は未検証
- 処理件数や実行時間などの上限の既定値を裏付ける実測は未検証
- pip でインストール先の環境を判断する際に使う glibc（Linux の基本的なライブラリ）の版の対応表は、Debian 12 の x86_64 以外で実測との照合を要する
修正結果の追跡
- PR の CI がビルドしたイメージを取得し、再スキャンして実際に修正されたことを確かめる
- マージ後にビルド・配備された最終イメージの再スキャンによる解消確認は、PR の作成とマージの確認とは別に残る
公式イメージの digest 表の更新ワークフローの確認
- 週次または手動で更新 PR を作るワークフローについて、実運用での実行から更新 PR の取り込みまでを確認する
- イメージの版・設定・書き込み可能な場所の検査、脆弱性スキャン、更新処理のテストを通してから更新を提案する動作を確かめる
修正できる範囲を広げる
- Kubernetes の定義ファイルへの対応と、修正するソースファイルの自動特定は、利用者の反応を見ながら順に加える
- 修正済みイメージを作る緊急パッチは保留する

更新履歴

2026年10月15日

Node.js・Python の実行環境の選定と対応系列
実環境での確認結果と未検証の範囲
pnpm 12.10.0 以上の自動更新への対応と検証結果

2026年10月13日

公式イメージとツール取得方式への移行
部分 PR・本文表示・修正計画通知の変更
検証結果と次の作業の整理

2026年10月11日

言語パッケージの更新 PR の実装と検証の結果

2026年10月10日

実装と検証の状況を反映

2026年10月9日

調査と設計を記録
Dockerfile のベースイメージ更新の方針

この記事は、KestreLynxの開発記録です。KestreLynxについて