Docker Scout は、イメージ コンテンツを分析して、パッケージと検出した脆弱性の詳細なレポートを生成します。イメージ分析によって見つかった問題を修正する方法を提案することができます。
このガイドでは、Docker Scout を使用してコンテナー イメージの脆弱性を特定して修正し、イメージのバージョンを経時的に比較し、その結果をチームと共有する方法を紹介します。
このガイドの内容は 2025年 10月時点の情報に基づいています。最新情報については、エクセルソフト株式会社までお問い合わせください。
サンプル プロジェクトには、脆弱性のある Node.js アプリケーションが含まれています。これを使用して以下の手順を実行します。
リポジトリをクローンします。
$ git clone https://github.com/docker/scout-demo-service.git
ディレクトリに移動します。
$ cd scout-demo-service
docker login
コマンド、または Docker Desktop を使用して Docker アカウントにサインインします。
イメージをビルドして <ORG_NAME>/scout-demo:v1
にプッシュします。ここで、<ORG_NAME>
はプッシュ先の Docker Hub 名前空間です。
$ docker build --push -t <ORG_NAME>/scout-demo:v1 .
Docker Scout は、デフォルトではすべてのローカル イメージを分析します。リモート リポジトリにあるイメージを分析するには、まず Docker Scout を有効にする必要があります。これは、Docker Hub、Docker Scout Dashboard、および CLI から行うことができます。手順については、こちらを参照してください。
docker login
コマンド、または Docker Desktop の [Sign in] ボタンを使用して、Docker アカウントにサインインします。
次に、docker scout enroll
コマンドを使用して、Docker Scout に組織を登録します。
$ docker scout enroll <ORG_NAME>
docker scout repo enable
コマンドを使用して、イメージ リポジトリで Docker Scout を有効にします。
$ docker scout repo enable --org <ORG_NAME> <ORG_NAME>/scout-demo
ビルド後、docker scout
CLI コマンドを使用して、Docker Scout によって検出された脆弱性を確認できます。
サンプル アプリケーションでは、Express の脆弱なバージョンが使用されています。次のコマンドは、ビルドしたイメージ内の Express に影響するすべての CVE を表示します。
$ docker scout cves --only-package express
Docker Scout はデフォルトで最後にビルドしたイメージを分析するため、この場合はイメージの名前を指定する必要はありません。
docker scout cves
コマンドについては、CLI リファレンス ドキュメント
を参照してください。
Docker Scout の分析により、express パッケージの古いバージョンに起因する、深刻度の高い脆弱性 CVE-2022-24999 が見つかりました。
express パッケージのバージョン 4.17.3 ではこの脆弱性が修正されています。そのため、package.json
ファイルを新しいバージョンに更新してください。
"dependencies": {
- "express": "4.17.1"
+ "express": "4.17.3"
}
新しいタグでイメージをリビルドし、Docker Hub リポジトリにプッシュします。
$ docker build --push -t <ORG_NAME>/scout-demo:v2 .
docker scout
コマンドを再度実行し、HIGH CVE-2022-24999 が存在しなくなったことを確認します。
$ docker scout cves --only-package express
✓ Provenance obtained from attestation
✓ Image stored for indexing
✓ Indexed 79 packages
✓ No vulnerable package detected
## Overview
│ Analyzed Image
────────────────────┼───────────────────────────────────────────────────
Target │ mobywhale/scout-demo:v2
digest │ ef68417b2866
platform │ linux/arm64
provenance │ https://github.com/docker/scout-demo-service.git
│ 7c3a06793fc8f97961b4a40c73e0f7ed85501857
vulnerabilities │ 0C 0H 0M 0L
size │ 19 MB
packages │ 1
## Packages and Vulnerabilities
No vulnerable packages detected
特定のパッケージに基づいて脆弱性を検査することは有用ですが、サプライ チェーンの行動規範を改善する最も効果的な方法ではありません。
Docker Scout は、イメージ内の問題を検出して修正するための高レベルな概念であるポリシー評価もサポートしています。ポリシーは、組織がイメージがサプライ チェーンの要件に準拠しているかどうかを追跡できるようにするための、カスタマイズ可能なルールのセットです。
ポリシー ルールは組織ごとに固有であるため、評価対象となる組織のポリシーを指定する必要があります。docker scout config
コマンドを使用して、Docker 組織を設定します。
$ docker scout config organization <ORG_NAME>
✓ Successfully set organization to <ORG_NAME>
これで、quickview
コマンドを実行して、作成したイメージのコンプライアンス ステータスの概要を取得できます。イメージはデフォルトのポリシー設定に基づいて評価されます。次のような出力が表示されます。
$ docker scout quickview
...
Policy status FAILED (2/6 policies met, 2 missing data)
Status │ Policy │ Results
─────────┼──────────────────────────────────────────────┼──────────────────────────────
✓ │ No copyleft licenses │ 0 packages
! │ Default non-root user │
! │ No fixable critical or high vulnerabilities │ 2C 16H 0M 0L
✓ │ No high-profile vulnerabilities │ 0C 0H 0M 0L
? │ No outdated base images │ No data
? │ Supply chain attestations │ No data
ステータス列の感嘆符 (!) は、ポリシー違反を示します。疑問符 (?) は、評価を完了するのに十分なメタデータがないことを示します。チェックマーク (✓) は、コンプライアンスに準拠していることを示します。
quickview
コマンドの出力には、改善の余地があることがわかります。イメージにプロべナンスと SBOM 証明が不足しているため、一部のポリシーは正常に評価できませんでした (No data
)。また、イメージはいくつかの評価でもチェックに失敗しました。
ポリシー評価は、脆弱性のチェックだけではありません。たとえば、Default non-root user
は、イメージがデフォルトで root
スーパーユーザーとして実行されないようにすることで、ランタイム セキュリティの向上に寄与します。
このポリシー違反に対処するには、Dockerfile を編集し、非 root ユーザーを指定する USER
命令を追加します。
CMD ["node","/app/app.js"]
EXPOSE 3000
+ USER appuser
さらに、より完全なポリシー評価結果を得るには、イメージに SBOM とプロべナンス証明を添付する必要があります。Docker Scout は、プロべナンス証明を使用してイメージがどのようにビルドされたかを判断し、より適切な評価結果を提供します。
証明付きイメージをビルドする前に、containerd イメージ ストアを有効にする (または、docker-container
ドライバーを使用してカスタム ビルダーを作成する) 必要があります。従来のイメージ ストアは、プロべナンス証明をイメージに添付するマニフェスト リストをサポートしていません。
Docker Desktop で [Settings] を開きます。[General] セクションで、[Use containerd for pulling and storing images] オプションがオンになっていることを確認し、[Apply] を選択します。イメージ ストアを変更すると、非アクティブなイメージ ストアのイメージとコンテナーは、元に戻すまで一時的に非表示になることに注意してください。
containerd イメージ ストアを有効にした状態で、新しい v3
タグを使用してイメージをリビルドします。今回は、--provenance=true
と --sbom=true
フラグを追加します。
$ docker build --provenance=true --sbom=true --push -t <ORG_NAME>/scout-demo:v3 .
証明付きの更新されたイメージをプッシュしたら、結果を Docker Scout Dashboard で確認してみましょう。
イメージ ページには、Scout 対応リポジトリの一覧が表示されます。
表示したいイメージの行 (リンクを除く行内の任意の場所) を選択すると、[Image details] サイドバーが開きます。
サイドバーには、リポジトリに最後にプッシュされたタグのコンプライアンス概要が表示されます。
注意
ポリシー結果がまだ表示されていない場合は、ページを更新してみてください。Docker Scout Dashboard を初めて使用する場合は、結果が表示されるまでに数分かかることがあります。
イメージ リストに戻り、[Most recent image] 列にあるイメージ バージョンを選択します。次に、ページの右上にある [Update base image] ボタンを選択して、ポリシーを確認します。
このポリシーは、使用するベース イメージが最新かどうかを確認します。サンプル イメージでは alpine
の古いバージョンをベース イメージとして使用しているため、現在は非準拠ステータスになっています。
[Recommended fixes for base image] モーダルを閉じます。ポリシー リストで、ポリシー名の横にある [View fixes] ボタンを選択すると、違反の詳細と対処方法に関する推奨事項が表示されます。
この場合、推奨されるアクションは、ベース イメージを自動的に最新の状態に保つのに役立つ Docker Scout の GitHub 統合を有効にすることです。
ヒント
このガイドで使用しているデモ アプリでは、この統合を有効にすることはできません。ご自身の GitHub リポジトリにコードをプッシュして、統合をお試しください。
このクイックスタート ガイドでは、Docker Scout がソフトウェア サプライ チェーン管理を支援するいくつかの方法について、基本的な内容を紹介しました。
サードパーティ統合、ポリシーのカスタマイズ、ランタイム環境のリアルタイム監視など、ほかにも多くの機能があります。
以下のセクションをご覧ください。