アプリケーションをコンテナ（Dockerなどで動く、実行環境ごとまとめた軽量なパッケージ）で動かす現場が増えています。「このイメージに危ない脆弱性が紛れ込んでいないか」を気にする開発・インフラ担当の方も多いのではないでしょうか。コンテナのイメージには、OSのパッケージからアプリの依存ライブラリまで大量の部品が詰め込まれ、そのどこかに既知の弱点や設定ミスが残っていることがあります。
この弱点を攻撃される前に見つけるのが「コンテナセキュリティスキャン」です。ひとことで言えば、イメージの中に入っている部品を取り出し、既知の脆弱性がまとめられたデータベースと照らし合わせて、危険なものを一覧として洗い出す仕組みを指します。言葉は知っていても、具体的に「何を・何と照らし合わせて・どんな結果が出るのか」までは、意外と整理しきれていないことも少なくありません。
本記事では、コンテナセキュリティスキャンの仕組みを入力から出力までかみ砕いて解説します。そのうえで、イメージのどこを検査するのか、開発から本番までどこでスキャンするのか、検出結果の優先順位の付け方、ツールやサービスの選び方までを順に見ていきます。自社のコンテナ運用のどこに何を仕込めばよいかを、具体的に判断できる状態を目指します。
一括ダウンロードする
目次
一括ダウンロードする
コンテナセキュリティスキャンとは
コンテナセキュリティスキャンとは、コンテナイメージの中に含まれる部品を取り出し、公開されている既知脆弱性のデータベースと突き合わせる検査です。対象となる部品はOSのパッケージ、アプリの依存ライブラリ、設定ファイル、埋め込まれた認証情報などで、該当する脆弱性や設定ミスを一覧で洗い出します。
出力されるのは「どの部品に、どの脆弱性（CVE番号）が、どのくらいの深刻度で存在し、どう直せばよいか」という具体的なリストになります。
照合先の代表が、米国国立標準技術研究所（NIST）が運用するNVD（National Vulnerability Database）です。NVDは、ソフトウェアの脆弱性や設定ミス、製品名、影響度などを標準化された形で蓄積した政府のデータベースで、脆弱性管理の自動化に使えるように公開されています。
個々の脆弱性にはCVE（共通脆弱性識別子）という番号が振られ、ツールはこの番号を手がかりにイメージ内の部品と照合します。
出典・参考資料（2件）
イメージを層ごとに分解し、既知脆弱性データベースと突き合わせる
コンテナイメージは、ベースとなるOSの上にミドルウェアやアプリを積み重ねた「層（レイヤー）」の構造になっています。スキャンは、この層を一枚ずつ分解して「どのパッケージのどのバージョンが入っているか」の一覧をつくり、それをNVDなどの既知脆弱性データベースと照合します。重要なのは、ベースの層だけでなく、その上に載せたアプリのフレームワークや自社で追加したソフトまで、すべての層を見ることです。
NISTが公表するコンテナセキュリティの指針「SP 800-190」も、脆弱性管理の要件として、すべての層の脆弱性を可視化することを挙げています。ベースの層だけでなく、その上に載せたアプリケーションフレームワークや独自開発のソフトまで含めて見る必要がある、という考え方です。表面だけを見るスキャンでは、積み重ねた層の奥に残った弱点を見逃してしまいます。
スキャンで見つけられること・見つけられないこと
この仕組みから、スキャンが得意なことと苦手なことが見えてきます。スキャンが見つけるのは、あくまで「すでに公開・登録された既知の脆弱性」です。まだ誰にも知られていない未知の脆弱性（ゼロデイ）や、プログラムの作りそのものに潜む論理的な欠陥は、既知脆弱性との照合では検出できません。
また、検出結果には「実際には悪用できない」ものが偽陽性として混じることもあります。スキャンは弱点の候補を網羅的に挙げてくれますが、それがそのまま「いますぐ直すべき危険」とは限りません。だからこそ、後述する優先順位づけと、他の検査手段（動的なアプリ診断や手動のペネトレーションテストなど）との組み合わせが前提になります。
スキャンは守りの出発点であって、これ一つですべてをまかなえるものではない、と捉えるのが実務的です。
スキャンで検査する対象（4種のリスクとSBOM・SCA）
「イメージを検査する」と言っても、見る対象は一つではありません。NISTのSP 800-190は、コンテナ技術のリスクをイメージ・レジストリ・オーケストレータ・コンテナ・ホストOSの5つに整理しています。このうちイメージのリスクは、さらに脆弱性・設定の不備・埋め込まれたマルウェア・平文の認証情報などに分けられます。
このうちスキャンで日常的に検査するのは、脆弱性・設定の不備・認証情報です（マルウェアの混入を検知するツールもあります）。さらに脆弱性は発生源でOSパッケージと依存ライブラリに分かれるため、イメージの中で検査する対象は、実務でまず押さえたい次の4種に整理できます。
- OSパッケージの既知脆弱性: ベースイメージに含まれるOS由来のパッケージ（ライブラリやコマンド）に残った既知の弱点。
- アプリの依存ライブラリの既知脆弱性: アプリが利用する外部ライブラリ（npm・pip・Mavenなどで導入したもの）の弱点。これを解析する仕組みはSCA（Software Composition Analysis、ソフトウェア構成分析）と呼ばれます。
- 設定の不備: 不要な権限でコンテナを動かす、rootで実行するなど、イメージやその設定に残ったセキュリティ上の問題。
- 埋め込まれた認証情報（シークレット）: APIキーやパスワードを平文のままイメージに含めてしまうケース。漏洩すると直接の侵入口になります。
この「イメージの中に何が入っているか」を一覧にしたものがSBOM（Software Bill of Materials、ソフトウェア部品表）です。米国の電気通信情報管理庁（NTIA）は、SBOMをソフトウェアを構成するさまざまな部品の詳細とサプライチェーン上の関係を記した公式な記録と定義しています。スキャンの前段で部品表をつくり、それを脆弱性データベースと照合する流れです。
SBOMを書き出す標準形式としては、SPDXとCycloneDXが広く使われています。
出典・参考資料（3件）
どこでスキャンするか（実施ポイント×目的×タイミング）
スキャンは一度どこかで実施すれば終わり、というものではありません。開発者の手元から本番の稼働環境まで、複数の場所で目的を変えて実施するのが基本です。SP 800-190も、脆弱性管理を、ビルドの最初からレジストリ、そして稼働時まで、イメージのライフサイクル全体に組み込むよう求めています。主な実施ポイントと、それぞれの目的・タイミングを整理すると次のようになります。
| 実施ポイント | 手元（開発者のローカル） | CI/CDのビルド時 | コンテナレジストリ | デプロイ直前（Admission Control） | 稼働中（ランタイム） |
|---|---|---|---|---|---|
| 主な目的 | コードを書いた直後に早く気づき、手戻りを減らす | リリース前に品質ゲートで止め、危険なイメージを先へ進めない | 保管中のイメージを継続的に見張り、新しく公表された脆弱性に気づく | 基準を満たさないイメージが本番で動き出すのを止める | 動いているコンテナの変化や、稼働後に判明した脆弱性を検知する |
| タイミング | コミット前・ビルド前 | プルリクエストやビルドのたび | 登録時と定期的な再スキャン | デプロイの要求時 | 稼働している期間はつねに |
※上記は一般的な実施ポイントの整理です。実際にどこで実施できるかは利用するツール・サービスによって異なります。
ここで出てくる「Admission Control」は、Kubernetes（コンテナをまとめて動かす基盤）がデプロイ要求を受け付ける際に、ポリシーに照らして可否を判断する仕組みの呼び名です。SP 800-190の言葉では、ビルドからデプロイまでの各段階に品質ゲートを設け、基準を満たさないイメージを先に進めないようにする考え方にあたります。
手元で早く気づき、ビルドやデプロイで止め、稼働後も見張る——この多段構えが、取りこぼしを減らす要になります。
一括ダウンロードする
CI/CDパイプラインへの組み込み方
実施ポイントのなかでも、多くの開発チームが最初に取り組むのがCI/CD（継続的インテグレーション／継続的デリバリー、ビルドやデプロイを自動化する仕組み）への組み込みです。プルリクエストやビルドのたびにスキャンを自動実行し、結果に応じて先へ進めるかどうかを判断させます。
組み込み方はシンプルで、ビルドのパイプラインにスキャンのステップを1つ足し、ビルドしたイメージを渡して実行させます。たとえばOSSのTrivyなら、ビルド済みのイメージ名を指定してスキャンを走らせ、検出された脆弱性の深刻度が決めた基準を超えたらビルドを失敗させる、という組み方ができます。
SP 800-190は、こうした品質ゲートをビルドの各段階に設け、たとえば深刻度が一定の基準を超える脆弱性を含むイメージは先へ進めない、といったルールを組めるようにすることを推奨しています。
ただし、最初からすべてを止める設定にすると、既存の脆弱性でビルドが通らなくなり、開発が止まってしまいます。実務では段階的に導入するのが現実的です。まずは結果を記録して現状を可視化し、次に警告だけを出す段階を置き、運用が落ち着いてから特定の条件でブロックへ切り替える、という進め方が無理がありません。ゲートをいきなり厳しくするのではなく、チームが対応できる範囲で少しずつ強めていきます。
検出結果の優先度の付け方（CVSS・EPSS・KEV・到達可能性）
イメージをスキャンすると、1つのイメージから数百件、ときに数千件の脆弱性が報告されることも珍しくありません。これは、ベースイメージに多数のパッケージが含まれ、そのすべてに過去の脆弱性情報が紐づくためです。全部を一度に直すのは現実的ではないので、「どれから直すか」を決める指標が要ります。代表的な指標は性格が異なり、組み合わせて使うのが実務の勘所です。
| 優先度の指標 | CVSS | EPSS | KEV（CISA） | 到達可能性（In-Use） |
|---|---|---|---|---|
| 測っているもの | 脆弱性の深刻度（悪用されたときの影響の大きさ） | その脆弱性が今後30日間に実際に悪用される確率 | すでに実際の攻撃で悪用が確認された脆弱性か | その脆弱なコードが実際に使われている・外部から届くか |
| 使い方の例 | 「重大」「高」を上位に置いて対応順を決める | 悪用されやすいものを前倒しで直す | 該当すれば最優先で対応する | 動いていない脆弱性を後回しにして件数を絞る |
※CVSS・EPSS・KEVの性格は各提供元（FIRST・CISA）の定義に基づき、到達可能性は一般的な考え方として整理しています。どの指標を使えるかは利用するツールによって異なります。
CVSS（共通脆弱性評価システム）は、脆弱性の主な特徴を数値にして深刻度を表す指標で、FIRST.orgが定義しています。一方、EPSS（悪用予測スコアリングシステム）は、公開済みの脆弱性が今後30日間に実際に悪用される確率を機械学習で推定するもので、深刻度とは別の「悪用されやすさ」を示します。
KEVは、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）が「実際に悪用が確認された脆弱性」を権威的に一覧化したカタログで、CISAは優先順位づけの入力として使うよう示しています。深刻度（CVSS）・悪用確率（EPSS）・実被害（KEV）を重ね、さらに「その脆弱性が自社の環境で本当に使われているか」という到達可能性で絞り込めば、数千件を「いま直すべき数件」へ現実的に落とし込めます。
出典・参考資料（3件）
コンテナスキャンのツール・サービスの選び方
ここまでの仕組みを実際に回すツールは、大きく3つのタイプに分かれます。どれが正解というより、自社の規模や運用体制に合うものを選ぶのが肝心です。OWASP（Webアプリのセキュリティに関する国際的な団体）のKubernetesセキュリティ資料でも、イメージの定期的なスキャンが基本動作として挙げられています。例として、ClairやTrivy、Aqua Securityといったツールが示されています。
まずはタイプごとの違いを整理します。
ツールのタイプ別の違い
| ツールのタイプ | OSSのイメージスキャナ | 商用の統合プラットフォーム | ランタイム保護型 |
|---|---|---|---|
| 代表的なツールの例 | Trivy、Grype、Clair、Syft など | Snyk、Aqua、Prisma Cloud、Sysdig など | NeuVector、Red Hat Advanced Cluster Security、Falco など |
| 主な検査対象 | イメージ内のOSパッケージ・依存ライブラリ | イメージ・依存ライブラリ・クラウド設定などを横断 | 稼働中コンテナの挙動・新たな脆弱性・不審な通信 |
| CI/CDへの組み込み | コマンドで実行し自前で組み込む | 連携機能が用意され、画面で一元管理できる | 稼働環境に常駐して監視する |
| 運用の負荷 | 導入は無料。設定・集計・更新は自社で担う | 費用がかかる一方、集計・優先度付け・修正支援まで任せられる | 実行時の監視基盤を運用する必要がある |
| 向いている企業の例 | 少数のイメージを自分たちで管理できる開発チーム | 複数チーム・多数のイメージをまとめて見たい組織 | 本番で動くコンテナの実行時リスクまで抑えたい組織 |
※ツール名は各タイプの代表例で、順位づけではありません。機能の詳細は各ツールの公式情報をご確認ください。
出典・参考資料（1件）
自前のOSS運用か、まとめて見られるSaaSか
選定で迷いやすいのが、無料のOSSを自分たちで運用するか、費用を払って統合型のSaaSに任せるか、という点です。判断の軸は「自社がどこまで運用に手をかけられるか」にあります。OSSは導入費用こそかかりませんが、CI/CDへの組み込み、検出結果の集計、優先順位づけ、脆弱性データベースの更新までを自社で回す必要があります。
イメージの数が少なく、担当者がコンテナの運用に慣れているチームなら、OSSで十分にまわせます。
一方、複数のチームが多数のイメージを扱い、クラウドの設定や稼働中のコンテナまで一つの画面で見たい場合は、統合型のSaaSが向きます。集計や優先順位づけ、修正の支援までまとめて引き受けてくれるため、担当者が「アラートを消し込むだけで一日が終わる」状態を避けやすくなります。費用対効果は、削減できる運用工数と、見落としによる事故の防止で判断します。
アラートをどう集約して対応を絞るかは、ツールを提供する側も運用の勘所として挙げています。脆弱性診断サービスを手がける株式会社AndGoの原氏は、現場でよく聞く悩みとして次のように話しています。
当社がよくお聞きするのは、「アラートが多すぎて、何が重要か分からなくなって放置が始まる」という悩みです。Aikido Securityは、バラバラだったアラートを統一し、対応すべきアラートを絞れるようにします。結果として、消し込み工数を減少でき、セキュリティ運用を“手に負える状態”に寄せていけます。
関連サービスの比較
以下は、コンテナのイメージ検査から稼働中の保護までを扱うサービスと、代表的なコンテナスキャンツールを比べた比較表です。自前のOSS運用と、まとめて見られるSaaSの違いを確認する際の目安としてご覧ください。
| サービス | Aikido Security | Snyk Container | Sysdig Secure | Trivy |
|---|---|---|---|---|
| 提供形態 | SaaS（クラウド型） | SaaS（クラウド型） | SaaS（クラウド型） | OSS（自前運用） |
| 主な検査対象 | イメージ・依存ライブラリ クラウド設定・ソースコード 稼働中アプリ（ランタイム保護） | コンテナイメージ・ベースイメージ 依存ライブラリ・IaC Dockerfileの設定 | イメージ・クラウド設定 稼働中コンテナの挙動 （ランタイム検知が中心） | イメージ・依存ライブラリ IaC設定・シークレット SBOM生成 |
| CI/CD連携 | ●CI/CD・IDE・SCM連携 | ●IDE・CLI・CI/CD・SCM連携 | ●CLI・Jenkins・GitHub Actions等 | ●CLI/Docker・GitHub Actions等 |
| 料金の目安 | 無料プランあり 有料は月額・年額制 （日本窓口は要お問い合わせ） | 無料プランあり 有料は月額$25〜 （上位プランは要お問い合わせ） | 要お問い合わせ （利用量ベース） | 無料（OSS） 商用版（Aqua）は要お問い合わせ |
| 向いている企業 | イメージ検査から稼働中まで 1画面でまとめて見たい 内製開発の企業 | 開発者の手元（IDE・PR）で 検査まで寄せたい開発チーム | 稼働中コンテナの実行時 リスクまで抑えたい組織 | 少数のイメージを自分たちで 管理できる開発チーム |
| 詳細情報 | 公式資料を見る | 公式サイト | 公式サイト | 公式サイト |
※料金・検査対象は2026年11月時点の各社公式情報に基づく整理で、掲載順は優劣を示すものではありません。最新の対応範囲・料金は各サービスの公式情報・お問い合わせでご確認ください。
Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコードや依存ライブラリ、クラウドの設定、コンテナイメージ、さらに稼働中のアプリケーションまでを一つの画面でまとめて検査できる、オールインワン型の脆弱性診断SaaSです。製品の開発元はベルギーのAikido Security BVで、日本では株式会社AndGoが提供窓口となっています。
コンテナまわりでは、イメージに含まれるOSパッケージや依存ライブラリの既知脆弱性の検出（SCA）に加え、クラウド設定の点検（CSPM）を扱います。さらに、IaC（Infrastructure as Code、インフラ構成をコードで管理する仕組み）の検査や、稼働中コンテナを守るランタイム保護までをカバーします。
単機能のツールを組み合わせると通知がばらばらに出て対応が追いつきにくくなりますが、検査を一つにまとめることで、対応すべきアラートを絞り込みやすくなる設計です。
本記事の主題であるコンテナのイメージ検査についても、開発の流れに組み込んで使うことを前提とした製品で、CI/CDやソースコード管理と連携させて回せます。イメージの検査で見つかった脆弱性を、クラウド設定や依存ライブラリの検出結果とあわせて一覧で確認できる点が、単機能のスキャナとの違いになります。
- 導入前に試せる無料プラン: 無料のDeveloperプランが用意されており、有料プランは月額・年額のサブスクリプション型です。SOC 2 Type IIとISO/IEC 27001:2022の監査報告にも言及しています。
- スキャン環境の選択: スキャンのたびに一時的なコンテナ環境でリポジトリを検査し、終了後に削除する方式が基本です。要件が厳しい場合は、自社環境内でスキャンする方式も選べます。
- 日本での提供: 日本では株式会社AndGoが窓口となり、料金は為替を踏まえた日本円で案内されます（2026年11月時点。正確な金額は要お問い合わせ）。
出典・参考資料（3件）
コンテナのイメージ検査に限らず、Webアプリや社内システムも含めた自社全体の脆弱性診断サービスを、診断方法・費用相場・診断後のサポートから見比べたい場合は、以下の記事で主要サービスを整理しています。導入を本格的に検討する際の土台としてご覧ください。
継続的に運用するための勘所
コンテナセキュリティスキャンは、一度実施して終わりにはできません。NISTのSP 800-190は、イメージがアプリの実行に必要な部品をすべて含んだ、実質的に静的なアーカイブだと説明しています。
そのため、ビルド時点では最新でも、時間が経つと中の部品が古くなり脆弱性を抱えやすくなります。今日きれいだったイメージも、新しい脆弱性が公表されれば明日には危険なイメージに変わりうるということです。
そのため継続運用では、これまでの実施ポイントや優先度づけを「回し続ける」ことに加えて、土台となるベースイメージの扱いが独自の勘所になります。余計なパッケージを含まない信頼できる軽量なベースイメージを選び、こまめに更新して古い部品を持ち越さないことが基本です。
加えて、ビルド専用のツールを最終イメージに残さない多段ビルドで、攻撃対象そのものを減らせます。そのうえで、レジストリに保管したイメージの定期的な再スキャンと、検出結果を優先順位に沿って処理し対応を記録に残す運用を、仕組みとして回し続けます。
OWASPもイメージの定期的なスキャンを基本動作として挙げており、「入れっぱなし」にしない運用が前提になります。
出典・参考資料（2件）
こうした「スキャンのあと」——検出結果の優先順位づけや対応状況の管理を、イメージだけでなくサーバーやクラウド、自社コードの依存ライブラリまで横断して回したいこともあります。その場合は、脆弱性管理ツールという選択肢もあります。守りたい対象のカバー範囲・SBOM対応・優先順位づけの自動化という観点での選び方を、以下の記事で整理しています。
まとめ
コンテナセキュリティスキャンは、イメージの中の部品を取り出して既知脆弱性データベースと照合し、危険な箇所を一覧で洗い出す仕組みです。検査の対象はOSパッケージ・依存ライブラリ・設定の不備・埋め込まれた認証情報に分けられ、SBOMで部品を棚卸ししてから照合します。
実務では、手元・CI/CD・レジストリ・デプロイ直前・稼働中の各ポイントで目的を変えてスキャンし、大量に出る結果はCVSS・EPSS・KEV・到達可能性を重ねて「いま直すべき数件」に絞り込みます。ツールは自前で運用するOSSと、集計や優先順位づけまで任せられる統合型のSaaSに大別され、自社がどこまで運用に手をかけられるかで選びます。
まずは自社のコンテナ運用のどこにスキャンを仕込むかを一つ決めるところから、継続できる体制づくりを始めてみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. コンテナセキュリティスキャンとは何ですか？
A. コンテナセキュリティスキャンとは、コンテナイメージに含まれる部品（OSパッケージ・依存ライブラリ・設定・認証情報）を取り出し、既知脆弱性データベースと照合して危険な箇所を一覧で洗い出す検査です。照合先の代表はNISTが運用するNVD（National Vulnerability Database）で、各脆弱性に振られたCVE番号を手がかりに、イメージ内の部品と突き合わせます。
出力されるのは「どの部品に、どのCVEが、どのくらいの深刻度で存在し、どう直せばよいか」という具体的なリストです。
Q. コンテナセキュリティスキャンは無料ツールだけで実施できますか？
A. コンテナセキュリティスキャンは、TrivyやGrype、ClairといったOSS（無償のオープンソースツール）だけでも実施できます。これらはコマンドで実行して、イメージ内のOSパッケージや依存ライブラリの既知脆弱性を検出できます。OWASPのKubernetesセキュリティ資料でも、イメージを定期的にスキャンする標準的な手段として挙げられています。
ただし、CI/CDへの組み込み・検出結果の集計・優先順位づけ・脆弱性データベースの更新は自社で回す必要があり、扱うイメージが増えるほど運用の負荷は上がります。複数チームで多数のイメージを一元管理したい場合は、集計や優先度付けまで任せられる商用SaaSが向きます。
出典・参考資料（1件）
Q. コンテナセキュリティスキャンとランタイム保護（実行時保護）は何が違いますか？
A. コンテナセキュリティスキャンはビルドや保管の段階でイメージの中身を静的に検査するのに対し、ランタイム保護は稼働中のコンテナの挙動や通信を実行時に監視する点が異なります。スキャンは「本番に出す前に危険なイメージを止める」ための検査で、既知脆弱性・設定の不備・埋め込まれた認証情報を洗い出します。
一方のランタイム保護は、稼働後に新たに公表された脆弱性や、不審なプロセス・通信といった「動き出してから現れるリスク」を検知します。両者は競合する手段ではなく、ビルド前の検査と稼働後の監視として組み合わせて使うものです。
Q. コンテナセキュリティスキャンで脆弱性が数百件以上出たときは、何から対応すればよいですか？
A. コンテナセキュリティスキャンで大量の脆弱性が出たときは、深刻度（CVSS）・悪用確率（EPSS）・実際に悪用された実績（CISAのKEV）・自社環境での到達可能性を重ねて、いま直すべき数件に絞り込みます。1つのイメージから数百〜数千件が報告されるのは、ベースイメージに多数のパッケージが含まれ、そのすべてに過去の脆弱性情報が紐づくためで、すべてを一度に直すのは現実的ではありません。
まずKEVに該当するものや、悪用確率が高く自社で実際に使われている脆弱性を優先し、動いていないコードの脆弱性は後回しにすると、件数を対応できる量まで落とし込めます。
Q. コンテナセキュリティスキャンとSBOMはどう関係しますか？
A. SBOMはイメージの中に含まれる部品を一覧にした「ソフトウェア部品表」で、スキャンはこの部品表を既知脆弱性データベースと照合して脆弱性を洗い出します。SBOMはスキャンの前段にあたり、「何が入っているか」を棚卸ししたうえで「そのどれに既知の弱点があるか」を突き合わせる流れです。
SBOMを書き出す標準形式にはSPDXとCycloneDXがあり、部品表を残しておくと、後から新しい脆弱性が公表されたときにも「自社のイメージに該当する部品が含まれるか」をすばやく確認できます。
Q. コンテナセキュリティスキャンはどのくらいの頻度で実施すべきですか？
A. コンテナセキュリティスキャンは一度きりではなく、ビルドのたびに実施し、加えてレジストリに保管したイメージを定期的に再スキャンするのが基本です。NISTのSP 800-190は、イメージが実質的に静的なアーカイブであるため、ビルド時点では最新でも、時間が経つと中の部品が古くなり脆弱性を抱えやすいと指摘しています。
今日問題のなかったイメージも、新しい脆弱性が公表されれば翌日には危険なイメージに変わりうるため、プルリクエストやビルド時の検査に加えて、保管中のイメージの定期的な再スキャンを組み合わせます。
Q. スキャンを入れるとCI/CDのビルドは遅くなりませんか？
A. 多くのスキャナは数秒から数分で完了し、脆弱性データベースやレイヤーのキャッシュを使うことでビルドへの影響を抑えられます。初回は時間がかかっても、2回目以降は変化した部分だけを検査して短縮できる仕組みが一般的です。
それでも重く感じる場合は、ビルド時は深刻度の高いものだけを対象にして素早く判定し、全件の詳細なスキャンはレジストリでの定期実行に分ける、といった使い分けで、開発のテンポとのバランスを取れます。
脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、コンテナを含む自社システムの脆弱性診断・セキュリティ診断サービスの最新資料を無料で一括請求できます。検査できる範囲や料金、サポート体制を見比べて選べます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
