Tenable One Cloud Exposure 2026 年に完了した変更

変更内容

クラウドサイバーエクスポージャー は、ソフトウェアコンポジション解析 (SCA) 検出エンジンの更新をリリースします。

検出機能が拡張され、オープンソースコンポーネントとサードパーティの依存関係全体で、パッチ未適用の脆弱性やゼロデイ脆弱性をより適切に特定できるようになります。この更新により最も影響を受けるソフトウェアエコシステムは、Java (Maven)、PHP (Composer)、Node.js (npm) です。これらは、新たに報告された検出結果の大部分を占めています。

この検出ロジックは、リリース日に自動的に更新されます。設定の変更は必要ありません。

影響と意義

• 脆弱性の件数の増加。カバレッジが広がる結果として、アプリケーションリポジトリとビルドで検出される脆弱性の総数が増える可能性があります。
• 可視性の向上。盲点が減少するため、セキュリティチームと開発チームは、ソフトウェアサプライチェーン全体でパッチ未適用のリスクをより包括的に把握できるようになります。

変更内容

Tenable は、SIEM 統合を通じて提供されるクラウドとコードの検出結果データについて、プロパティ名と構造を変更します。このフィードを使用して検出、ダッシュボード、またはレポートを作成する場合は、以下の変更内容を確認し、リリース日までにプロパティマッピングを更新してください。

クラウドの検出結果

クラウドの検出結果データから次のプロパティが削除されます。

クラウドの検出結果データの中で、次のプロパティの名前が変更されました。

クラウドの検出結果データの中で、次のプロパティの動作が変更されます。

コードの検出結果

コードの検出結果データから次のプロパティが削除されます。

コードの検出結果データの中で、次のプロパティの名前が変更されました。

コードの検出結果データに 2 つの新しいプロパティが追加されます。

• accountId - IaC リソースが属するアカウント (リポジトリ) の識別子
• accountPath - アカウント階層のアカウント (リポジトリ) のパス

下位互換性 (要対応)

SIEM 統合、保存されたクエリ、またはダッシュボードが、SIEM 統合の検出結果プロパティの変更 (2026 年 8 月 30 日)またはSIEM 統合の検出結果プロパティの変更 (2026 年 8 月 30 日)で説明されている、削除または名前が変更されたプロパティを参照している場合は、2026 年 8 月 16 日までに更新してください。変更前のプロパティ名を参照するクエリとマッピングは、この日付を過ぎると、そのプロパティのデータを返さなくなります。

理由と意義

Tenable は、クラウドとコードの検出結果スキーマを調整して、両方のフィードが共通のコンセプトに同じプロパティ名と構造を使用するように変更しています。1 つの provider プロパティが cloudProvider と platform を置き換え、1 つの statusUpdateTime プロパティがステータスに応じて名前を変更するキーを置き換えます。これにより、SIEM がクラウドデータとコードデータ全体で維持する必要があるマッピングロジックが軽減されます。

jiraIssueLinks と serviceNowIncidentUrls は、同じ Jira リンクと ServiceNow リンクがすでに 1 か所に一覧表示されている ticketLinks と重複しているため削除されます。

comments と vulnerabilities に上限を設定すると、大規模な検出結果で過剰なペイロードが生成されないようになり、SIEM での取り込みコストが削減され、遅延が短縮されます。

変更内容

クラウドサイバーエクスポージャー は Windows の脆弱性検出を合理化し、インストールされたアプリケーションのディレクトリ内にある個々の .exe と .dll のコンポーネントファイルではなく、アプリケーションレベルで検出結果を報告するようになりました。

インストールされているアプリケーション内のコンポーネントファイル (.exe/.dll) に個別にパッチを適用することはできません。そのため、これらの問題を解決するには親アプリケーションを更新する必要があります。以前は、これらのコンポーネントを報告すると、対処の対象とならない冗長な検出結果が作成されていました。

影響と意義

• ノイズの軽減: この修正により、完全な脆弱性カバレッジを維持しながら、重複アラートを排除できます。ダッシュボードと Vulnerability Instances API 全体の脆弱性インスタンス数が減り、[ソフトウェア] ページに表示される重複のサブコンポーネントや内部ライブラリも減ると考えられます。
• 履歴データの処理: 以前に報告されていたコンポーネントレベルの検出結果は自然になくなり、誤って解決済みと表示されることなく、レポートの精度が確保されます。
• 未登録ファイルに変更なし: 登録済みのインストールに関連付けられていないスタンドアロンの実行可能ファイルと DLL は、これまでどおり引き続き報告されます。

変更内容

Tenable は、インフラのコード化 (IaC) ポリシーのサブセットが特定の IaC リソースの評価を停止する原因となっていた問題を解決します。この問題がある間、これらのポリシーは新しい検出結果をオープンしたり、既存の検出結果をクローズしたりしません。

この修正は、クラウドサイバーエクスポージャー によって自動的に適用されます。ポリシー、除外、ワークフローの設定変更は必要ありません。

影響と意義

• 正確な検出結果: 影響を受けるポリシーの IaC 検出結果に、IaC リソースの現在の状態が反映されるようになりました。

変更内容

Tenable は、クラウドサイバーエクスポージャー [概要] ダッシュボードの次の 4 つのトレンドウィジェットを、Explorer で使用されるのと同じアプローチであるクエリベースのモデルに移行しています。

• 検出結果の深刻度別
• 検出結果のトレンド
• 検出結果の MTTR
• 解決済みの検出結果

これらのウィジェットのいずれかを含むカスタムダッシュボードも、同じ方法で移行されます。

この更新により 2 つの点が変更されます。

• ウィジェットは、ビルトインまたはカスタムクエリで実行されます。すべてのアカウントに、[概要] ダッシュボードの基盤となる、ビルトインの [すべての検出結果] でのモニタリング対象クエリが提供されます。これらのウィジェットの 1 つにフィルターを保存してカスタムダッシュボードを作成した場合、その設定は {Finding type} | {Categories (up to 3)} | {Policy count ("X policies")} という名前の独自のカスタムクエリに自動的に移行されるため、フィルタリングされたビューは以前とまったく同じように動作し続けます。
• カテゴリとポリシーのリアルタイムのフィルターはクエリに組み込まれます。 現在は、ウィジェットを表示しながらカテゴリフィルターとポリシーフィルターをリアルタイムで切り替えることができます。しかしこの変更後、これら 2 つのフィルターはリアルタイムのトグルとして使用できなくなります。他のすべてのリアルタイムのフィルターは影響を受けません。カテゴリまたはポリシーでフィルタリングするには、編集時に、その条件をウィジェットの基礎となるクエリに追加します。

影響と意義

これらのウィジェットをクエリベースのモデルに移行すると、Explorer と適合し、トレンドウィジェットのロジックが Explorer と同じように機能します。お客様による対応は必要ありません。既存のカスタムダッシュボードと保存済みフィルターは、カスタムメトリクスとして自動的に引き継がれ、これらの新しいカスタムクエリが [すべてのクエリ] に一覧表示されます。

新しい設定について

• [概要] ダッシュボードにはこれまでと同じ 4 つのウィジェットが表示されますが、これらは今後ビルトインの [すべての検出結果] メトリクスでサポートされます。
• これらのウィジェットを使用するカスタムダッシュボードは、既存のフィルタリングされたビューを維持しますが、自動作成されたカスタムメトリクスによってサポートされるようになりました。
• 現在カテゴリまたはポリシーでフィルタリングしている場合、変更後はリアルタイムのトグルオプションとして表示されなくなります。トグルではなく、クエリにそのフィルターを設定するように、ウィジェットを編集することになります。

変更内容

Tenable は、脆弱性の可視性をより正確で予測しやすいものにするために、コンテナイメージを クラウドサイバーエクスポージャー のクラウドアカウントに割り当てる方法を変更しています。範囲フィルターを使用すると、各アカウントに、所有するイメージだけでなく、実際に実行するコンテナイメージが表示されるようになりました。アカウントフィルターを使用して、脆弱性テーブル内のコンテナイメージの所有権をフィルタリングできます。

この更新により 2 つの点が変更されます。

• パブリックイメージと未同期イメージに対する新しいコンテナレジストリの範囲
  • クラウドサイバーエクスポージャー と同期されていないレジストリからプルされたコンテナイメージ (docker.io、quay.io、パブリック GHCR などからのイメージ) は、コンテナレジストリという名前の 1 つのアカウント所有者の下に統合されるようになりました。これは、新たな包括的範囲として、アカウントフィルターと範囲フィルターで選択できます。
  • 以前は、同じパブリックイメージがそれをプルした各クラウドアカウントに別のエンティティとして表示されたり、ダイジェストのローテーションに伴い、スキャン間にアカウントの所有権が切り替わったりすることがありました。どちらの動作も不正確で、混乱を招くものでした。
• 共有イメージを実行するすべてのアカウントでの共有イメージの可視化
  • 組織に同じコンテナイメージをプルするクラウドアカウントが複数ある場合、各アカウントで独自のインベントリビューと脆弱性ビューにそのイメージが表示されるようになりました。たとえば、本番環境と非本番環境の両方の AWS アカウントが docker.io/library/nginx をプルする Pod を実行している場合、以前は最初にイメージをスキャンしたアカウントのみにそのイメージが表示されていました。
  • 現在は両方のアカウントで、それぞれのアカウントのワークロードに関連付けられた脆弱性、パッケージ、リスクとともに、固有の範囲内のイメージが表示されるようになりました。

影響の概要

これらの変更は、ダッシュボード、検出結果ページ、スケジュールされたレポートに影響します。必要な対応はありません。変更は自動的に適用されます。

• コンテナイメージをアカウントごとにグループ化した既存のフィルターとダッシュボードでは、同期されていないイメージの新しいコンテナレジストリアカウントが表示されます。
• 特定のクラウドアカウントのコンテナイメージエンティティ数が減少し、コンテナレジストリの数がそれに応じて増加します。
• パブリックイメージのアカウント所有権が、スキャン後にアカウント間で切り替えられることがなくなりました。
• アカウントダッシュボードに表示される脆弱性の件数は、場合によっては大幅に増加する可能性があります。しかし、これらのカウントは、新しい脆弱性を示すものではありません。これらは、前から存在していたものの、以前は使用アカウントに表示されなかったエクスポージャーが反映された数字です。
• 脆弱性、ソフトウェア、悪意のあるファイルの各ページには、共有イメージを使用する各アカウントのエントリが表示されます。
• スケジュールされたレポートは、事前定義された範囲にエクスポートされるため、影響を受けます。選択した範囲内で使用されたコンテナイメージ (他のアカウントが所有しているが、その範囲内で使用されたイメージを含む) の脆弱性がレポートに含まれるようになりました。

変更内容

Tenable は、誤検出を減らし、これまで見逃していたシークレットを捕捉するためにシークレット検出ロジックを更新しました。

このロジックは自動的に更新されます。設定を変更する必要はありません。ポリシー管理、除外管理、検出結果のライフサイクルなどの既存のワークフローは変更されずに残ります。

影響と意義

• 解決済みの検出結果。誤検出が減り、検出結果が実際に公開されたシークレットをより確実に示すようになるため、ノイズの調査に費やす時間が短縮されます。
• 検出カバレッジの改善。これまで見逃されていたシークレットが検出されるようになりました。

影響を受けるポリシー

• AWS リソースタグでシークレットが公開されている
• AWS EC2 インスタンスでシークレットが公開されている
• AWS CloudFormation スタックでシークレットが公開されている
• AWS ECS タスク定義でシークレットが公開されている
• AWS Lambda 関数でシークレットが公開されている
• GCP リソースラベルでシークレットが公開されている
• GCP VM インスタンスでシークレットが公開されている
• GCP App Engine サービスでシークレットが公開されている
• GCP Cloud Functions でシークレットが公開されている
• GCP Cloud Run サービスでシークレットが公開されている
• Azure リソースタグでシークレットが公開されている
• Azure ロジックアプリでシークレットが公開されている

変更内容

Tenable は、誤検出を減らし、より忠実度の高い検出を提供するために、クラウドサイバーエクスポージャー における異常なユーザーエージェントクライアントの使用の脅威ルールに関するロジックを更新しました。

• シームレスな統合: 更新されたロジックは、自動的に以前のロジックと置き換わります。この更新を受け取るために手動で設定変更を行う必要はありません。

影響と意義

• 忠実度の高い検出: このルールによって忠実度の高い検出が生成されるようになりました。各結果は信頼性の高い明確な脅威を提示するため、チームはより結果を信頼して対応することができます。
• セキュリティデータの信頼性の向上: 結果の忠実度が高いほど、セキュリティの検出結果は調査と対応に役立つ信頼性の高い基盤をもたらします。

変更内容

Tenable は、誤検出を減らし、より忠実度の高い検出を提供するために、クラウドサイバーエクスポージャー に悪意があると疑われるファイルがないかを検出するロジックを更新しました。

• シームレスな統合: 更新されたロジックが自動的に適用されます。この更新を受け取るために手動で設定変更を行う必要はありません。

影響と意義

• 忠実度の高い検出: 誤検出が少なくなり、悪意があると疑われるファイルの検出結果に真の脅威がより正確に反映されるため、チームは自信を持って対応できます。
• セキュリティデータの信頼性の向上: 結果の忠実度が高いほど、調査と対応の基盤の信頼性も高くなります。

ステータスと移行

• 現在のステータス: Tenable Vulnerability Management 内のベータモードで現在利用可能です。
• 移行計画: 移行期間中は、元の VPR と拡張された VPR (ベータ) が共存します。
• 非推奨予定: 強化された VPR への完全な移行は、2026 年 7 月 1 日に予定されています。

変更内容

Tenable は優先順位付けの精度を向上させるため、特許取得済みの VPR (脆弱性優先度格付け) を大幅に強化しました。

• VPR スコアの強化: 新しい VPR では、現在実際に悪用されている CVE や近い将来悪用されると予測されている CVE を、元のバージョンと比較して 2 倍効率的に特定できます。
• 精度の向上: 強化された VPR は、リスクの絞り込みがさらに正確になり、チームは実際に事業にリスクとなる 1.6% の脆弱性に集中できます (今までの VPR では 3%)。
• 新しい文脈メタデータ: 新しいメタデータは重要な文脈を提供し、脆弱性が標的にされているかどうかを把握するのに役立ちます。この情報は、脆弱性プロファイルの [脅威の要因] 領域に表示されます。

影響と意義

• フォーカスの向上: 即時の対応が必要な、重大な脆弱性のセットに集中することで、リスクを大幅に軽減し、チームの効率を高められます。
• ベータ機能: ベータ期間中は、新しいスコアは表示のみ可能で、元の VPR と並べて表示されます。脆弱性の深刻度の計算、検出結果の作成、設定されたワークフローには反映されません。
• 準備: 併用期間中は、2 つのスコアを比較し、2026 年 7 月 1 日の完全移行前に内部の優先順位付けプロセスを段階的に適合させることができます。

詳細については、こちらのドキュメントを参照してください。

変更内容

Tenable は、仮想マシン用の非ルートボリュームスキャンのグローバルロールアウトを開始しました。

• 自動有効化: ご使用の環境は今後数週間のうちに自動的に更新されます。手動での設定は必要ありません。
• 請求の更新: これらのスキャンは、各クラウドプロバイダーに固有の新しいデータディスクカテゴリで請求されます。

理由と意義

ルートボリュームから非ルートボリュームにスキャンを拡張することは、セキュリティギャップを埋めるための重要なステップです。主な利点は次のとおりです。

• 盲点の排除: 攻撃者は多くの場合、悪意のあるバイナリを隠ぺいしたり、セカンダリボリューム内の旧式のライブラリを悪用したりして、基本的な「OS のみ」のスキャンを回避します。
• アプリケーションスタックの保護: ほとんどの最新のアプリケーションとデータベースは、ルートパーティションのオーバーフローを防ぐために別々のディスクにインストールされています。これらをスキャンすることで、ソフトウェアスタックを完全にモニタリングできます。
• ラテラルムーブメントの防止: 非ルートボリュームの脆弱性を特定することで、攻撃者が足場を築いてネットワークを探索するのを防ぐことができます。
• コンプライアンスの確保: この更新は、アタックサーフェス全体の包括的な評価を必要とする規制フレームワーク (PCI-DSS や SOC2 など) を遵守するのに役立ちます。

FAQ (よくある質問)

この機能のライセンスはどのようになっていますか?

非ルートディスクは、ライセンスページでクラウドプロバイダー (AWS、Azure、GCP、OCI) ごとに新しいデータディスクカテゴリで分類されます。

注意: 最初のロールアウトフェーズでは、スケールセットに接続された Azure 仮想マシンディスクにはスキャン料金が発生しません。

サポートされる最大ディスクサイズとボリューム数を教えてください。
回答

• 現在の最大ディスクサイズ: 個別ディスクあたり 600GB
• 現在サポートされているボリューム数: リソースあたり最大 4 つのディスク (ルートボリュームを含む)

特定の仮想マシンのスキャンステータスを表示するにはどうすればよいですか?
回答

特定の VM に接続されているすべてのディスクのステータスを表示する方法
1. 仮想マシンのプロファイルページに移動します。
2. [概要] タブで、[ディスク/ボリューム] テーブルを表示します。

非ルートスキャンを無効にできますか?

はい。この機能は、[設定] > [セキュリティ] > [ワークロード] > [拡張ディスクスキャン] で管理できます。

注意: この設定はデフォルトで有効です。

スキャンロジックはどのように動作しますか。また、「部分的」とはどのようなステータスのことですか?

このロジックは、データディスクに対して「全か無か」のアプローチを取ります。Tenable は次のいずれかをスキャンします。

• ルートボリュームのみ
• ルートボリュームおよび対象となるすべての非ルートボリューム

Tenable は、非ルートセットの部分スキャンは実行しません。

ルートボリュームがスキャンされ、非ルートボリュームはスキップされる場合、仮想マシンのスキャンステータスは [部分的] と表示されます。

ユースケースの例

• スキャンステータス: 部分的
• 理由: 接続されたディスクのうち、少なくとも 1 つが上限である 600GB を超えているため

変更内容

現在、シークレットカテゴリには 5 つの一般的なデータタイプがマッピングされています。

• 汎用パスワード
• ランタイムシークレット
• 秘密キー
• 機密性の高い URL
• トークン

5 月 10 日から、これらのデータタイプは 280 以上の個別のデータタイプに分割されます。たとえば、トークンのデータタイプは、AWS セッショントークンや Confluent アクセストークンなど、160 以上のデータタイプに分類されます。

意義

• 可視性の向上: 機密データタイプの分類がより正確になり、機密データの格納場所やリスクへの対処方法を正確に特定できるようになります。
• 秘密レベルの正確性の向上: 個別のデータタイプによって、関連付けられている深刻度レベルもタイプ別になり、正確性が高まります。
• 詳細な制御: 除外を適用して、シークレットデータタイプごとにカスタムポリシーを設定できるため、セキュリティポリシーを正確に制御できるようになりました。

影響

• リスクの再計算: 検出結果は、更新後に予定されている次回のスキャン中に再計算されます。
• ワークロードデータスキャン: 新しいデータタイプの一部は、機密レベルが 「制限付き」 より低くなります。このため、次回のスキャン結果の後に、リソースの全体的なリスクが低減する可能性があります。

変更内容

Tenable は、ネットワークベースのパブリックおよび全体のインバウンドインターネットエクスポージャーを識別するポリシーの命名規則を統一しています。

これらのポリシーは次の形式に標準化されます。

• {resource_name} is exposed to the internet

ポリシー名の変更

次の表は、ポリシー名の変更に関する一覧です。

理由と意義

• ポリシーの命名規則を標準化し、ポリシーと検出結果全体で一貫性と正確性を確保します。
• 潜在的なエクスポージャーに焦点を合わせて、リスクの報告方法を合理化します。

下位互換性

この更新はポリシータイトルの表示のみの変更であり、ご使用の環境に対する手動の調整は必要ありません。

• 自動化とクエリ: 既存のすべての自動化と保存されたクエリは、引き続き使用できます。変更は既存のポリシー ID の表示名にのみ適用されるため、ワークフローでは新しい名前が自動的に反映されます。
• GraphQL API: API の使用率に影響はありません。検索クエリは PolicyIds または Types フィルターを利用しますが、どちらもこの更新の影響を受けません。

変更内容

Tenable は、アカウント関連のクエリを単一のエントリポイントに統合し、GraphQL API に対して互換性に影響する変更を行っています。AWS、Azure、GCP に対するプロバイダー固有のレガシークエリは、統合された Accounts クエリに置き換えられています。

非推奨のクエリ

次の上位クエリがスキーマから削除されます。

要対応

上記の表にあるレガシークエリを使用する自動化スクリプト、統合、カスタムレポートは、更新する必要があります。

機能を維持するには、リクエストを Accounts クエリに移行します。詳細な実装手順とクラウド固有の例については、Account API のドキュメントを参照してください。

変更内容

Tenable は、クラウドサイバーエクスポージャー 内のマルウェア検出ロジックを更新し、最新の脅威をより正確かつ包括的にカバーできるようにします。

• 検出ロジックの更新: この機能強化により、Tenable がクラウドワークロード内でマルウェアのシグネチャや動作を識別する方法が改善されます。新しくなったロジックにより、セキュリティデータに最新の脅威環境が確実に反映されます。
• シームレスな統合: 新しい検出エンジンは、従来のロジックを自動的に置き換えます。これらの更新を受け取るために手動で設定変更を行う必要はありません。

影響と意義

• 検出精度の向上: 新しいロジックによりマルウェアの識別が向上し、利用可能な最も洗練された検出方法に基づいてセキュリティ検出結果を取得できるようになります。
• 信頼できる修正データ: マルウェアの識別方法を改良することで、Tenable はより正確な情報を提供し、インシデント対応と修正作業をサポートします。

変更内容

現在はリソースのデータスキャンが無効になっている場合、最新のスキャン結果が クラウドサイバーエクスポージャー コンソールに永久に残ります。これは、古いデータ、誤解を招くデータ、無関係なデータにつながる可能性があります。

4 月 12 日より、Tenable はこの動作を更新し、アクティブなモニタリングのみが反映されるようにします。

新しい動作

• データ保持: リソースのスキャンが無効になると、30 日以上経過した分類結果は、コンソールと API から自動的に消去されます。
• プラットフォームの透明性: 30 日以上経過すると、無効になっているリソースの分類結果は、リソースの [データ] タブ、関連する列、API クエリ経由で入手できなくなります。
• リスクの再計算: 既存の検出結果の深刻度が再計算され、データポリシー (カスタムおよびビルトイン) によってトリガーされた検出結果はクローズされます。
  ## 影響と意義
  この更新により、古いモニタリングされていない結果ではなく、現在の実用的なデータに基づいたセキュリティポスチャーが確保されます。
• リスク評価の改善: リスクレベルとアラートが、データが現在モニタリングされている請求対象のリソースに厳格に関連付けられます。
• コンソールの正確なデータ: 環境がアクティブなスキャン設定と現在のデータプライバシー設定に引き続き重点を置くようにします。

変更内容

クラウドサイバーエクスポージャー は、クラウドリソースのインターネットエクスポージャー分析の決定方法をアップグレードしています。現在、インターネットエクスポージャーは、クラウドリソースの設定の静的な分析によって決定されています。この設定では、インターネットに接続しているように見えるリソースにフラグが立てられます。ネットワークスキャナー (2025 年 12 月導入) では、フラグが立てられたリソースに接続して実際の到達可能性を確認することで、エクスポージャーが動的にバリデーションされます。

この更新では、スキャナーがネットワーク評価の一部になり、インターネット接続によるパブリックエクスポージャーの計算方法が変わります。

主な変更は次のとおりです。

• 直接的なインターネットエクスポージャーの検証: サポートされている直接リソース (EC2、RDS、Redshift など) では、ネットワークスキャナーが到達可能性を正常に検証し、ネットワークエンドポイントを作成する場合にのみ、リソースはパブリック (インターネット接続) として分類されます。
• 検出結果の深刻度: インターネットエクスポージャーの検証が、ネットワーク関連の検出結果の深刻度を決定する要素になりました。設定のみではなく確認済みの到達可能性を使用することで、ノイズを低減させ、検出結果のリスクレベルに実際のエクスポージャーを反映させます。その結果、影響を受ける検出結果の深刻度が増減する可能性がありますが、より正確なリスク評価が提供されます。
• フォールバックロジック: ロードバランサーや API ゲートウェイの背後にあるリソースなど、間接的に公開されるリソースは、スキャナーサポートが追加されるまでの今後数か月間、エクスポージャーに対して静的な設定分析を引き続き使用します。

詳細は、ネットワークのエクスポージャーを参照してください。

検出結果が影響を受けるかどうかを確認する方法

影響を受ける直接リソースを特定するには、検出結果のプロファイル内で [リソース] が X ネットワークエンドポイントを公開しているかどうかを確認します。これは、ネットワークスキャナーが実際の到達可能性を動的に検証していることを示し、検出結果が静的な設定だけでなく実際の接続に基づいていることを確認できます。

理由と意義

これにより、理論上のリスクから検証済みのエクスポージャーに移行します。

• ノイズの排除: セキュリティチームが、実際には外部のファイヤーウォールやプロキシなど、ネットワーク評価に含まれないその他のリソースによって保護されているリソースのインターネット接続の検出結果を追跡する必要がなくなります。
• 実際の脅威を優先: 攻撃者が実際にインターネットから到達できる資産に、深刻度の高いアラートとリスクスコアを付けるようにします。
• 危険な組み合わせ: 重大な脆弱性、過剰な権限を持つアイデンティ、機密データなどの資産が真に公開されているかどうかを確認します。これにより、環境全体の最も危険なリスクを優先することができます。

新しい設定について

検証済みの到達可能性の実装により、検出結果の深刻度が変更される場合があります。サポートされているリソースでは、リスクレベルが、静的な設定分析のみでなく、確認されたスキャナーの結果によって決定されます。

この変更により、セキュリティポスチャーが現実のエクスポージャーを正確に反映できます。ただし、既存の検出結果の深刻度は、検証済みの到達可能性データと合わせて調整される場合があります。

スキャナーが到達可能なリソースを検証し、リスクを正確に反映できるようにするために、ファイヤーウォール/WAF ルールでスキャナーの元の IP アドレスからのトラフィックが許可されていることを確認してください。

影響を受けるポリシー

次の表は、検証済みのインターネットエクスポージャーへの移行によって影響を受ける具体的なポリシーを示しています。

プロバイダー固有のポリシー

ワークロード保護ポリシー

変更内容

2026 年 4 月 5 日付けで、Tenable は IaC セキュリティの検出結果に対する除外アノテーションを非推奨とします。

Tenable は、セキュリティチームがすべての除外された検出結果を完全に可視化できるように、この変更を行います。IaC で除外が定義されている場合は、セキュリティチームの確認なく除外が適用される可能性があります。

影響

現在 IaC 検出結果を管理するために除外アノテーションを使用している場合、検出結果を除外する別の方法に移行する必要があります。2026 年 4 月 5 日以降、Tenable はこれらのアノテーションを認識しなくなります。

変更内容

Tenable は、Amazon Machine Image (AMI) スキャンを無料サービスから請求対象サービスに移行しています。

影響と意義

• Tenable は自動的に AMI のスキャンを続行します。カバレッジを維持するために、お客様が何か対応する必要はありません。
• スキャンされた EC2 イメージは、ライセンスのあるリソース使用量にカウントされます。
• 「ライセンス」 ページで、現在の使用量をいつでもモニタリングできます。
• スキャンの設定を管理するには、[設定] > [クラウドサイバーエクスポージャー] > [ワークロード] > [仮想マシンイメージ] に移動します。

変更内容

2026 年 3 月 3 日に、Tenable は、Inventory API 内のアンマネージド Kubernetes クラスタをクエリするためのメソッドを更新します。これらの特定のクラスタは、クラウドプロバイダーのリソースクエリ経由で利用できなくなります。代わりに、Entities クエリを使用してアクセスする必要があります。

この更新では、フィルターおよびキャストタイプからプロバイダー固有のプレフィックス (Aws など) を削除し、さまざまな環境にまたがるアンマネージド Kubernetes クラスタの操作方法を標準化します。

要対応

リリース日の前に、新しいエンティティの命名規則を反映するように GraphQL API クエリを更新する必要があります。既存の統合またはスクリプトが AwsUnmanagedKubernetesCluster などのプロバイダー固有のタイプに依存している場合、汎用の UnmanagedKubernetesCluster タイプに更新する必要があります。

影響と意義

この変更により、GraphQL スキーマが簡素化され、マルチクラウドまたはハイブリッド環境を管理するお客様の一貫性が向上します。プロバイダー固有のプレフィックスを削除することで、Tenable は、アンマネージド Kubernetes リソースをクエリするための統一された方法を提供し、API 実装の複雑さを軽減します。

変更の詳細

次の表は、アンマネージド Kubernetes クラスタのクエリに必要な特定の構文変更の概要です。

API クエリの比較例

以下の例を使用して、従来の構文とアンマネージドクラスタに必要な新しい構造を比較します。

従来のクエリ (3 月 3 日以降サポート対象外)

query 
{
  Entities(filter:{Types:[AwsUnmanagedKubernetesCluster]})
    {
      nodes
      {
        __typename
        Name
        Id
        Provider
        ... on AwsUnmanagedKubernetesCluster {
            Region
        }
      }
    }
}

新しいクエリ (必須)

このクエリでは、標準化されたエンティティタイプを使用します。特定のプロバイダーを分離するには、フィルターに Providers 引数を追加します。

query
{
  Entities(filter:{Types:[UnmanagedKubernetesCluster], Providers:[AWS]})
    {
      nodes
      {
        __typename
        Name
        Id
        Provider
        ... on UnmanagedKubernetesCluster {
            SyncTime
        }
      }
    }
}

ステータスと移行

• 現在のステータス: すべての AWS クラウドワークロード保護 (CWP) ユーザーが現在利用可能です。
• 移行計画: AWS クラウド統合は、新しいスキャンロジックの反映を開始します。
• 完全な実装: デフォルト設定としての AMI スキャンへの移行は、2026 年 1 月 25 日までに完了する予定です。

変更内容

Tenable は、すべての AWS クラウドワークロード保護 (CWP) ユーザーに対して AMI (Amazon Machine Image) スキャンをデフォルト要件とすることで、クラウドセキュリティカバレッジを標準化しています。これにより、リソースのライフサイクル全体における包括的なセキュリティベースラインが確保されます。

• 一貫性: すべての CWP リソース (仮想マシンなど) はデフォルトですでにスキャンされていますが、仮想マシンイメージが同じ設定を受け取り、包括的なカバレッジを確保するようになりました。
• アクセス許可の処理: 仮想マシンイメージのアクセス許可は、現在の CWP オンボーディング中にデフォルトでリクエストされます。
• ステータスの更新: 従来のお客様またはポリシーが変更されたお客様の場合、この仮想マシンイメージのステータスは [無効] から [サポート対象外] (アクセス許可なしを示す) に変わります。

影響と意義

• セキュリティの価値と比較して無視できるコスト: デフォルトで AMI スキャンを有効にすると、リソースへの影響を最小限に抑えてセキュリティポスチャーを拡大できます。これらのスキャンによりイメージライブラリに対する重要な可視性が得られ、一方で、クラウド環境内で発生するコストは無視できる程度となる見込みです。
• 「シフトレフト」による包括的なセキュリティベースライン: デフォルトの要件として AMI スキャンを扱うことで、Tenable では、新しいインスタンスの起動に使用される前にすべての設定済みのイメージテンプレートで脆弱性が評価されるようになります。これにより、セキュリティ上の欠陥が環境全体に広がるのを防ぎます。

準備

• アクセス許可の確認: AWS IAM ポリシーに、AMI のスキャンに必要なアクセス許可が含まれていることを確認し、「サポート対象外」ステータスを回避します。
• 移行の検証: 1 月 25 日の期限よりも前に新しいロジックに移行するように、AWS 統合をモニタリングします。