コンテナのセキュリティ脆弱性対策の自動化

2026年9月20日 2026年9月20日

rio

自宅鯖ではベアメタルとPodman（Quadlet）のコンテナが稼働している。DHCPサーバやSMTP/IMAPなど、ハードと切り離しにくい、あるいはコンテナ化することのメリットが薄いものはベアメタルで動かしていて、これらはベースとなっているRHEL10のセキュリティエラータを自動適用する。

一方で、約50個ほど動いているコンテナは、ベースイメージがAlpineだったりUbuntuだったりバラバラな上、上物、つまりメインのサービスを開発しているコミュニティによって、セキュリティ対応のレベルもバラバラだったりする。

コミュニティによるセキュリティ対応への疑問

このブログを動かしているWordPressのセキュリティ対応は素晴らしくて、ともかく早い。プラグインのリリースゲートにAIを採用していたり、かなり先端を行っていると思う。

一方で、AIによるIssue報告、Pull Requestsをガイドラインで禁止しているコミュニティも多く、セキュリティ脆弱性が残存しているのはほとんどこれ。とっととAIによるコードを受け入れた方が良い。何せ、発見も攻撃もAIがしているのだから、防御だけニンゲンでやろうとするのは無理がある。

自宅鯖のコンテナセキュリティ

ホストがRHEL10なのでSELinuxその他のセキュリティ対策は一通りやっているという前提で読んで欲しい。

元々は、自宅鯖自身で"host-security-scan"というサービスを定義して稼働していた。これはTrivyなどで該当するCVEや、名前・ハッシュベースでファイルを検出するといった手法で、コンテナイメージに含まれるセキュリティ脆弱性を発見しレポートさせていた。

このレポートはメールで飛ばすようにしているので、AIエージェントに「CRITICAL / HIGHだけ直して」とザックリと指示し、途中で詰まったら追加の判断・指示を与えるという流れ。これをしばらく続けていたところ、GPT-5.6からはザックリとした指示だけで完走するようになったので、MacStudio上のApple Containerで日次で自動実行するようにした。この自動実行を実装する際に、過去のセキュリティ脆弱性対応のログを与えて、決定論的に処理すべき部分と、非決定論的に、つまり動的にLLMが判断すべき部分を分類させ、前者はPython等のコードとして、後者は環境変数でLLMを選択できる入り口だけ作った。

しかしMacStudioは24時間稼働している訳ではないので、ちょっとだけ多い腰を上げて使っていなかったミニPCにRHEL10を入れ、Podman（Quadlet）で動くようにした、というのが現在動作しているもの。

何をやらせているのか

"host-security-scan"を実行する。前述した通り、TricyやOpenSCAP、SCEなど。これもツールの診断結果の集計などにOpenAI APIを利用している。
1の結果、セキュリティ脆弱性は、CRITICAL / HIGH / MEDIUM / LOW / UNKNOWNに分類される。
CRITICALについては実際に自宅鯖に該当するか否かに関わらず、即時修正させる。CVEの質を問わず、修正時間を優先。HIGHは、該当チェックしてからの修正。MEDIUM以下は件数が多すぎるので該当チェックもせず、CRITICAL / HIGH修正のついでに直ったら良いな、という扱い。
修正方針は、
- コンテナのアップストリームのイメージを更新
- アップストリームのイメージで修正できない場合、コンテナ内に含まれるパッケージを更新
- パッケージで更新できない場合、CRITICAL / HIGHはパッチを書いて適用、テストして修正
- よりリスクの高い脆弱性の修正の結果、低い脆弱性が増えるのは許容する。
- リモート実行はよりリスクが高いと評価する。
- これらの作業を全てAnsibleを介して実装
作業後に再度"host-security-scan"を実行し、レポートとして報告する。