あるサービスを Docker イメージにして、同僚にテストやデプロイを渡そうとしている。セキュリティスキャナーを走らせると、画面には突然、何十個、場合によっては百個以上の警告が並ぶ。パッケージのバージョンが古い、ベースイメージに脆弱性がある、Dockerfile（そのイメージをどう作るかを記述する設定ファイル）の書き方が安全ではない、コンテナの権限が広すぎるかもしれない。

セキュリティを毎日扱っていない人ほど、二つの極端に寄りやすい。警告を全部無視するか、AI に「全部直して」と頼むかだ。前者は本当に危険な穴を残すかもしれない。後者も安全とは限らない。AI がバージョン、インストール方法、実行権限を変えて、サービスを安全そうに見せながら別の場所を壊すことがあるからだ。

OWASP Incubator Project の DockSec は、最近いくつかのセキュリティ／オープンソース系メディアで紹介された。Trivy、Hadolint、Docker Scout のような既存の Docker スキャンツールをまとめ、大規模言語モデル、つまり文章を読み説明を生成できる AI を使って、警告を整理し、リスクを説明し、Dockerfile の修正案を出す。AI を呼ばずにスキャンだけを行うオフラインモード（scan-only）もあり、説明が必要なときだけ OpenAI、Anthropic、Google Gemini、ローカルの Ollama などにつなげる。

この種のツールの価値は、AI に修正ボタンを押してもらうことではない。本当に学ぶべきことは、スキャン結果が増えたとき、チームには「先に分類し、次に修正し、最後に人が確認する」流れが必要だという点だ。

大量の Docker セキュリティ警告に向き合うチームが、警告を分類し、テストし、責任者が放行できる修正を判断している。

問題は警告が少なすぎることではなく、多すぎて最初に見るものが分からないこと

Docker は、アプリケーション、実行環境、依存パッケージをまとめて包む方法だ。多くの Web サイト、API、社内ツール、小さな AI サービスは、デプロイを安定させるために Docker を使う。ただし、その包みの中には OS パッケージ、言語パッケージ、設定ファイル、起動コマンドが同時に入る。どこか一層でも古かったり、権限が大きすぎたりすれば、リスクになり得る。

従来のスキャンツールは問題を見つけるのは得意だが、何から直すべきかを判断する手助けは十分ではないことがある。一般的な開発者にとって、スキャン結果はよくこう見える。

  • 本当に急いで今日直すべき警告がある。
  • パッケージ内には存在するが、このサービスでは該当機能を使っていない警告がある。
  • バージョンを上げるだけに見える修正が、実際には互換性に影響することがある。
  • Dockerfile の提案は妥当でも、既存のデプロイ手順を壊すことがある。

DockSec のようなツールが埋めようとしているのは、「大量の警告」から「理解できる修正計画」までの空白だ。Open Source For You はプロジェクト作者の言葉として、開発者が 200 件以上の CVE、つまり公開番号の付いたセキュリティ脆弱性を受け取っても、「結局どの行を先に直せばよいのか」が分からない状況を紹介している。

ただし、ここには新しいリスクもある。AI が修正をなめらかに説明すると、チームは判断まで終わったように感じやすい。実際には違う。AI は手がかりを整理できるが、このサービスのバージョンを変えてよいか、ベースイメージを替えてよいか、あるパッケージを削ってよいかまでは決められない。

まず三層に分ける：手順どおり修正、テスト後に修正、人が決める修正

AI が整理したスキャンレポートを見たとき、最初に「賢いかどうか」を見ない。まず問うべきなのは、この修正が間違っていたら誰に影響するかだ。

修正層よくある例次の動き
手順どおり修正Dockerfile の整形、明らかに不要な一時ファイル、文書化された低リスク設定提案どおり修正しつつ、差分記録を残す
テスト後に修正パッケージのアップグレード、ベースイメージ変更、ビルド手順の変更隔離されたテスト環境で確認し、失敗時のロールバック／復旧を用意する
人が決める修正権限モデル変更、主要パッケージ削除、ネットワークや認証情報の設定変更、顧客データへの影響責任者がリスク、時期、リリース枠を確認する

この表の目的は、「AI の提案」を「追跡できる修正判断」に変えることだ。AI は脆弱性がなぜ重要かを説明し、Dockerfile の変更候補を示せる。だが、修正がデプロイ、権限、データ処理、顧客の利用可否に影響するなら、AI の助言をそのまま本番へ通してはいけない。

特に権限まわりの修正は慎重に扱いたい。権限を下げることは多くの場合よいことだが、サービスがあるファイル、接続、システム能力に依存しているなら、直接削ることでテストでは通り、本番でだけ壊れることがある。セキュリティとは、すべての権限を削ることではない。それぞれの権限がなぜあるのか、どれを外せるのか、どれをより狭い代替に変えるべきかを知ることだ。

AI の修正提案は四つの確認を通す

チームが AI 支援スキャンを日常の流れに入れたいなら、各修正提案を四つの確認に通すとよい。

確認点問うことなぜ重要か
影響範囲この脆弱性は現在のイメージ、実行方法、公開入口に本当に影響するか発火しない警告に時間を使いすぎないため
変更内容AI が提案しているのはバージョン、設定、権限、ビルド全体のどの変更か変更の種類ごとに必要なテストの深さが違うため
テスト証拠修正後に単体、結合、起動、デプロイのどのテストを走らせたか「スキャン点数は上がったがサービスは壊れた」を防ぐため
復旧方法問題が起きたとき、前の版へすぐ戻せるかセキュリティ修正にもロールバックと復旧計画が必要だから

ロールバック／復旧とは、変更を前の安定状態へ戻すことだ。これは悲観ではなく、セキュリティ作業の一部である。ベースイメージ、システムパッケージ、デプロイ権限に関わる修正ほど、変更前に戻し方を知っておく必要がある。

0 から 100 までの安全スコアだけを目標にしないことも大切だ。スコアは改善を追跡する助けになるが、製品が安全かどうかの完全な答えではない。本当に見るべきなのは、高リスク警告が処理されたか、修正にテストがあるか、例外が承認されているか、次回のスキャンでなぜその警告を残したのか説明できるかだ。

AI に自動修正させないほうがよい場面

AI に任せやすい作業もある。レポートを平易な言葉に直す、重複した警告をまとめる、Dockerfile の変更候補を列挙する。こうした作業は読む時間を減らしてくれる。

ただし、次のような場面では、AI が自動修正したものをそのまま本番に出すべきではない。

  • サービスが顧客データ、決済、ログイン、内部認証情報、会社の機密を扱う。
  • 修正がベースイメージ、データベースドライバー、暗号化パッケージ、ネットワーク設定に触れる。
  • 自動テストがなく、デプロイのロールバック／復旧方法も明確ではない。
  • チーム内の誰も、そのコンテナに必要な権限を説明できない。
  • スキャンツールや AI モデルがレポートデータを外部サービスへ送る必要があるが、その中に機密情報が含まれるか確認していない。

DockSec の文書は、オフラインスキャンだけを行うことも、必要に応じて異なる AI モデルを使うこともできると説明している。これはよい注意点だ。AI 支援の資安ツールを導入する前に、データがローカル環境を出るのか、送られるのはイメージ全体なのかスキャンの要約だけなのか、誰がレポートを見られるのか、どこに保存されるのかを先に確認する必要がある。

まだそれらを説明できないなら、本番のビルドフローには入れない。まずは隔離されたテスト環境で、機密性の低いプロジェクトを使い、分類と修正の流れを練習するほうがよい。

最小限の流れ：AI に説明させ、人が放行を決める

小さなチームが、最初から複雑なセキュリティ基盤を作る必要はない。現実的な始め方は、スキャン結果を簡単な表に入れることだ。この表は第三の新しい基準ではない。上の三層分類と四つの確認を、PR、チケット、修正記録に貼れる一枚の作業表へまとめるものだ。

欄位記録すること
警告概要AI またはスキャンツールが整理した問題
影響判断現在のサービスに影響するか。影響しないなら理由
修正タイプ手順どおり修正、テスト後に修正、人が決める修正
テスト証拠修正後に走らせたテストと結果
放行者この修正をマージまたはデプロイしてよいと本当に確認した人

この流れは「ワンクリックで全部修正」より遅く見える。だが、AI が脆弱性を説明したからといって、修正後の結果まで AI が引き受けるわけではない、という最も危険な誤解を避けられる。

生活四コマ

四コマ漫画：チームが大量のセキュリティ警告を受け取り、分類し、AI に手がかりの整理を手伝わせ、最後に人が放行できる修正を決める。

  1. チームに安全警告が箱いっぱい届き、最初はどれも急ぎに見える。
  2. まず、手順どおり修正、テスト後に修正、人が決める修正に分ける。
  3. AI は手がかりとチェックリストの整理を手伝うが、テストと復旧方法は人が確認する。
  4. 低リスクの修正だけを先に進め、危険な項目は責任者の判断を待つ。

DockSec のようなツールは、セキュリティスキャンを読みやすくしてくれる。それはよいことだ。ただし、読みやすいレポートほど、明確な人の関門が必要になる。次に Docker スキャナーが大量の脆弱性を出したとき、AI に全部直してもらおうと急がない。まず分けるべきだ。どれが整理作業で、どれがエンジニアリング上の変更で、どれが本当の製品責任に関わるのかを。

AI 整理カード

この記事の状況に合わせて、AI に整理してもらう

自分の AI チャットツールに貼り付けると、このミニクラスを自分用のチェックリストにできます。BMC は、あなたが AI に貼り付けた内容を見ることはありません。

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料