Docker 入門

Dockerイメージセキュリティ：DCT（コンテンツトラスト）とイメージスキャンのコンフィギュレーション

Dockerコンテナ化アプリケーションのセキュリティを確保する旅において、安全なイメージをビルドし、ベストプラクティスに従ってコンテナのコンフィギュレーションを行うことは基本です。しかし、イメージのソース（出所）が検証できない場合や、イメージを構成するコンポーネント自体に既知のセキュリティ脆弱性が潜んでいる場合、いかに精巧に作られたイメージであっても安全とは言えません。

本章では、Dockerイメージの完全性とセキュリティを強化する2つの重要なメカニズムについて深く掘り下げます。イメージのオーセンティシティ（真正性）と完全性を保証するための Docker Content Trust (DCT) と、イメージレイヤー内の脆弱性をプロアクティブに識別するためのイメージスキャン (Image Scanning) です。これら2つのプラクティスは、コンテナセキュリティポリシーにおける堅牢な防御層を形成し、あなたの焦点を単なる「イメージをどうビルドするか」から、「イメージをどうトラスト（信頼）するか」、そして「イメージ内に一体何が含まれているのか」へとアップグレードさせます。

1. Docker Content Trust (DCT)：イメージのオーセンティシティと完全性の確保

Docker Content Trust (DCT) は強力なセキュリティ保証レイヤーを提供し、イメージの完全性とパブリッシャー（発行者）のアイデンティティを検証できるようにします。その設計の本来の目的は、「中間者（Man-in-the-middle）」攻撃（攻撃者がイメージの転送中にデータを改ざんする可能性）を防ぐこと、または信頼できない、あるいは侵害されたイメージを誤ってプル（Pull）してしまうのを防ぐことです。DCTは TUF (The Update Framework) と Notary テクノロジーを活用し、あなたが操作するイメージがまさにパブリッシャーが意図したバージョンであり、改ざんされていないことを保証します。

1.1 Docker Content Trustとは？

端的に言えば、DCTはあなたがプルするすべてのDockerイメージに、パブリッシャーのデジタルシグネチャ（署名）が付与されていることを保証します。この機能を有効にすると、Dockerは信頼できるソースから提供され、かつ有効なデジタルシグネチャを持つイメージのプルのみを許可します。イメージにシグネチャがない場合、またはシグネチャが検証できない場合、プル操作は失敗し、潜在的に侵害されたソフトウェアのデプロイを阻止します。これは、コンテナイメージにクリプトグラフィ（暗号化）による検証レイヤーを追加するため、安全なソフトウェアサプライチェーンを維持する上で極めて重要です。

1.2 Docker Content Trustの動作原理

DCTは、暗号化キーのセットと、Notary サーバーと呼ばれる信頼できるシグネチャサーバーに基づいて動作します。例えば、Docker HubはNotaryサーバーを実行しており、署名済みイメージのシグネチャとメタデータを保存するために使用されています。

キー管理： DCTを初めて有効にする際、Dockerは以下の暗号化キーのセットを生成します。

  • Root Key (ルートキー): 他のキーに署名するために使用される、最もセンシティブなキー。極めて高いセキュリティを確保するため、オフラインで厳重に保管する必要があります。
  • Repository Keys / Targets (レポジトリキー / ターゲット): レポジトリ内の個々のイメージ（タグ）に署名するために使用されます。通常、デベロッパーがこれらのキーを使用します。
  • Timestamp Key (タイムスタンプキー): タイムリネス（適時性）の保証を提供し、最新の署名済みメタデータを取得していることを確認します。
  • Snapshot Key (スナップショットキー): すべての署名済みメタデータのスナップショットに署名することで、ロールバック攻撃を防ぎます。

署名ワークフロー (Signature Workflow):

  1. デベロッパーがDCTを有効にし、イメージをイメージレジストリ（Docker Hubなど）にプッシュ（Push）すると、Dockerはプライベートなレポジトリキーを使用してイメージタグに署名します。
  2. そのシグネチャと、イメージに関するメタデータがNotaryサーバーに送信されます。
  3. Notaryサーバーはこれらの情報を安全に保存し、イメージと検証済みのパブリッシャーを関連付けます。

検証ワークフロー (Verification Workflow):

  1. ユーザーがDCTを有効にした状態でイメージをプルしようとすると、DockerクライアントはNotaryサーバーにコンタクトします。
  2. リクエストされたイメージタグの暗号化シグネチャとメタデータをリトリーブ（検索・取得）します。
  3. パブリッシャーのパブリックキー（公開されており、または以前の信頼できるインタラクションを通じてクライアントに既知）を利用して、Dockerクライアントはイメージのシグネチャを検証します。
  4. シグネチャが有効であり、イメージのコンテンツと一致する場合、イメージは正常にプルされます。シグネチャが無効、欠落、または改ざんが示唆される場合、プル操作は中止され、エラーがスローされます。

1.3 実際のアプリケーションシナリオ

実際のシナリオ 1：サプライチェーンの完全性
"SecureApps Inc." というソフトウェア企業があり、重要な内部サービスの開発に特化していると仮定します。彼らはこれらのサービス用にDockerイメージをビルドし、プライベートDockerレジストリにプッシュしています。DCTを有効にすることで、同社は承認されたデベロッパーによって署名されたイメージのみがプロダクション環境にデプロイされることを保証します。悪意のある攻撃者がレジストリにアクセスできたとしても、プライベート署名キーを取得できなければ、デプロイメントシステムに受け入れられる未署名または改ざんされたイメージをプッシュすることはできず、内部ソフトウェアサプライチェーンの完全性が保護されます。

実際のシナリオ 2：パブリックイメージのトラスト
"CommunityTools" というオープンソースプロジェクトが、最新のユーティリティツール用のDockerイメージをリリースしたとします。プロジェクトがDCTを有効にしてイメージに署名していれば、ユーザーも自身の環境でDCTを有効にすることができます。ユーザーが communitytools/utility:latest をプルすると、Dockerクライアントはそのイメージが確実に CommunityTools によってリリースされたものであり、中間者によって改ざんされていないことを検証します。これにより、実行しているソフトウェアが正当なソースからのものであるという保証がユーザーに提供されます。

想定シナリオ：未署名イメージの意図しないデプロイの防止
開発チームは、Docker Hub上の様々なベースイメージを頻繁に使用します。ある日、ジュニアデベロッパーがDockerfileの FROM インストラクションで、一度も署名されたことのないカスタム内部イメージ（おそらく高速なテスト用のイメージ）を誤って参照してしまいました。CI/CD パイプラインでDCTが強制的に有効にされていれば、この派生イメージのビルドまたはプッシュ操作は失敗します。なぜなら、その親イメージに信頼できるシグネチャがないためです（派生イメージ自体に署名できたとしてもです）。これにより、トラストされていないコンポーネントが誤ってプロダクション環境にデプロイされるのを防ぎます。

1.4 Docker Content Trustの有効化と無効化

DCTは、環境変数 DOCKER_CONTENT_TRUST を通じて制御されます。

DCTの有効化：

export DOCKER_CONTENT_TRUST=1

有効にすると、すべての docker pull、docker build、docker create、および docker run コマンドはイメージシグネチャの検証を試みます。また、docker push コマンドはシグネチャの付与を強制します。

DCTの無効化：

export DOCKER_CONTENT_TRUST=0

または、変数の設定を直接解除します：

unset DOCKER_CONTENT_TRUST

ワンタイムの操作として、コマンドの直前に環境変数を付与することも可能です：

DOCKER_CONTENT_TRUST=1 docker pull myregistry/myimage:latest

1.5 制限事項と注意事項

DCTは強力な機能ですが、いくつかの制限事項や注意すべき点があります：

  • キー管理コスト： 暗号化キー（特に Root Key）の管理には、綿密なプランニングと安全なプラクティスが必要です。キーの紛失や漏洩は、重大なセキュリティインシデントをもたらします。
  • オール・オア・ナッシング： 真のエンドツーエンドのトラストを実現するには、依存関係チェーン内のすべてのイメージ（ベースイメージを含む）が署名されている必要があります。ベースイメージにシグネチャがない場合、DCTはその使用をブロックするため、サードパーティのベースイメージが一貫して署名されていないと、利用上の障壁となる可能性があります。
  • 脆弱性のスキャンは行わない： DCTが検証するのは、誰がイメージをパブリッシュしたかと、イメージが改ざんされていないかです。既知のセキュリティ脆弱性を見つけるためにイメージのコンテンツをスキャンすることはありません。ここで登場するのがイメージスキャンです。

2. Dockerイメージスキャン: 脆弱性とコンプライアンス問題の特定

DCTを通じてイメージが署名され、トラストされていたとしても、そのコンテンツには既知の脆弱性を持つソフトウェアコンポーネントが含まれている可能性があります。Dockerイメージスキャンとは、Dockerイメージのコンテンツをアナライズ（分析）し、これらのセキュリティ上の弱点を特定すると同時に、ライセンスのコンプライアンスやその他のセキュリティベストプラクティスをチェックするプロセスを指します。

2.1 なぜイメージをスキャンするのか？

Dockerイメージは通常、OSパッケージ、オープンソースライブラリ、およびアプリケーションコードのレイヤーからビルドされます。これらのコンポーネントのそれぞれに、既知のセキュリティ脆弱性（CVE：Common Vulnerabilities and Exposures）が存在する可能性があります。スキャンを行わないと、これらの脆弱性がシステム内に潜伏し、コンテナのデプロイ時に巨大なセキュリティリスクをもたらす可能性があります。

  • 脆弱性のプロアクティブな検知： イメージがプロダクション環境にデプロイされる前に、OSパッケージ（apt、yumなど）、言語固有パッケージ（pip、npm、composerなど）、およびその他のソフトウェア依存関係内の脆弱性を発見します。
  • コンプライアンス： イメージが組織のセキュリティポリシー、規制要件、およびライセンスアグリーメント（契約）に準拠していることを確認します。
  • アタックサーフェスの縮小： 脆弱性を早期に発見しパッチを当てることで、コンテナの潜在的なアタックサーフェス（攻撃対象領域）を縮小できます。
  • シフトレフトセキュリティ (Shift Left Security)： 開発ライフサイクルのより早い段階（例えば CI/CD ビルド中）にセキュリティチェックをインテグレート（統合）します。この段階であれば、問題の修正コストは低く、解決も容易です。

2.2 イメージスキャンの種類

  • 脆弱性スキャン (Vulnerability Scanning)： これが最も一般的なタイプです。イメージレイヤーを検査してインストールされているパッケージとそのバージョンを特定し、そのインベントリ（リスト）を既知の脆弱性データベース（NVD 国家脆弱性データベース、特定ベンダーのデータベース、コミュニティが管理するリストなど）と照合します。
    • 例：ある nginx イメージが、深刻な脆弱性を持つ古いバージョンの OpenSSL を使用していることを検出する。
  • ライセンススキャン (License Scanning)： このタイプのスキャンは、イメージ内のソフトウェアコンポーネントに関連するライセンスを識別します。これは、特にオープンソースソフトウェアを使用する商用アプリケーションにおいて、法的なコンプライアンスを確保するために不可欠です。
    • 例：プロプライエタリなアプリケーションイメージ内に、厳格な AGPL ライセンスを持つ依存関係が含まれており、企業ポリシーに違反する可能性があることを特定する。
  • 静的解析 (SAST - 静的アプリケーションセキュリティテスト)： 従来の意味では完全な「イメージスキャン」に分類されないかもしれませんが、一部の高度なツールはイメージ内のアプリケーションコードをアナライズし、セキュリティ脆弱性につながる一般的なコーディングエラー（SQLインジェクションの欠陥、クロスサイトスクリプティングなど）を探索できます。
    • 例：スキャナが、イメージに含まれる Python スクリプト内に潜在的な SQL インジェクション脆弱性を発見する。

2.3 イメージスキャナの動作原理

大部分のイメージスキャナは、以下のような類似のプロセスを辿ります：

  1. イメージのデコンストラクション (解体): スキャナはまず、Dockerイメージを個々の独立したレイヤーに解体し、そのファイルシステムを抽出します。
  2. パッケージの識別: 次に、インストールされているすべてのパッケージ、ライブラリ、およびアプリケーションの依存関係を識別します。これには、OSパッケージ（.deb、.rpm など）、プログラミング言語の依存関係（Pythonの requirements.txt、Node.js の package.json、Java の pom.xml など）、さらには設定ファイルも含まれます。
  3. データベース照合: 識別されたコンポーネント（パッケージ名、バージョン）を、継続的にアップデートされる脆弱性データベースと照合します。これらのデータベースには、既知の CVE、その重大度（Critical、High、Medium、Low）、通常は推奨される修正バージョンに関する情報が含まれています。
  4. レポート生成: 最後に、スキャナは詳細なレポートを生成し、発見されたすべての脆弱性、その重大度、欠陥の説明をアウトプットします。通常は CVE エントリへのリンクと推奨されるリメディエーション（修復）ステップ（例：特定のバージョンへのアップグレード）も提供されます。

2.4 主流のイメージスキャンツール

市場には、オープンソースプロジェクトから商用のエンタープライズソリューションまで、選択可能な多くのツールが存在します。

  • Trivy: 非常にポピュラーで、オープンソースかつ包括的な脆弱性スキャナです。使いやすさ、スピード、正確さで知られています。Trivy は、OSパッケージ、アプリケーション依存関係（Go, Java, Python, Node.js, PHP, Ruby, .NET）、Infrastructure as Code (IaC) コンフィギュレーション（Terraform, Kubernetes, Dockerfile）、さらには Kubernetes クラスターコンポーネントをスキャンできます。
  • Clair: オープンソースの API ドリブンなコンテナ脆弱性静的解析ツールです。Clair は主にOSパッケージレベルでの脆弱性分析を行い、大規模な CI/CD パイプラインやコンテナレジストリにインテグレートされることがよくあります。
  • Docker Scout (Docker Desktop 統合): Docker Scout は、Docker Desktop に直接インテグレートされた脆弱性スキャンとサプライチェーンインサイトの機能を提供します。追加のツールをインストールすることなく、脆弱性の可視性、SBOM（ソフトウェア部品表）の生成、およびポリシーの実行機能を提供します。
  • 商用ソリューション (Snyk, Aqua Security, Qualys Container Security など): これらのソリューションは、ポリシーの強制実行、CI/CD ツールとのディープなインテグレーション、ランタイム保護、およびプロプライエタリな脅威インテリジェンスを備えた巨大な脆弱性データベースなど、より高度な機能を提供します。

2.5 CI/CDへのスキャンの統合

最大のユーティリティ（有用性）を得るために、イメージスキャンはソフトウェア開発ライフサイクル全体に貫徹されるべきです：

  • コミット前 / ビルド前： デベロッパーは、コードをコードレポジトリにプッシュする前に Dockerfile やローカルイメージをスキャンし、早期に問題を発見できます。
  • CI/CD パイプライン： 継続的インテグレーション (CI) パイプラインにスキャナをインテグレートします。イメージがビルドされるたびにスキャンを実行すべきです。"Critical"（深刻）または "High"（高）リスクの脆弱性が発見された場合、ビルドをフェイル（失敗）させるように設定し、安全でないイメージのデプロイをブロックできます。
  • イメージレジストリスキャン： 多くのコンテナレジストリ（Docker Hub、AWS ECR、Google Container Registry など）はビルトインのスキャン機能を提供しており、イメージのプッシュ時に自動的にスキャンを実行し、新しい脆弱性を発見するために定期的に再スキャンを行います。
  • ランタイムスキャン： プロダクション環境で実行されているデプロイ済みイメージを定期的にスキャンします。新しい脆弱性は毎日発見されるため、継続的なモニタリングが不可欠です。

2.6 イメージスキャンのベストプラクティス

  • 早期に、かつ頻繁にスキャンする： 開発パイプラインのすべてのステージにスキャンを組み込んでください。
  • リメディエーションの優先順位付け： すべての脆弱性が等しく重要というわけではありません。"Critical" および "High" の問題、特に容易にエクスプロイト（悪用）可能なものや、既知のエクスプロイトプログラムが存在するもの（ゼロデイ脆弱性など）の解決を優先してください。
  • 極小のベースイメージを使用する： 最小限のベースイメージ（Linux ディストリビューションの alpine や slim バリアントなど）から始めてください。これにより、スキャン対象のパッケージ数と潜在的なアタックサーフェスを劇的に減らすことができます。
  • イメージを最新の状態に保つ： 定期的にイメージを再ビルドし、ベースイメージと依存関係の最新バージョンをプルしてください。これらには通常、セキュリティパッチが含まれています。
  • ツールの特性を理解する： 使用するスキャナの機能と制限、脆弱性データベースのソース、およびフォールス・ポジティブ（誤検知）をどのように処理するかを明確に理解しておきましょう。

3. 実践演習: DCTとTrivyスキャン

具体的な例を通して、Docker Content Trust を有効にし、Trivy を使用してイメージスキャンを実行する方法をデモンストレーションします。

3.1 Docker Content Trust (DCT) のデモンストレーション

このデモンストレーションでは、Docker Hub アカウントが必要です。

1. DCTの有効化： ターミナルを開き、環境変数を設定します。

export DOCKER_CONTENT_TRUST=1

2. プッシュ用イメージの準備： シンプルな hello-world イメージを使用しましょう。あなたの Docker Hub ユーザー名でタグ付けします。

docker tag hello-world:latest あなたのdockerhubユーザー名/hello-world-signed:v1.0

(「あなたのdockerhubユーザー名」を実際の Docker Hub ユーザー名に置き換えてください。)

3. イメージのプッシュ（DCT有効化状態での初回）： DCTを有効にした状態で初めてイメージをプッシュする際、Docker は署名キーの設定をプロンプトで求めます。Root Key 用のパスフレーズを作成し、次にレポジトリキー用のパスフレーズを作成する必要があります。これらのパスフレーズは必ず記憶しておいてください！

docker push あなたのdockerhubユーザー名/hello-world-signed:v1.0

ターミナルの出力がパスフレーズの作成をガイドします。

The image you are pushing will be signed by newly generated content trust keys.
For more information, refer to https://docs.docker.com/engine/security/content-trust/

You are about to create a new root signing key. This key will be used to sign the
repository's trusted publishing key.

Please enter a passphrase for the new root key:
Repeat passphrase for new root key:
Please enter a passphrase for the new repository key:
Repeat passphrase for new repository key:
The push refers to repository [docker.io/your_dockerhub_username/hello-world-signed]
...
v1.0: digest: sha256:... size: 525
Signed trust metadata for "your_dockerhub_username/hello-world-signed:v1.0"

4. シグネチャの検証：docker trust inspect コマンドを使用して、イメージに関連付けられたトラストデータをチェックできます。

docker trust inspect --pretty あなたのdockerhubユーザー名/hello-world-signed:v1.0

このコマンドは、誰がイメージに署名したか、関連するキー、および有効期限を表示します。あなたの Docker Hub ユーザー名が署名者 (Signer) としてリストされているはずです。

5. 署名済みイメージのプルテスト（DCT有効化状態）： まず、ローカルイメージを削除して、ゼロからのプルをシミュレートします。

docker rmi あなたのdockerhubユーザー名/hello-world-signed:v1.0

次に、DCTを有効にしたままプルします：

DOCKER_CONTENT_TRUST=1 docker pull あなたのdockerhubユーザー名/hello-world-signed:v1.0

プルは成功するはずです。これは、シグネチャが正常に検証されたことを示しています。

6. 未署名イメージのプルテスト（DCT有効化状態）： 大部分のパブリックな hello-world イメージはデフォルトでは署名されていません。DCTを有効にした状態で、公式の未署名 hello-world イメージをプルしてみましょう。

DOCKER_CONTENT_TRUST=1 docker pull hello-world:latest

公式の hello-world:latest イメージはデフォルトで Docker Content Trust の下で署名されていないため、このコマンドは失敗するはずです。以下のようなエラーメッセージが表示されます：

Error: remote trust data not found for docker.io/library/hello-world:latest: notary.docker.io does not have trust data for docker.io/library/hello-world
(エラー: docker.io/library/hello-world:latest のリモートトラストデータが見つかりません: notary.docker.io にはこのイメージのトラストデータがありません)

これはDCTの保護メカニズムをデモンストレーションしています。トラストされたパブリッシャーによって明示的に署名されていないイメージのプルをブロックします。

7. DCTの無効化：

unset DOCKER_CONTENT_TRUST

3.2 Trivyを使用したイメージスキャン

1. Trivyのインストール： 公式 Trivy ドキュメントにある、お使いの OS 向けの指示に従ってインストールしてください。ほとんどの Linux システムでは、通常以下のようになります：

sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

macOS で Homebrew を使用する場合：

brew install trivy

2. サンプルイメージのスキャン： よく使われるイメージ、例えば nginx:1.21.0 をスキャンして、どのような脆弱性があるか見てみましょう。

trivy image nginx:1.21.0

出力には、以下を含む詳細なレポートが表示されます：

  • OS Packages (OSパッケージ): OSコンポーネント内で発見された脆弱性。
  • Libraries/Dependencies (ライブラリ/依存関係): アプリケーションレイヤーの依存関係が検出された場合（例えば、イメージに Node.js アプリが含まれている場合、package.json をスキャンします）、その中の脆弱性を表示します。
  • CVE ID: 共通脆弱性識別子。
  • Severity (重大度): Critical(深刻), High(高), Medium(中), Low(低), Unknown(未知)。
  • Installed Version (インストール済みバージョン): イメージ内の現在のパッケージバージョン。
  • Fixed Version (修正バージョン): その脆弱性を修正したバージョン。
  • Title/Description (タイトル/説明): 脆弱性の短いサマリー。

出力例（一部抜粋）：

nginx:1.21.0 (debian 11.0)
===========================
Total: 29 (CRITICAL: 2, HIGH: 5, MEDIUM: 8, LOW: 14, UNKNOWN: 0)

OS Packages:
+-----------------+------------------+----------+-------------------+---------------+-------------------------------------------------+
|     Library     | Vulnerability ID | Severity | Installed Version | Fixed Version |                     Title                       |
|   (ライブラリ)  |    (脆弱性 ID)   | (重大度) |(インストール済みV)| (修正バージョン)|                    (タイトル)                   |
+-----------------+------------------+----------+-------------------+---------------+-------------------------------------------------+
| openssl         | CVE-2023-0464    | HIGH     | 1.1.1n-0+deb11u4  | 1.1.1n-0+deb11u5| openssl: Integer overflow in PKCS7 parsing      |
+-----------------+------------------+----------+-------------------+---------------+-------------------------------------------------+
| systemd         | CVE-2022-2526    | MEDIUM   | 247.3-7+deb11u3   | 247.3-7+deb11u4| systemd: denial of service                      |
+-----------------+------------------+----------+-------------------+---------------+-------------------------------------------------+
| libexpat1       | CVE-2022-43680   | CRITICAL | 2.2.10-2+deb11u1  | 2.2.10-2+deb11u2| libexpat: double free vulnerability             |
+-----------------+------------------+----------+-------------------+---------------+-------------------------------------------------+
...

3. 重大度によるフィルタリング： 出力をフィルタリングして、特定の重大度以上の脆弱性のみを表示させることができます。これは、クリティカルな問題にフォーカスして対応する際に非常に有用です。

trivy image --severity CRITICAL,HIGH nginx:1.21.0

4. ローカルDockerfileのスキャン： Trivy は、ローカルの Dockerfile をスキャンしてコンフィギュレーションの問題を探し、さらに指定されたベースイメージを間接的にスキャンすることも可能です。まず、シンプルな Dockerfile を作成します：

# Dockerfile
FROM debian:11-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    git \
    && rm -rf /var/lib/apt/lists/*

COPY . /app
WORKDIR /app

CMD ["curl", "--version"]

次に、これをスキャンします：

trivy fs Dockerfile

これにより、debian:11-slim ベースイメージ、および RUN コマンドでインストールされたあらゆるパッケージ内の脆弱性がレポートされます。

出力例の断片（一部抜粋）：

Scanning `Dockerfile` for vulnerabilities...
( `Dockerfile` 内の脆弱性をスキャンしています...)

...

debian:11-slim (debian 11.7)
===========================
Total: 29 (CRITICAL: 2, HIGH: 5, MEDIUM: 8, LOW: 14, UNKNOWN: 0)

OS Packages:
+-----------------+------------------+----------+-------------------+---------------+-------------------------------------------------+
|     Library     | Vulnerability ID | Severity | Installed Version | Fixed Version |                     Title                       |
+-----------------+------------------+----------+-------------------+---------------+-------------------------------------------------+
| openssl         | CVE-2023-0464    | HIGH     | 1.1.1n-0+deb11u4  | 1.1.1n-0+deb11u5| openssl: Integer overflow in PKCS7 parsing      |
...

このような詳細な出力は、アップデートが必要な特定のパッケージを識別したり、代替のベースイメージへの切り替えを検討したりする際の強力な手がかりとなります。