短命なコンテナのスキャンの開発

状態: 設計(実装未着手)
開始日: 2026年10月3日
最終更新: 2026年10月6日

目的

定期実行のバッチなど、一時的に動いて消えるコンテナのイメージも、脆弱性のスキャンと通知の対象にする。

本体が常駐する Docker 環境を対象とし、スキャンの時点では終了しているコンテナの実行履歴を使う。Sensor(実行時の情報を観測する部品)による使用状況の判定とは分けて設計する。

方針

短命なコンテナには使用状況の判定をしない
- 数秒の観測から使用状況を判断する意味は薄く、観測に必要な準備を実行中に終えることも難しい
- 使用状況を判定しなくても、イメージから検出した脆弱性は通知する
イメージの名前ごとに最後に動いた版を対象にする
- :latest のような名前は、イメージを作り直すと同じ名前のまま別の中身を指すため、名前ではなく実際に動いた中身を記録してスキャンする
- 名前の違うイメージは別々に扱い、過去の版をすべて対象に残すことはしない
取りこぼしを前提にして、確認できない範囲を見える形にする
- 実行を拾えなかった可能性がある期間を記録し、通知にも示す
- 観測の対象外と確認できたイベントと、本来の観測の取りこぼしを区別する
期間から外れたことを脆弱性の修正と混同させない
- スキャンの対象外になったことと、再スキャンで所見がなくなったことを分ける
- 確認できないことを根拠に、前回の所見を解消にしない

きっかけになった調査

Sensor の記録で、使用状況の判定に使えなかったイベントの件数が毎朝増えていた
毎朝の定期バッチが、数秒だけ動いて終了し、その後に削除されるコンテナを作っていたため、Sensor のコンテナの発見や、イベントをパッケージに結び付ける準備が間に合っていなかった
- 発見してから準備が整う前に終了したコンテナのイベントは、取りこぼしの件数に加わっていた
- 発見する前に終了したコンテナのイベントは、どのコンテナのものか分からないイベントとして分類不能の件数に加わっていた
- 観測の対象外のイベントが混ざるため、これらの件数だけでは本来の観測の問題と区別できなかった
同じくコンテナが短時間で終了していたため、その時点で動いているコンテナだけを対象にする本体の毎日のスキャンにも、このバッチのイメージが入っておらず、所見が通知に出ていなかった
確認した期間には、カーネル(OS の中核部分)側でイベントを一時的にためる領域があふれてイベントを取りこぼしたことは一度もなかった
- 今後もカーネル側の取りこぼしを区別できるよう、Sensor が出す証拠にカーネル側の取りこぼしの件数を記録する項目を追加した(実装済み)

決めたこと

使用状況と通知

短命なコンテナには使用状況の判定を行わず、実行履歴から対象に加えるイメージには、その実行についての注記を付ける。

対象	扱い
短命なコンテナの実行履歴だけを根拠にするイメージ	所見に使用状況の印を付けず、イメージの見出しに「短時間だけ動いたコンテナ」と最後の実行の時刻を注記する
同じイメージが常駐のコンテナでも動いている場合	常駐のコンテナについては今までどおり使用状況を判定し、その結果を短命な実行の使用状況としては扱わない

実行の捕捉と対象の選び方

本体が Docker のイベント(コンテナの開始・終了・削除の通知)を常時受け取り、実行履歴を保存する
- コンテナが消える前に実際に動いた中身を確認し、イメージの名前と最後の実行の時刻に結び付ける
- 中身を確認できなかった場合は未確認として残し、名前が現在指す別の版で代用しない
現在稼働中のコンテナのイメージに加えて、現在は動いていないイメージを履歴から選ぶ
- イメージの名前ごとに最後に動いた版だけを、最後の実行から14日間スキャンの対象に残す
- 名前の違うイメージは別々に扱う
- 同じ名前の新しい実行を確認した場合に期限を更新し、スキャンしただけでは期限を延ばさない

同じ名前で次のスキャンまでに複数の版が動いた場合は、最後の版だけを履歴から選ぶため、途中の版が一度もスキャンされないことはある。

所見の保持と監視の対象外

状態	所見と通知の扱い
再スキャンが成功し、前回の所見がなくなった	解消として扱う
最後の実行から14日が経過した	「監視の対象外になった」として、解消と区別する
実行した中身を確認できない、またはスキャンに失敗した	前回の所見を保持し、確認できないことを示す
実行を取りこぼした可能性がある期間があり、対象の変化を確認できない	前回の所見を保持し、不確かな消失を解消にしない

スキャンできずに前回の結果を表示している所見には、前回のスキャンの結果であることを示す。本体の停止などで Docker のイベント(コンテナの開始・終了の知らせ)を受け取れなかった期間を「収集の空白」と呼ぶ。イベントを受け取れなかった期間があっても、14日の期限は延ばさない。期限に達したイメージは監視の対象外にし、その期間にまた動いていた可能性があることを添える。

取りこぼしの記録

Docker のイベントは本体の停止中などに完全には拾えないため、収集の空白を記録し、通知に期間と短い注意を示す
- 再接続で一部のイベントを取り直せても、その期間の実行をすべて回収できたとは扱わない
Sensor は、観測の対象外と確認できた短命なコンテナのイベントを、取りこぼしや分類不能とは別に数える
- どのコンテナのものか分からないイベントは、今までどおり分類不能に残す
- 対象外のイベントを分けることで、常駐のコンテナやカーネル側の実際の取りこぼしを隠さない

未検証・次の作業

短命なコンテナのスキャンと Sensor の数え方の変更は未実装である。実装は Sensor の数え方、本体による実行の捕捉と保存、スキャンの対象の選び方と通知の順に進める。

実際の運用環境で実行条件を確認する
- バッチのイメージが毎回作り直されるかを確認する
- Docker Engine と Compose の版、コンテナの起動方法と削除の仕方を確認する
Sensor の分類の基準を確かめる
- 実行時間と終了の根拠、観測の準備状況を調べ、短命とみなす具体的な基準を決める
- 記録されたイベントの内訳と、取りこぼしや分類不能に数えられる条件を確認する
捕捉と保存の負荷を測る
- イベントの受信、コンテナの情報取得、履歴の保存にかかる負荷を測り、処理と保存量の上限を決める
- 本体の再起動や接続切断、コンテナの削除が重なった場合に、確認できない範囲が記録と通知に残ることを確かめる

更新履歴

2026年10月6日

調査結果と設計を記録

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