SonarQube のコンテナスキャンとは｜イメージの脆弱性をコードと同じ画面で管理する

AI Security & GovernanceSonarQube

SonarQube のコンテナスキャン（container scanning）とは、コンテナイメージに含まれる既知の脆弱性と悪意のあるパッケージを検出する機能です。

Sonar 社が、2026 年 10 月 22 日にオープンベータを発表しました。提供先は SonarQube Cloud です。そして、SonarQube Advanced Security を契約していれば、追加費用なしで使えます。

コードと依存ライブラリは、SonarQube で調べているチームが多いはずです。しかし、出荷するイメージには、OS パッケージや言語ランタイムも入っています。コンテナスキャンは、この層を SonarQube に取り込みます。

この記事でわかること

  • コードの解析だけでは、イメージのどこが見えないのか
  • コンテナスキャンが検出するものと、使える環境
  • スキャンから再チェックまでの仕組み
  • CLI の使い方と、CI でイメージを止める方法
  • ベータ版の対応範囲と、導入前の確認点

コードの解析では見えない層：なぜコンテナイメージを調べるのか

まず、アプリが動くまでに重なる層を整理します。層は、大きく 3 つあります。

  • 自分で書いたコード：SonarQube の静的解析（SAST）が調べます。
  • 依存ライブラリ：SCA（ソフトウェア構成解析）が調べます。つまり、プロジェクトが取り込むオープンソースです。
  • イメージの層：OS パッケージ、言語ランタイム、システムのライブラリです。

上の 2 つは、リポジトリの中にあります。一方、3 つ目はリポジトリに現れません。そのため、コードと依存関係をどれだけ調べても、この層の脆弱性は見つかりません。

アプリを構成する層と、それを調べる仕組みの表。自分で書いたコードは静的解析（SAST）、依存ライブラリは SCA が調べる。コンテナイメージで加わる OS パッケージ、言語ランタイム、システムのライブラリは、リポジトリに現れないので、コードと依存関係の解析では見えない。この層を調べるのがコンテナスキャン
図 1：コードと依存ライブラリは、解析で調べられます。一方、イメージの層は、リポジトリに現れないので見えません。

実例があります。2026 年 10 月に、PHP 本体の重大な脆弱性が公表されました。通称は PHP2Shell です。これは、アプリのコードにも、Composer のパッケージにも現れません。つまり、問題があるのは、イメージの中の PHP ランタイムです。なお、確認の手順は後半で扱います。

多くのチームは、この層を別のツールで調べています。しかし、その結果は SonarQube とは別の場所に出ます。すると、2 つの一覧を突き合わせる作業が生まれます。Sonar 社も、発表の中でこの点を課題に挙げています。

SonarQube のコンテナスキャンとは：イメージのリスクも同じ画面で管理

コンテナスキャンは、Advanced Security の解析対象をコンテナイメージまで広げる機能です。Advanced Security は、SCA などを提供する SonarQube の製品です。これまでは、依存ライブラリが対象でした。そこに、イメージの中身が加わります。

結果は、SonarQube Cloud の「Container images」に出ます。そして、依存関係のリスクと同じ流れで管理できます。なお、開発元の Sonar 社は、別の記事で紹介しています。SonarSource の会社概要と信頼性を評価した記事です。

コンテナスキャンが検出する 2 種類のリスク

  • 既知の脆弱性：イメージの部品に、公表済みの脆弱性が無いかを調べます。
  • 悪意のあるパッケージ：既知の悪意あるソフトウェアが、入っていないかを調べます。

一方、ライセンスのリスクは対象外です。なぜなら、イメージの利用条件は、コードのプロジェクトとは違うからです。公式ドキュメントも、そう説明しています。

コンテナスキャンを使える環境

使えるのは SonarQube Cloud です。条件は、組織が Advanced Security を契約していることです。対象は、Team プランと Enterprise プランです。また、コンテナスキャンに追加費用はかかりません。なお、Advanced Security 自体は、プランとは別の契約です。

一方、SonarQube Server では、まだ使えません。ただし、Sonar 社は Server への対応を予定しています。時期は公表されていません。

コンテナスキャンの仕組み：スキャンから再チェックまでの 4 段階

仕組みは 4 段階です。手元で動くのは CLI だけで、照合は SonarQube Cloud が行います。

  1. スキャン：スキャナーの CLI を、イメージに対して実行します。場所は、手元の端末か CI です。
  2. 解析：スキャナーが、イメージの SBOM（ソフトウェア部品表）を作ります。そして、SonarQube Cloud に送ります。すると、SonarQube Cloud が部品を照合します。
  3. 確認：結果は、スキャナーの出力に出ます。また、SonarQube Cloud の「Container images」にも出ます。
  4. 再チェック：SonarQube Cloud が、解析済みのイメージを調べ直します。つまり、新しく公表された脆弱性を探します。なお、実行は組織の再解析の設定に従います。
SonarQube のコンテナスキャンの仕組みの図。手元の端末か CI でスキャナーのコマンドを実行すると、イメージの SBOM が SonarQube Cloud に送られる。SonarQube Cloud は部品を照合し、結果を Container images に表示する。解析済みのイメージは、新しい脆弱性が公表されると自動で再チェックされる
図 2：スキャナーが SBOM を作り、SonarQube Cloud が照合します。そして、解析済みのイメージは自動で再チェックされます。

運用で効くのは、4 つ目です。なぜなら、脆弱性は、イメージを作った後にも公表されるからです。つまり、新しい脆弱性を知るために、スキャンをやり直す必要はありません。ただし、イメージの中身を変えたときは別です。その場合は、スキャナーをもう一度実行します。

なお、SBOM の生成には、オープンソースの syft が使われています。そして、スキャナーに内蔵されています。そのため、別に入れる必要はありません。

コンテナスキャンの使い方：CLI の導入から CI への組み込みまで

ここからは、公式ドキュメントの手順を順に見ていきます。まず、必要なものは 3 つです。

  • Advanced Security を契約した SonarQube Cloud の組織
  • SonarQube Cloud のユーザートークン
  • 手元か CI にあるイメージ

スキャナーを入れる

スキャナーは、1 つの実行ファイルです。Linux、macOS、Windows 向けに配布されています。Linux と macOS は x64 と arm64、Windows は x64 です。まず、公式の配布ページから取得します。そして、sonar-container-scanner という名前で PATH に置きます。例えば、Linux と macOS では次のとおりです。

chmod +x sonar-container-scanner-<version>-<platform>.bin
mkdir -p ~/.local/bin
mv sonar-container-scanner-<version>-<platform>.bin ~/.local/bin/sonar-container-scanner

イメージをスキャンする

イメージを指定して実行します。また、組織のキーとトークンを渡します。

sonar-container-scanner <IMAGE> --organization <ORGANIZATION_KEY> --token <TOKEN>

ただし、公式ドキュメントは環境変数を勧めています。なぜなら、トークンが、コマンド履歴やログに残らないからです。

export SONAR_CONTAINER_SCANNER_ORG=<ORGANIZATION_KEY>
export SONAR_CONTAINER_SCANNER_TOKEN=<TOKEN>
sonar-container-scanner alpine:3.19

指定できる入力は 3 種類です。

  • イメージの参照：alpine:3.19 や、ダイジェスト付きの参照です。
  • tar ファイル：docker-archive 形式か、OCI layout 形式です。
  • ディレクトリ：OCI layout を置いたディレクトリです。

なお、イメージは手元にある必要があります。つまり、docker build や docker pull の後に実行します。

CI でリスクのあるイメージを止める

CI では、ビルドの直後にスキャンを置きます。つまり、レジストリへ push する前です。そして、--fail-on で、止める重大度を決めます。

docker build -t my-app:${BUILD_TAG} .
sonar-container-scanner my-app:${BUILD_TAG} --fail-on high

指定した重大度以上のリスクがあると、スキャナーは失敗の終了コードを返します。すると、CI のジョブが失敗します。つまり、そのイメージは先に進みません。指定できる値は 6 つです。none、info、low、medium、high、blocker です。なお、既定は high です。また、none にすると、重大度では止まりません。

CI での SonarQube コンテナスキャンの位置を示す図。ビルドの直後にスキャナーを --fail-on high で実行する。重大度が high 以上のリスクがあると、スキャンが失敗して CI が止まり、push に進まない。無ければ、push などの次の工程に進む
図 3：ビルドの直後にスキャンを置きます。すると、基準以上のリスクがあるイメージは、出荷の前に止まります。

ただし、最初から厳しく止めると、パイプラインが止まり続けます。そのため、「検知」と「ブロック」は分けて考えます。この考え方は、別の記事で整理しています。SAST 導入で失敗する 3 つの理由と対策の記事です。

CI では、あと 2 点を押さえます。まず、組織のキーとトークンは、秘密の環境変数に入れます。次に、スキャナーのキャッシュを引き継ぎます。スキャナーは初回に、内蔵の syft を展開します。そして、これに数秒かかります。そのため、キャッシュのディレクトリをジョブ間で残すと、毎回の展開を省けます。なお、場所は SONAR_CONTAINER_SCANNER_CACHE_DIR で指定できます。

結果を SonarQube Cloud で見る

まず、組織のサイドバーで「Container images」を開きます。すると、解析したイメージの一覧が出ます。一覧に並ぶのは、タグ、リスクの数、最も重大なリスク、最後の解析時刻です。また、検索と並べ替えもできます。そして、イメージを選ぶと、バージョンごとのリスクが出ます。なお、すべてのオプションは公式ドキュメントにあります。

PHP2Shell を例に：コンテナスキャンでイメージの PHP を確認する

PHP2Shell は、PHP 本体の 2 つの脆弱性です。番号は CVE-2026-109618 と CVE-2026-109619 です。どちらも、認証なしでリモートからコードを実行される恐れがあります。影響を受けるのは、Web リクエストを処理する PHP です。PHP の開発チームは、2026 年 10 月 21 日に修正版を公開しました。修正版は 8.5.12、8.4.27、8.3.36、8.2.35 です。出典は PHP 公式のセキュリティ勧告です。なお、Sonar 社の発表では、重大度はどちらも CVSS v4.0 で 9.2 です。

問題は、この脆弱性の場所です。つまり、アプリのコードにも、Composer のパッケージにもありません。そのため、コード解析と依存関係の解析では出てきません。一方、コンテナスキャンでは、ディストリビューションのセキュリティ勧告として出ます。

イメージを確認する 3 つの手順

  1. スキャンする：PHP が動くイメージを、すべてスキャンします。なお、10 月 21 日より前にスキャンしたイメージは、もう一度実行します。
  2. リスクを探す：「Container images」でイメージを選びます。そして、2 つの CVE 番号を探します。なお、Debian や Ubuntu の勧告の名前で出ることもあります。
  3. PHP を更新する：修正済みのベースイメージか、更新されたパッケージで作り直します。そして、もう一度スキャンして、リスクが消えたことを確かめます。

検出できる PHP と、できない PHP

ここには、大事な制約があります。検出できるのは、ディストリビューションのパッケージで入れた PHP です。例えば、Debian や Ubuntu で apt install php8.x として入れた PHP です。また、ベースイメージが対応範囲にあることも条件です。なお、検出されるのは、ディストリビューションが勧告を公開した後です。

一方、ソースからビルドした PHP は検出されません。Docker Hub の公式 php イメージも、これに当たります。つまり、公式 php イメージを使っている場合は、PHP の版を直接確かめてください。

別々のツールで見る運用と、コンテナスキャンで変わること

すでに別のスキャナーで、イメージを調べているチームもあるでしょう。その運用でも、脆弱性は見つかります。変わるのは、結果を見る場所と、管理の流れです。Sonar 社は、利点を 3 つ挙げています。

  • 1 か所で見られる：イメージのリスクが、コードと依存関係のリスクの隣に並びます。
  • 開発の流れの中で調べられる：手元でも CI でも実行できます。そのため、出荷の前に止められます。
  • 一覧が古くならない：解析したイメージは、新しい脆弱性が公表されるたびに調べ直されます。
イメージを別のツールで見る運用と、SonarQube にまとめる運用を左右で比べた図。別々に見ると、コードと依存ライブラリは SonarQube、イメージは別のツールに結果が分かれ、突き合わせが必要になる。SonarQube にまとめると、コード・依存ライブラリ・イメージのリスクが同じ画面に並ぶ
図 4：別々のツールで見ると、結果は 2 か所に分かれます。一方、SonarQube にまとめると、3 つの層のリスクが同じ画面に並びます。

なお、スキャンは「見つける」ための仕組みです。一方、脆弱性の少ないベースイメージを選ぶ方法もあります。こちらは、別の記事で紹介しています。Chainguard の特徴と防御力を検証した記事です。

比較表：別のツールで見る運用と、SonarQube にまとめる運用

変わる点を、表にまとめました。なお、左の列は一般的な例です。つまり、使うツールによって異なります。

項目イメージを別のツールで見る運用（一例）SonarQube のコンテナスキャン
結果を見る場所コードは SonarQube、イメージは別の画面○ コード・依存関係・イメージを同じ組織の画面で
リスクの管理ツールごとに別の流れ○ 依存関係のリスクと同じ流れ
CI で止めるツールごとに設定する--fail-on で重大度を指定（既定は high）
新しい脆弱性への追従ツールによる（再スキャンが要る場合もある）○ 解析済みのイメージを自動で再チェック
ライセンスの確認ツールによる対象外（2026 年 11 月時点）
提供の状況ツールによるSonarQube Cloud のオープンベータ

コンテナスキャンのベータ版：対応範囲と、導入前に確認すること

※ 2026 年 11 月時点の公式情報に基づきます。ベータ版のため、内容は変わることがあります。最新は公式ドキュメントでご確認ください。

対応するベースイメージ

脆弱性を追跡できるかは、ベースの OS で決まります。対応するのは、次の 6 つです。

  • Red Hat Enterprise Linux
  • Debian（11 以上）
  • Rocky Linux
  • AlmaLinux
  • Ubuntu
  • Alpine

また、これらの上に作ったイメージも対象です。例えば、Debian や Alpine をベースにした公式の Node.js イメージです。さらに、各ディストリビューションのセキュリティ勧告も、追跡に含まれます。

ベータ版の制約

  • 提供先：SonarQube Cloud だけです。つまり、SonarQube Server は未対応です。
  • 対象のイメージ：手元か CI にあるイメージです。
  • ライセンス：リスクの検出とポリシーは、対象外です。
  • 再スキャン：画面からは実行できません。そのため、スキャナーをもう一度実行します。
  • SLA：ベータの機能は、SLA の対象外です。

そのため、まずは、いまのスキャナーと並べて試すことを勧めます。つまり、同じイメージを両方で調べ、結果を比べます。なお、リリースの段階の定義は、公式ドキュメントにあります。

よくある質問

コンテナスキャンに追加の費用はかかりますか？

かかりません。SonarQube Advanced Security に含まれています。対象は、SonarQube Cloud の Team プランと Enterprise プランです。ただし、Advanced Security 自体は、プランとは別の契約です。なお、料金は公式サイトでご確認ください。

SonarQube Server でコンテナスキャンは使えますか？

まだ使えません。いま使えるのは、SonarQube Cloud だけです。ただし、Sonar 社は Server への対応を予定しています。なお、時期は公表されていません。

新しい脆弱性を知るために、再スキャンは必要ですか？

必要ありません。SonarQube Cloud が、解析済みのイメージを自動で調べ直します。なお、実行は組織の再解析の設定に従います。一方、イメージの中身を変えたときは、スキャナーをもう一度実行します。

Dockerfile の解析とは、何が違いますか？

調べる対象が違います。SonarQube は、Dockerfile もコードとして解析できます。つまり、こちらが見るのは Dockerfile の書き方です。一方、コンテナスキャンが見るのは、ビルドした後のイメージの中身です。そのため、2 つは補い合います。

すでに別のスキャナーを使っています。置き換えるべきですか？

すぐに置き換える必要はありません。なぜなら、いまはベータ版だからです。また、対応するベースイメージにも限りがあります。まずは、同じイメージを両方でスキャンして、結果を比べるのがよいでしょう。そして、結果を 1 か所で見る利点が大きいかを判断します。

レジストリにあるイメージを、直接スキャンできますか？

ベータ版の対象は、手元か CI にあるイメージです。つまり、先に docker pull などで取得してから、スキャンします。

まとめ：コンテナスキャンで、イメージのリスクもコードと同じ画面に

コードと依存関係を調べても、イメージの層は見えません。そこには、OS パッケージやランタイムの脆弱性が残ります。SonarQube のコンテナスキャンは、その層を同じ画面に取り込みます。さらに、CI では、基準以上のリスクがあるイメージを出荷の前に止められます。そして、解析済みのイメージは、自動で再チェックされます。

いまはオープンベータです。そのため、対応範囲には限りがあります。それでも、Advanced Security を使っているチームなら、追加費用なしで試せます。まずは、いまビルドしているイメージを 1 つスキャンしてみてください。なお、SonarQube の新機能は、ほかにも紹介しています。イシューを自動で修正する Remediation Agent の記事です。

SonarQube のご相談はお気軽にどうぞ

弊社は SonarQube のリセラーです。ライセンスのご提案から、技術サポートまで対応しています。「Advanced Security を足すと、何が見えるようになるのか」。そう確認したい方は、お問い合わせフォームからご連絡ください。

お問い合わせ

参考リンク（公式）

Ryuji Goto
AUTHOR
Ryuji Goto

✨ このカテゴリーのAIまとめ記事を見る

新規CTA