DockerやKubernetesを使ったコンテナの本番運用が広がる一方で、「自社のコンテナ環境に、拠り所となるセキュリティ基準はあるのか」という問いに、すぐ答えられる現場は多くありません。自己流で対策を決めても、監査や取引先への説明の場面で根拠を示しづらいという悩みもよく聞かれます。
コンテナセキュリティの基準づくりでまず参照したいのが、米国の国立標準技術研究所（NIST）が公開するガイドライン「NIST SP800-190（アプリケーションコンテナセキュリティガイド）」です。コンテナ固有のリスクと対策を、イメージからホストOSまで体系的に整理した公式文書として、コンテナセキュリティの分野で広く参照されています。
本記事では、NIST SP800-190が何を定めているのかを、5つのコアコンポーネント別のリスクと対策として整理します。あわせて、CIS Benchmarksなど併用される基準との違い、AWS FargateやKubernetesなど環境ごとの責任分界、基準づくりの着手手順、準拠を点検する方法までを解説します。
自社のコンテナセキュリティ基準を作る、あるいは見直すための検討材料としてご活用ください。
目次
一括ダウンロードする
コンテナセキュリティのガイドラインはNIST SP800-190
コンテナセキュリティの基準づくりで最初の拠り所になるのが、NIST SP800-190（Application Container Security Guide）です。米国の国立標準技術研究所（NIST）が2017年9月に公開したもので、コンテナ技術に固有のセキュリティ上の懸念と、それに対処するための推奨事項を体系的にまとめています。
この文書は、コンテナの計画・実装・保守の各段階で何をすべきかを示すもので、自らの目的を次のように定めています。
本文書の目的は、アプリケーションコンテナ技術に関連するセキュリティ上の懸念事項を説明し、コンテナの計画、実装、保守を行う際に、それらの懸念事項に対処するための実践的な推奨事項を提供することである。仮想マシンなど、アプリケーションコンテナ以外のすべての仮想化の形態は、本文書の範囲外である。
出典：NIST SP800-190（IPAによる日本語訳）1.1 目的とスコープ
NIST SP800-190は英語の原典に加えて、独立行政法人情報処理推進機構（IPA）による日本語訳（非公式翻訳）が公開されています。原典・日本語訳とも無償で読めるため、自社の基準づくりの根拠として引用する際は、下記の原文にあたって確認することをおすすめします。
ISO/IEC 27001やPCI DSSといった一般的な情報セキュリティの基準は組織全体の管理策を広く扱いますが、イメージやオーケストレータといったコンテナ固有のリスクを個別には扱いません。NIST SP800-190は、こうした一般的な枠組みでは拾いきれないコンテナ固有の観点を補う文書と位置づけると、既存の社内基準とも整理して併用できます。
出典・参考資料（2件）
NIST SP800-190が定める5領域のリスクと対策一覧
ここからは、NIST SP800-190の核心である「どこに、どんなリスクがあり、何をすべきか」を見ていきます。NIST SP800-190は、コンテナ技術を5つのコアコンポーネントに分けてリスクを分析し、それぞれに対策を1対1で対応づけています。
本節では、コンテナ技術のコアコンポーネントであるイメージ、レジストリ、オーケストレータ、コンテナ、ホストOSの主要なリスクを特定し、分析する。この分析は、コアコンポーネントのみを対象としているため、コンテナ技術、ホストOSプラットフォーム、ロケーション（パブリッククラウド、プライベートクラウドなど）に関係なく、ほとんどのコンテナのデプロイに適用できる。
出典：NIST SP800-190（IPAによる日本語訳）3 コンテナ技術のコアコンポーネントの主なリスク
この5つのコアコンポーネントの関係を図にすると、次のようになります。
5領域のリスクは第3章（3.1〜3.5）で、対応する対策は第4章（4.1〜4.5）で定義されています。さらに第4章には、第3章にリスク項目を持たない「4.6 ハードウェアの対策」も加えられています。まずは全体像を、5領域と対策のみのハードウェア（4.6）を合わせた計6行の一覧で、自社の基準表に写せる形で確認してください。
| NIST SP800-190の5領域別リスクと対策の対応表 | イメージ | レジストリ | オーケストレータ | コンテナ | ホストOS | ハードウェア（対策のみ） |
|---|---|---|---|---|---|---|
| 主なリスク（第3章） | 脆弱性／設定の不備／埋め込まれたマルウェア／埋め込まれた平文の秘密情報／信頼できないイメージの使用 | セキュアでない接続／古いイメージの残存／認証・認可の不十分な制限 | 制限のない管理者アクセス／不正アクセス／コンテナ間通信の不十分な分離／機微性レベルの混合／ノードの信頼 | ランタイムの脆弱性／無制限のネットワークアクセス／セキュアでないランタイム設定／アプリの脆弱性／未承認コンテナ | 大きなアタックサーフェス／共有カーネル／OSコンポーネントの脆弱性／不適切なユーザアクセス権／ファイルシステムの改ざん | （第3章に対応リスク項目なし） |
| 推奨対策の方向（第4章） | コンテナ向けの脆弱性管理、イメージの設定点検、信頼できるイメージのみの利用 | 通信の暗号化、古いイメージの管理、アクセス制御の厳格化 | 最小権限の管理アクセス、認証強化、ネットワーク分離、機微性に応じた分離 | ランタイムの保護、通信の制限、安全な設定、実行時の監視 | コンテナ専用の最小構成OS、カーネルの保護、権限管理、改ざん検知 | 信頼の基点（ハードウェアルートオブトラスト）を用いた基盤の信頼性確保 |
| 対応する節 | 3.1 / 4.1 | 3.2 / 4.2 | 3.3 / 4.3 | 3.4 / 4.4 | 3.5 / 4.5 | 4.6 |
※NIST SP800-190（IPA日本語訳）第3章・第4章の節構成にもとづく整理です。リスク・対策の詳細は各節の原文をご確認ください。
NIST SP800-190は2017年に公開された文書です。発行から年数は経っていますが、5領域の分類とリスク・対策の考え方はコンテナ技術の基本構造に根ざしており、現在のKubernetesやサーバーレス型のコンテナ基盤にもそのまま当てはめて読めます。環境による違いは、どのリスクを自社が受け持つかという責任分界に表れるため、その点は後半の環境別の当てはめで整理します。
イメージのリスクと対策（3.1／4.1）
イメージは、アプリケーションと実行環境をまとめた「設計図」にあたり、ここに含まれる問題はそのまま多数のコンテナに複製されます。NIST SP800-190は、古いライブラリに起因する脆弱性、不要な権限やポートを含む設定の不備、埋め込まれたマルウェアやパスワード・鍵などの秘密情報、出所の不確かなイメージの利用を主なリスクとして挙げています。
対策の中心は、コンテナに特化した脆弱性管理です。この点についてNIST SP800-190は、従来型のツールではコンテナ内部の脆弱性を見落としやすいと明確に指摘しています。
コンテナ技術に特化した脆弱性管理ツールおよびプロセスが必要となる。従来の脆弱性管理ツールは、ホストの耐久性やアプリの更新メカニズムや頻度について多くの仮定をしているが、それらはコンテナ化されたモデルとは根本的にずれている。これらのツールは、コンテナ内の脆弱性を検知できないことが多く、誤った安心感をもたらす。
出典：NIST SP800-190（IPAによる日本語訳）4.1.1 イメージの脆弱性
そのため、ビルドの段階でイメージを検査し、脆弱性の深刻度に応じてリリースを止める品質ゲートを設ける運用が推奨されます。あわせて、秘密情報をイメージに埋め込まない仕組み、信頼できるイメージだけを使う運用も、この領域の基本的な打ち手になります。
レジストリのリスクと対策（3.2／4.2）
レジストリは、イメージを保管・配布する倉庫です。NIST SP800-190は、暗号化されていない通信によるイメージの盗聴・改ざん、脆弱性が放置された古いイメージの残存、だれでも読み書きできてしまう認証・認可の甘さをリスクとして整理しています。
対策としては、レジストリへの接続を暗号化し、古いイメージを定期的に棚卸しして使わせない仕組みを整え、イメージの登録・取得を役割に応じて制限することが挙げられます。開発の利便性を優先してアクセス制御を緩めがちな領域なので、運用ルールとして明文化しておくことが重要です。
とくに古いイメージの残存は見落としやすいリスクです。公開済みの脆弱性が未修正のまま倉庫に残り、気づかないうちに再利用されることがあるため、保持期間や自動削除のルールを運用として決めておくと安全です。
オーケストレータのリスクと対策（3.3／4.3）
Kubernetesに代表されるオーケストレータは、多数のコンテナの配置や通信を束ねる管制塔です。影響範囲が広いぶん、管理者権限の広すぎる付与、正規の手続きを経ない不正アクセス、コンテナ間通信が分離されていないこと、機密度の異なるワークロードの混在、信頼できないノードの参加が、いずれも重大なリスクになります。
NIST SP800-190は、役割ごとに権限を絞る最小権限の管理アクセス、強固な認証、ネットワークの分離、機密度に応じたワークロードの振り分けを推奨しています。権限とネットワークの設計がこの領域の中心で、後述するアクセス制御（RBAC）の設定とも密接に関わります。
設計の勘所は、人とワークロードの両面で「つながりを絞る」ことです。RBACで役割ごとに操作できる範囲を限定し、ネットワークポリシーでコンテナ間の通信を既定で遮断してから必要な経路だけを開けると、1か所の侵害が横に広がりにくくなります。
コンテナのリスクと対策（3.4／4.4）
実行中のコンテナそのものにも固有のリスクがあります。コンテナを動かすランタイムの脆弱性、外部と自由に通信できてしまう状態、安全でないランタイム設定、アプリ自体の脆弱性、承認されていないコンテナの実行が、NIST SP800-190の挙げる主なリスクです。
これらには、ランタイムを保護し、通信を必要な範囲に限定し、安全な設定で起動し、実行中の挙動を監視することで対処します。ビルド時の対策だけでは防ぎきれない、実行時（ランタイム）ならではの打ち手が求められる領域です。
要になるのは、イメージ検査をすり抜けた脅威への備えです。たとえば想定外のプロセス起動や外部への通信を実行中に検知できるようにしておくと、ビルド段階では問題がなかったコンテナの異常にも気づけます。
ホストOSのリスクと対策（3.5／4.5）
コンテナは、ホストOSのカーネルを共有して動きます。そのためホストOSが侵害されると、その上で動くすべてのコンテナに影響が及びます。NIST SP800-190は、不要な機能による大きなアタックサーフェス、カーネル共有に起因するリスク、OSコンポーネントの脆弱性、過剰なユーザ権限、ファイルシステムの改ざんをリスクとして整理しています。
対策は、コンテナ実行に特化した最小構成のOSを使い、カーネルを保護し、ユーザー権限を絞り、改ざんを検知する仕組みを備えることです。このホストOSの領域は、後述するマネージドなコンテナ基盤を使うと、利用者の受け持ちが大きく変わる部分でもあります。
カーネルを共有する構造上、ホストOSの1つの脆弱性が全コンテナの侵害につながりかねません。余計なサービスを載せない専用OSを選び、万一に備えてコンテナを隔離する仕組みを併用すると、影響範囲を抑えられます。
NIST SP800-190とCIS Benchmarksの違いと使い分け
コンテナセキュリティの基準を調べると、NIST SP800-190と並んで「CIS Benchmarks」がよく登場します。両者は競合するものではなく、役割が異なります。結論を先にいえば、NIST SP800-190が「何を守るべきか」という原則を示すのに対し、CIS Benchmarksは「どう設定すべきか」という具体的な設定値を示す関係です。
CIS Benchmarksは、非営利団体のCenter for Internet Security（CIS）が、世界のセキュリティ専門家の合意にもとづいて公開している設定推奨です。DockerとKubernetesの両方にベンチマークがあり、具体的な設定項目を点検できる形で提供されています。
The CIS Benchmarks® are prescriptive configuration recommendations for more than 25+ vendor product families.
出典：CIS Benchmarks｜Center for Internet Security
設定値の例を挙げると、CIS Docker Benchmarkには次のような項目があります。
- コンテナをroot権限で実行しない
- 付与するLinuxケーパビリティを必要最小限に絞る
- ルートファイルシステムを読み取り専用でマウントする
CIS Kubernetes Benchmarkには、APIサーバーで匿名アクセス（–anonymous-auth）を無効にする、特権コンテナ（privileged）の許可を最小化する、といった項目が並びます。
NIST SP800-190が示す対策の方向（たとえば4.4のコンテナに対する最小権限・ランタイム保護）を、こうした具体的な設定値に落とし込むと、自社の基準表に「何を・どう設定するか」まで書き込めます。項目の詳細や番号はベンチマークの版により異なるため、適用時に最新版を確認してください。
両者の位置づけを整理すると、次のようになります。NIST SP800-190でリスクと対策の全体像を押さえ、CIS Benchmarksで個々の設定値を点検する、という順に使うと基準づくりがスムーズです。
| NIST SP800-190とCIS Benchmarksの役割分担 | 位置づけ | 抽象度 | 主な対象 | 発行元 |
|---|---|---|---|---|
| NIST SP800-190 | コンテナ固有のリスクと対策を示す推奨事項（ガイド） | 何を守るべきか（原則・方針） | イメージ〜ホストOSの5領域全体 | 米国国立標準技術研究所（NIST） |
| CIS Benchmarks | 具体的な設定値の推奨（設定ベンチマーク） | どう設定すべきか（具体値・項目） | Docker・Kubernetesの設定（マネージド版の派生もあり） | Center for Internet Security（CIS・非営利団体） |
※2026年11月時点の各発行元の公式情報にもとづく整理です。
出典・参考資料（2件）
クラウド・プラットフォーム別の当てはめと責任分界
NIST SP800-190の5領域は環境を問わず適用できますが、「どのリスクを自社が受け持つか」は、使うコンテナ基盤によって変わります。ここを取り違えると、クラウド側が守る部分を二重に対策したり、逆に自社が守るべき部分を見落としたりします。基準づくりでは、この責任分界を環境ごとに確認しておくことが欠かせません。
クラウドの責任分界の原則として広く用いられているのが、AWSの「責任共有モデル」です。クラウド事業者と利用者の責任範囲を、基盤側と利用側で切り分けて示しています。
AWS responsibility “Security of the Cloud” — AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud.
出典：AWS 責任共有モデル（Shared Responsibility Model）｜Amazon Web Services
Customer responsibility “Security in the Cloud” — Customer responsibility will be determined by the AWS Cloud services that a customer selects.
ここで重要なのは、利用者の責任範囲が「選んだサービスによって決まる」という点です。たとえば同じコンテナでも、仮想マシン（Amazon EC2）や自前のKubernetes上で動かすか、サーバー管理の不要なAWS Fargateで動かすかで、ホストOSの受け持ちが変わります。
AWS Fargateの場合、NIST SP800-190でいうホストOS（3.5／4.5）の領域、すなわちOSのパッチ適用やノード管理、SSHによる保守といった作業が利用者から外れ、AWS側に移ります。AWSはEKSの公式ドキュメントで、Fargateでは次の3点が不要になると明記しています。
Must secure, maintain, and patch the operating system of Amazon EC2 instances — No
出典：Amazon EKS ユーザーガイド（Fargate 比較表）｜Amazon Web Services
Can SSH into node — No – There’s no node host operating system to SSH to.
Must update node Kubernetes version on your own — No – You don’t manage nodes.
これは、Amazon EC2のインスタンスを使う場合に必要なOSの保守・パッチ、ノードへのSSH、ノードのKubernetesバージョン更新が、Fargateではいずれも不要になることを示しています。
ただし、マネージドな基盤を使っても、責任共有モデル上の利用者の責任そのものが消えるわけではありません。AWS自身、EKSの利用が責任共有モデル上の責任を変えるものではなく、クラスタのセキュリティやガバナンスの設定は利用者が慎重に検討すべきだと述べています。イメージの脆弱性管理、アクセス制御、アプリの脆弱性といった領域は、Fargateを使っても引き続き自社の受け持ちです。
Using Amazon EKS doesn’t change your responsibilities under the shared responsibility model. You should carefully consider the configuration of cluster security and governance controls.
出典：Amazon EKS ユーザーガイド「Simplify compute management with AWS Fargate」｜Amazon Web Services
基盤タイプごとに、NIST SP800-190の領域を「事業者が守る／自社が守る」で整理すると、受け持ちの違いは主にホストOSまわりに表れます。
| コンテナ基盤タイプ別の責任分界（NIST SP800-190の領域別） | ホストOS・ノード管理（3.5／4.5） | クラスタ・オーケストレータの設定（3.3／4.3） | イメージ・アプリの脆弱性（3.1・3.4／4.1・4.4） | アクセス制御（RBAC）・ネットワーク分離 |
|---|---|---|---|---|
| 自前Kubernetes・オンプレミス | 自社 | 自社 | 自社 | 自社 |
| マネージド型Kubernetes（Amazon EKS など） | 一部は事業者＋自社 | 自社 | 自社 | 自社 |
| サーバーレス型（AWS Fargate など） | 事業者 | 自社 | 自社 | 自社 |
※AWSの責任共有モデルおよびEKSのFargateドキュメントにもとづくNIST SP800-190の領域別整理です。マネージドの範囲はサービス・設定により異なります。
自前のKubernetesやオンプレミスで運用する場合は、ホストOSの手当ても含めて5領域のほぼ全体が自社の受け持ちになります。逆に、マネージドなサービスを使うほどホストOSやノードの管理は事業者側に寄り、自社はイメージ・アプリ・設定・アクセス制御に注力できます。
自社がどの基盤を使っているかに照らして、NIST SP800-190の各領域を「事業者が守る／自社が守る」に振り分けておくと、対策の抜け漏れと重複を防げます。
OpenShiftやAzureのコンテナサービスでも、マネージドの範囲に応じて同じ考え方を当てはめられます。自社が使う環境でどこまでが事業者の守備範囲かは、各社の公式ドキュメントで確認してください。
AWS上で運用している場合、自社の受け持ち部分の脆弱性診断を具体的にどう進めるか（自己診断と外部ベンダー診断の使い分け、AWSへの事前申請の要否など）は、以下の記事で解説しています。
出典・参考資料（2件）
コンテナセキュリティ基準づくりの進め方（着手ステップ）
ここからは、NIST SP800-190を自社の基準づくりに落とし込む進め方を整理します。NIST SP800-190は第6章で、コンテナ技術のライフサイクルを5つのフェーズに分けて考慮事項を示しています。この5つのフェーズを実務の着手順に組み替えたのが、以下の導入ステップです。
コンテナ技術のインストール、設定、およびデプロイを行う前に、慎重に計画を立てることが非常に重要である。これにより、コンテナ環境が可能な限りセキュアであり、関連するすべての組織のポリシー、外部規制、およびその他の要件に準拠していることを確実にすることができる。
出典：NIST SP800-190（IPAによる日本語訳）6 コンテナ技術のライフサイクルにおけるセキュリティに関する考慮事項
打ち手は、開発の早い段階で対処する「シフトレフト」の工程と、実行中に守る「実行時」の工程に分かれます。下表は、ライフサイクルに沿った着手順と、各段階の主な打ち手、対応するNIST SP800-190の節を整理したものです。
| コンテナセキュリティ基準づくりの着手ステップ | 1. 開始・計画／設計 | 2. 実装（ビルド） | 3. 実装（デプロイ） | 4. 運用・保守 | 5. 廃棄 |
|---|---|---|---|---|---|
| 主な打ち手 | 守る対象（5領域）と責任分界の確認、セキュリティポリシーの文書化 | イメージスキャン、秘密情報の排除、信頼できるイメージの利用、設定の点検（シフトレフト） | 最小権限・アクセス制御（RBAC）、ネットワーク分離、安全なランタイム設定 | 実行時の監視、脆弱性の継続的な検知とパッチ、設定の逸脱検知 | 不要なイメージ・コンテナ・秘密情報の安全な削除 |
| 組み込む工程 | 計画 | CI/CD（シフトレフト） | デプロイ | 実行時 | 実行時 |
| 対応する節 | 6.1 / 6.2 | 6.3 / 4.1・4.2 | 6.3 / 4.3・4.4 | 6.4 / 4.4・4.5 | 6.5 |
※NIST SP800-190（IPA日本語訳）第6章のライフサイクル区分にもとづく整理です。
すべてを一度に整えるのは現実的ではありません。優先順位としては、被害が複製されやすいイメージの検査（ステップ2）と、影響範囲の広いアクセス制御・ネットワーク分離（ステップ3）から着手し、実行時の監視（ステップ4）へ広げていくのが取り組みやすい順序です。
こうした「開発の早い段階で作り込む」進め方が基本になってきた背景には、開発現場でのセキュリティの位置づけそのものの変化があります。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。
準拠を確認・維持する方法（チェックリスト・点検ツール・継続監視）
基準を作ったら、それが守られているかを点検し、維持する仕組みが必要です。本記事前半の5領域のリスクと対策の一覧を点検項目のたたき台として使い、定期的に見直すのが基本です。
設定値の点検には、CIS Benchmarksに対応したツールが役立ちます。たとえばKubernetesの構成を点検するkube-benchは、CIS Kubernetes Benchmarkのチェックを実行して、安全に構成されているかを確認するツールです。
kube-bench is a tool that checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark.
出典：kube-bench（GitHub・Aqua Security）README
こうした点検は一度きりでは意味を持ちません。イメージは日々更新され、新たな脆弱性も次々と公表されるため、ビルドのたびのイメージ検査と、実行中の継続的な監視を組み合わせて、基準への準拠を保ち続けることが重要です。設定の点検・脆弱性の検知・実行時の監視を自動化しておくと、運用の負担を抑えながら準拠を維持できます。
出典・参考資料（1件）
- 参考資料：kube-bench｜Aqua Security（GitHub）（リンク）
一括ダウンロードする
コンテナの脆弱性を点検するサービス
NIST SP800-190に沿って基準を整えても、イメージやコンテナの脆弱性を自社だけで継続的に検査・点検するのは負担が大きいものです。そうした場合は、コンテナやイメージの脆弱性を検査できる診断サービス・ツールを使うと、準拠状況の確認を効率よく進められます。ここでは、コンテナやイメージの脆弱性検査に対応するサービスを紹介します。
ここで取り上げるのはコンテナ・イメージの検査に対応するサービスに絞った紹介です。脆弱性診断サービス全体の診断方法・費用相場・選び方から比較検討したい場合は、以下の記事もあわせてご覧ください。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
まずは各サービスの対応領域を一覧にまとめました。
| コンテナ・イメージの脆弱性検査への対応比較 | Aikido Security | Checkmarx | Securify（セキュリファイ） | Veracode |
|---|---|---|---|---|
| 提供会社 | 株式会社AndGo （開発元：Aikido Security BV） | Checkmarx Ltd. | 株式会社スリーシェイク | Veracode, Inc. |
| コンテナ/イメージの脆弱性検査 | ●コンテナイメージ・ハードニング | ●Container Security（Professional以上） | △SBOMで構成を点検 | ●Container Security（CLI） |
| ソースコード診断（SAST） | ● | ● | × | ● |
| クラウド設定診断（CSPM） | ● | × | ● | × |
| IaC設定の点検 | ● | ●Enterpriseパッケージ | × | ●Container Securityで対応 |
| 提供形態 | クラウド（SaaS） ※Proで顧客環境スキャン可 | クラウド／オンプレミス | クラウド（SaaS） | クラウド＋CLI ※コンテナ検査はCLI |
| 料金の目安 | 無料プランあり 有償は月額5万円台〜（年間契約） | 要問い合わせ | 脆弱性診断は月額5万円〜 SBOM等は要問い合わせ | 要問い合わせ |
| 無料トライアル | ●無料プランあり | ×デモのみ | ●最短即日 | 要問い合わせ |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
※2026年11月時点の各サービスの公式情報にもとづく整理です。各機能の対応可否や範囲はプラン・パッケージによって異なります。詳細は各社の最新の公式情報・資料でご確認ください。
1. Aikido Security（株式会社AndGo）
コードからクラウドまでの脆弱性診断を1つの画面でまとめて扱えるオールインワン型のSaaSが、Aikido Securityです。開発会社・開発部門向けに、分断されがちなセキュリティ診断を統合して運用できる点を特徴としています。
コンテナイメージの検査にも対応し、ソースコードの静的解析や依存ライブラリの解析（SCA）、クラウド設定の点検（CSPM）、IaC（コードでインフラ構成を管理する手法）の点検などと同じ基盤で扱えます。複数の診断を1つのツールにまとめたい開発チームの候補になります。
2. Checkmarx（Checkmarx Ltd.）
Checkmarxは、アプリケーションセキュリティを幅広くカバーするプラットフォームです。ソースコードの静的解析（SAST）を中核に、依存関係やIaCの点検など、開発ライフサイクル全体にわたる診断機能を1つのプラットフォームで提供します。
サプライチェーンセキュリティの一部としてコンテナのセキュリティにも対応しており、開発段階からコンテナを含めて脆弱性を点検したい組織に向いています。既に静的解析などで同社を利用している場合、コンテナ領域も同じ基盤に寄せやすい点が利点です。
3. Securify（株式会社スリーシェイク）
株式会社スリーシェイクが提供するSecurify（セキュリファイ）は、Webアプリケーションの脆弱性診断を自動化したクラウド型のセキュリティ診断SaaSです。専門知識がなくても扱える操作性を打ち出しています。
SBOM（ソフトウェア部品表）の機能では、コンテナイメージから構成要素を抽出し、既知の脆弱性（CVE）と突き合わせて点検できます。Webアプリ診断を主軸にしつつ、SBOMでコンテナイメージの構成まで押さえられる点が持ち味です。
4. Veracode（Veracode, Inc.）
Veracodeは、静的解析（SAST）や依存関係の解析（SCA）など複数の診断を同一基盤で提供するアプリケーションセキュリティのプラットフォームです。
コンテナ向けには「Veracode Container Security」が用意され、コンテナイメージの脆弱性検出に加え、IaCの設定ミスやシークレットの検出にも対応します。アプリケーションの診断とコンテナの検査を同じ体系で運用できる点が強みです。
まとめ
コンテナセキュリティの基準づくりは、公式のガイドラインであるNIST SP800-190を拠り所にすると、根拠を示しながら進められます。イメージ・レジストリ・オーケストレータ・コンテナ・ホストOSの5領域ごとにリスクと対策を押さえ、CIS Benchmarksで具体的な設定値を点検し、自社の基盤に合わせて責任分界を確認する、という流れが基本の型です。
まずはNIST SP800-190の5領域の対応表を自社の基準のたたき台として写し、環境ごとの責任分界に照らして未対応の項目を洗い出すことから始めるとよいでしょう。自社だけで検査・点検を続けるのが難しい場合は、コンテナやイメージの脆弱性を検査できる診断サービスの活用も選択肢になります。各サービスの資料を取り寄せて、自社の運用に合うものを比較検討してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. NIST SP800-190とは何ですか？
A. NIST SP800-190は、米国国立標準技術研究所（NIST）が2017年に公開した、コンテナ技術固有のセキュリティリスクと対策を体系化した公式ガイドラインです。イメージ・レジストリ・オーケストレータ・コンテナ・ホストOSという5つのコアコンポーネントごとに、リスクと推奨対策を1対1で整理しており、コンテナセキュリティの基準づくりで広く参照されています。
英語の原典に加え、IPA（情報処理推進機構）による日本語訳も無償で公開されています。
Q. コンテナセキュリティの対策は、どの範囲を守ればよいですか？
A. NIST SP800-190では、コンテナ技術をイメージ・レジストリ・オーケストレータ・コンテナ（実行環境）・ホストOSの5つのコアコンポーネントに分け、それぞれのリスクに対策を対応づけています。この5領域を物差しにすると、守るべき範囲を漏れなく洗い出せます。各領域の具体的なリスクと対策は本記事の対応表にまとめているので、自社のコンテナセキュリティ基準表のたたき台として活用してください。
Q. NIST SP800-190とCIS Benchmarksは何が違い、どう使い分けますか？
A. NIST SP800-190が「何を守るべきか」という原則を示すのに対し、CIS Benchmarksは「どう設定すべきか」という具体的な設定値を示す点が違いです。
まずNIST SP800-190で5領域のリスクと対策の全体像を押さえ、次にCIS Benchmarks（Docker／Kubernetesの設定ベンチマーク）で個々の設定値を点検する、という順で併用すると基準づくりがスムーズに進みます。両者は競合する基準ではなく、抽象度の異なる補完関係にあります。
Q. NIST SP800-190は2017年に発行された文書ですが、今でも使えますか？
A. NIST SP800-190の5領域の分類とリスク・対策の考え方はコンテナ技術の基本構造に根ざしているため、現在のKubernetesやサーバーレス型のコンテナ基盤にもそのまま当てはめて読めます。発行からの年数はありますが、環境による違いは「どのリスクを自社が受け持つか」という責任分界に表れるだけで、守るべきリスクの枠組み自体は変わりません。
環境ごとの責任分界をあわせて確認すれば、現行の基準づくりの土台として問題なく使えます。
Q. コンテナセキュリティは、どのリスクから優先して対応すべきですか？
A. 被害が多数のコンテナに複製されやすいイメージの検査と、影響範囲の広いアクセス制御・ネットワーク分離から着手するのが取り組みやすい順序です。NIST SP800-190の5領域すべてを一度に整えるのは現実的でないため、ビルド段階のイメージスキャン、オーケストレータの最小権限とネットワーク分離を先に固め、その後に実行時の監視へ広げていくとよいでしょう。
自社の環境でリスクが大きい領域から優先順位をつけるのが基本です。
Q. コンテナの脆弱性スキャンは、従来の脆弱性診断と何が違いますか？
A. コンテナには、イメージ内部の脆弱性を検知できるコンテナ専用の脆弱性管理ツールとプロセスが必要です。NIST SP800-190は、従来の脆弱性管理ツールはホストの耐久性やアプリの更新方法について前提を置いており、その前提がコンテナ化されたモデルとはずれているため、コンテナ内の脆弱性を見落として「誤った安心感」をもたらすことが多いと指摘しています。
従来型の診断をそのまま流用するのではなく、ビルド段階でイメージを検査する運用が求められます。
Q. AWS FargateやマネージドなKubernetesを使う場合、コンテナのセキュリティはどこまで自社の責任ですか？
A. ホストOSのパッチ適用やノード管理はクラウド事業者側に移りますが、イメージの脆弱性管理・アクセス制御・アプリの脆弱性といった領域は、マネージドな基盤を使っても引き続き自社の責任です。
たとえばAWS Fargateでは、NIST SP800-190でいうホストOS（3.5／4.5）の受け持ちがAWS側に移りますが、AWSは「EKSの利用が責任共有モデル上の責任を変えるものではない」と明記しています。自社が使う基盤に照らして、5領域を「事業者が守る／自社が守る」に振り分けておくことが大切です。
Q. コンテナセキュリティの「シフトレフト」とは何ですか？
A. シフトレフトとは、脆弱性や設定ミスへの対処を、運用後ではなく開発・ビルドの早い段階（工程の「左側」）で行う考え方です。コンテナセキュリティでは、CI/CDパイプラインにイメージスキャンや設定点検を組み込み、問題のあるイメージをリリース前に止めることを指します。実行時の対策と組み合わせることで、問題が本番環境に流れ込む前に食い止められます。
Q. コンテナのアクセス制御で使われるRBACとは何ですか？
A. RBAC（ロールベースアクセス制御）とは、ユーザーの職務や役割に応じて権限を割り当て、各自が業務に必要な範囲のリソースだけにアクセスできるようにする仕組みです。Kubernetesなどのオーケストレータでは、管理者権限を広く付与しすぎることが重大なリスクになるため、RBACで役割ごとに権限を絞る最小権限の運用が、NIST SP800-190でも推奨されています。
Q. Kubernetesセキュリティの「4C」とは何ですか？
A. 4Cとは、Kubernetes環境を保護する際の4つの階層——クラウド（Cloud）・クラスタ（Cluster）・コンテナ（Container）・コード（Code）——を指す考え方です。外側のクラウドから内側のコードまで各層を順に守ることで、コンテナ環境全体を多層的に保護するアプローチです。NIST SP800-190の5領域とあわせて、守る対象を層で捉えるための補助線として役立ちます。
Q. NIST SP800-190に準拠できているかは、どうやって確認・維持すればよいですか？
A. 5領域ごとの対策を点検項目に落とし込んだチェックリストで定期的に見直し、設定値はCIS Benchmarks対応ツールで点検するのが基本です。たとえばkube-benchは、CIS Kubernetes Benchmarkのチェックを実行して、Kubernetesが安全に構成されているかを確認できるツールです。
イメージは日々更新され新たな脆弱性も次々と公表されるため、ビルドのたびのイメージ検査と実行時の継続監視を組み合わせ、点検を自動化して準拠を保ち続けることが重要です。
Q. 自社だけでコンテナやイメージの脆弱性を検査し続けるのが難しい場合はどうすればよいですか？
A. コンテナやイメージの脆弱性を検査できる脆弱性診断サービス・ツールを活用すると、準拠状況の確認を効率よく進められます。イメージの検査や実行時の監視を継続的に自社だけで担うのは負担が大きいため、コンテナイメージの検査に対応する診断SaaSを使って抜け漏れを点検する方法があります。
各サービスで対応領域（コードからクラウドまでの範囲、SBOMへの対応など）が異なるので、自社の運用に合うものを比較検討するとよいでしょう。
コンテナ・Webの脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、コンテナやイメージの脆弱性を検査できる脆弱性診断サービスの最新資料を無料で一括請求できます。診断対象や提供形態を比べて、自社のコンテナ環境に合うサービスを検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
