サービスを Docker のイメージにまとめ、セキュリティのスキャンをかけると、報告は真っ赤になりがちだ。ベースイメージに既知の脆弱性がある、パッケージの版が古い、Dockerfile の書き方に問題がある、コンテナの権限が広すぎる。オープンソースのツール DockSec は、まさにこうした報告を扱うためのもので、2026 年 5 月の報道によれば、OWASP（オープンなウェブアプリのセキュリティの国際プロジェクト）のインキュベータープロジェクトに採用された。手元で Trivy、Hadolint、Docker Scout などのスキャナーを走らせ、重複した警告をまとめ、深刻度と悪用されやすさで並べ、AI でそれぞれの問題を説明し、直し方を示す。
このツールでいちばん参考になるのは、自分で引いている線だ。プロジェクトの説明によれば、自動修正が当てるのは Dockerfile の機械的な修正だけで、先にバックアップを取り、直したあともう一度スキャンする。ベースイメージの版を選ぶこと、秘密情報を動かすこと、デプロイ用の設定ファイルを書き換えることはしない。コミットしていない変更があるファイルは、強制しない限り直すのを断る。
チームも同じ線を使える。間違えても気づきやすく戻しやすい機械的な修正は AI に任せてよい。ベースイメージを替える、実行時の権限を変える、デプロイの設定を変えるといった、コンテナの振る舞いを変える判断は、人が試して承認する。
一行の修正でも、影響はその一行より広いことが多い
AI は脆弱性の説明を平易な言葉に直し、一行のアップグレードのコマンドまで付けてくれる。手間が省けそうに見える。だがコンテナの中の変更は、その一行よりずっと広く響くことが多い。ベースイメージの版を替えると、何十ものシステムのパッケージが一度に入れ替わり、すでに確かめた振る舞いが変わることがある。コンテナを root 以外の利用者で動かすように変えると、サービスがあるディレクトリを読めなくなり、起動に失敗することがある。
こうした問題はスキャンの報告には出てこない。実際に動かしてみて初めてわかる。DockSec がベースイメージの版を選ばないのも、その選択にはサービスの理解と試験が要るからだ。
まず分け、それから誰が手を動かすかを決める
機械的な修正： たとえば Dockerfile の書き方の提案、不要なパッケージのキャッシュの削除、版のタグの固定。間違えればビルドの失敗や差分から見て取りやすいので、AI に直させてよい。ただし差分が見え、戻せることが条件だ。
振る舞いを変える修正： ベースイメージの交換、主要なシステムのパッケージのアップグレード、コンテナの実行ユーザーの変更、外に開くポートの変更。これらはテスト環境で動かし、サービスの担当者が承認する。
データの境界： AI の説明を使う前に、何が送られるのかを知っておく。DockSec の説明によれば、AI モードでは Dockerfile かデプロイの設定ファイルの内容と、脆弱性の件数のまとめがモデルに送られる。秘密情報らしい値は既定で伏せられる。Dockerfile に外に出すべきでない社内のアドレスや設定が書いてあるなら、AI を呼ばないスキャンだけのモードか、手元で動くモデルを使う。
警告が多いなら、まず本当に届くのかを見る
スキャンの結果にある脆弱性が、サービスの実行時に使われるとは限らない。順位を決めるときは、外ですでに悪用されているか、サービスがそのコードを実行するか、外部からの入力が届くかを先に問う。脆弱性の優先順位は点数だけで決めず、まず実行経路と外部からの入力を調べるも参考になる。順番が決まったあと、AI が作った修正を本番に出せるかは、問題が起きたときに戻せるかで決まる。AI は脆弱性の修正を書ける。本番に出せるかは、問題が起きたとき戻せるかで決まるも参考にしてほしい。
ツールが引いた線も、自分のサービスで判断し直す
DockSec は個人が作った、まだインキュベーションの段階にあるオープンソースのプロジェクトで、機能や既定の設定は変わりうる。この記事が引いているのはいま公開されている説明なので、導入の前にはプロジェクトの最新の文書を確かめること。ツールが引く線は参考になるが、何を「機械的」とみなすかは、やはり自分のサービスで判断する必要がある。同じ一行の修正でも、サービスによってリスクはまったく違いうる。
AI 整理カード
Docker のイメージのスキャンで大量の警告が出た。AI に整理を手伝ってもらいつつ、AI に直させてよい修正と、人が承認すべき修正の線をはっきりさせたい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/docker-ai-security-scanner-human-fix-gate/
記事の見方はこうだ。間違えても気づきやすく戻しやすい機械的な修正は AI に任せてよい。ベースイメージを替える、実行時の権限を変える、デプロイの設定を変えるといった、コンテナの振る舞いを変える判断は、人が試して承認する。AI の説明を使う前に、どのファイルの内容がモデルに送られるかを知っておく。
私が許可した Dockerfile、デプロイの設定、スキャンの報告だけを、読み取り専用で確認してほしい。ファイルを直したり、ビルドを走らせたりしないこと。
1. 警告を出どころで分ける。ベースイメージ、パッケージ、Dockerfile の書き方、実行時の権限や外に開くポート；
2. それぞれの修正の提案を「機械的な修正」と「振る舞いを変える修正」に分け、理由を書く；
3. Dockerfile や設定に、社内のアドレスや秘密情報など外部のモデルに送るべきでないものがないかを確かめ、スキャンだけのモードか手元のモデルかを勧める；
4. 振る舞いを変える修正について、テスト環境で確かめるべき項目と承認者を挙げる。
ベースイメージの版を私の代わりに選ばないこと。候補と試すべき点を挙げるだけにすること。
参考資料
- GitHub（OWASP 公式プロジェクト）：OWASP/DockSec — https://github.com/OWASP/DockSec [accessed: 2026-10-11]
- Open Source For You：OWASP-Backed Open Source DockSec Uses LLMs To Fix Docker Vulnerabilities Faster — https://www.opensourceforu.com/2026/05/owasp-backed-open-source-docksec-uses-llms-to-fix-docker-vulnerabilities-faster/（2026-05-27）
- Docker Docs（公式）：Docker Scout — https://docs.docker.com/scout/ [accessed: 2026-10-11]
