dt-sec-insights

Security Insights スキル

DQL を使用して、security.events 内の Dynatrace セキュリティデータをクエリし、分析します。イベントは、Dynatrace ネイティブのソース（RVA、RAP、Automated Detections、SPM）、または連携を介して取り込まれた外部製品（AWS Security Hub、Amazon GuardDuty、GitHub Advanced Security、Snyk、Qualys、Tenable など）から取得されます。

このスキルで扱う内容

• 脆弱性管理 — DT ネイティブの RVA による、実行中のコードに存在する未解決の CVE（Dynatrace Security Score と、4 つの観点によるランタイム評価（脆弱な関数の使用状況、パブリックネットワークへの露出、到達可能なデータ資産、公開済みエクスプロイトの有無）に基づくリスク順位付け）、および外部の SCA／SAST／イメージスキャナー。
• コンプライアンス態勢 — DT ネイティブの KSPM（Kubernetes のみ：CIS、DORA、NIST、STIG）、および CSPM／VSPM と外部のコンプライアンス／態勢プロバイダー。
• ランタイム攻撃と脅威 — DT ネイティブの検出（RAP ランタイム攻撃、Automated Detections ルール）、および外部の検出プロバイダー。
• 脅威インテリジェンス — 外部の脅威インテリジェンスレポート（AlienVault OTX パルス、CrowdStrike Falcon Intelligence）。攻撃者／キャンペーン／標的に関するコンテキストと侵害指標（IOC）を含みます。報告された IOC／CVE／手法を、監視対象の環境と照合します。これらは広く流通する脅威インテリジェンスであり、お客様のエンティティに関する検出結果ではありません。個別にクエリします。
• スキャン範囲の分析 — Dynatrace のスキャン機能（Library Vulnerability Analytics、Operating System Vulnerability Analytics、Code-level Vulnerability Analytics）または外部製品ごとに、対象となっている Kubernetes ワークロード／ホスト／プロセスと、対象外のものを分析します。
• エンティティのエンリッチメント — Smartscape を介して、外部の検出結果を Dynatrace のランタイムエンティティ（ホスト、Kubernetes ワークロード、クラウドリソース）にマッピングします。
• ダッシュボード／KPI — タイル、上位 N 件のテーブル、推移グラフ、カバレッジのドーナツグラフ。

このスキルを使用するタイミング

✅ 最初に行うルーティングルール： DQL を生成する前に、まずユーザーの意図を特定し、クイックスタート：ユースケースを見つけるから該当する主要リファレンスを読み込みます。

意図を特定してから、DQL を記述する前に該当するリファレンスを読み込みます。

横断的なユースケース（すべて／任意の検出結果タイプ）

意図／例	リファレンス	パターン
すべての製品（DT ネイティブを含む）にわたるセキュリティ態勢／概要	all-security-events.md § 広範な質問のクエリ分解	3 ストリームに分解（外部＋検出 24h／RVA 30m／KSPM 1h）してマージします。件数の概要は KSPM コンプライアンス（まず CIS）から始めます（他の標準＋RVA＋検出結果はその下に記載）→ compliance.md § CIS 優先の標準概要
特定のエンティティに関する検出結果 — 直接または関連（影響範囲）	dt-sec-contextualization entity-enrichment.md · all-security-events.md	エンティティに関する広範なセキュリティの質問は、分解が必要です： dt.smartscape_source.id／dt.entity.*／k8s.* による外部の *_FINDING（24h）＋DT RVA のエンティティ範囲（30m）＋DT SPM のエンティティ範囲（1h）
特定のプロバイダーからの検出結果	all-security-events.md § 特定のプロバイダーに絞り込む	contains(lower(event.provider | product.vendor), "<p>")
データを送信しているサードパーティ／外部ツールはどれか（DT ネイティブを除く）	all-security-events.md § 有効な外部連携	外部のみを列挙（単一クエリ）
どのセキュリティ製品が連携されているか／どのようなセキュリティデータがあるか（デフォルト：DT ネイティブの RVA＋KSPM を含む）	all-security-events.md § 広範な質問のクエリ分解	3 ストリームに分解します。security.events を単一の広範なクエリでスキャンすることは避けてください
特定のエンティティを対象としている製品	dt-sec-contextualization correlation-and-coverage.md · all-security-events.md	product.* で要約します。検出結果とスキャンを分けます

ルーティングの優先順位： 修飾のない「どのセキュリティ製品が統合されていますか？／対策はできていますか？／何を利用していますか？」という質問では、デフォルトでDTを含む3ストリーム分解を使用します（DTの脆弱性とコンプライアンスを必ず照会してください）。外部のみを対象とする単一クエリを使うのは、「どの外部ツールがデータを送信していますか？」のように、ユーザーが外部／サードパーティのツールに明示的に範囲を限定している場合に限ります。

脆弱性（CVE 管理）

意図／例	リファレンス	パターン
件数／重大度（リスクとミュート状態別）	vulnerabilities-dynatrace.md	RVA スナップショットのステップ 1～3
最も脆弱なコンポーネント／ホスト／ワークロード（ランキング）	vulnerabilities-entities.md	ステップ 1～3 ＋ expand で型付き related_entities.<group>.ids を展開 → id_classic を使って smartscapeNodes を検索 — ⚠ RVA イベントでは k8s.*／dt.entity.* は null です
CVE／ライブラリの検索、「log4shell に対して脆弱ですか？」	vulnerabilities-dynatrace.md § エンティティのスコープ設定	ステップ 2 の CVE／コンポーネントフィルター。RVA のスコープを既知のエンティティに限定
影響範囲 — CVE X の影響を受けるエンティティ	vulnerabilities-entities.md	related_entities.* の間接リレーションを展開
ライフサイクル — 新規／解決済み／未解決期間／MTTR	vulnerabilities-dynatrace.md	導出後の resolution.change_date。MTTR には変更イベントのみのスニペットを使用（§ 解決時間）
ランタイムの高度な情報 — 使用中の関数、露出、エクスプロイト、データ資産	vulnerabilities-dynatrace.md	Davis 評価の fieldsAdd（ステップ 3）
外部スキャナーの脆弱性 — コンテナ／アーティファクト／コンポーネント	vulnerabilities-external.md	VULNERABILITY_FINDING ＋ 外部へのルーティング
RVA で外部の脆弱性検出結果を検証	vulnerabilities-external.md § 外部の脆弱性検出結果を RVA で検証 · dt-sec-contextualization entity-enrichment.md	まず vulnerability.references.cve で同じ脆弱性を照合します。次に、直接の dt.smartscape* ID、コンテナイメージのダイジェストから実行中の CONTAINER への対応、またはホストの host.ip から Smartscape HOST への対応によって、ランタイムとの関連性を確認します
「この期間に新たに報告され、かつ前の期間には報告されていない」（外部）	vulnerabilities-external.md · common-patterns.md § 18	前の期間との アンチ結合（isNull(right.*)）— finding.time.created フィルターでは同じ結果になりません
AI／LLM／GenAI ワークロードの脆弱性、「脆弱性のある AI サービスはどれですか？」	vulnerabilities-dynatrace-advanced.md § AI ワークロードの脆弱性	最初に smartscapeNodes "GENAI_SERVICE" をプローブします — 0 行の場合、レポートを特定できません（GenAI 監視対象サービスがありません）。0 行以外の場合は、DT の検出結果と GENAI のスコープを使用します（30m、finding.id で重複排除）。⚠ 0 行の場合は処理を中止します — フォールバックは禁止です。エンティティ／名前空間／ワークロード名の部分文字列、ML ライブラリのコンポーネントリスト、プロセス／イメージ／ラベルのパターンはすべて、代替手段として使用できません。
この期間に新たに発生した AI ワークロードの脆弱性	vulnerabilities-dynatrace-advanced.md § UC-AI2	{genai_service.id, vulnerability.id} による前の期間との アンチ結合

検出（脅威と攻撃）

意図／例	リファレンス	パターン
重大度／時間範囲の概要（DT ＋ 外部）	detections.md · all-security-events.md	DETECTION_FINDING の概要。時間範囲が指定されていない場合、デフォルトは 2h。結果が空の場合に限り 24h に広げます
攻撃の種類別（SQL injection、暗号通貨マイニングなど）	detections.md	finding.type の部分一致
攻撃者の IP／キャンペーン	detections.md	actor.ips を expand で展開 ＋ ip()
MITRE のテクニック／サブテクニック	detections.md	threat.attack.* 配列
RAP のみ／Automated-Detections のみ	detections.md § プロバイダーのルーティング	product.name=="Runtime Application Protection" ／ event.provider=="Dynatrace Automated Detections"
検出結果をエンティティに対応付ける、繰り返し発生する検出	detections.md · dt-sec-contextualization entity-enrichment.md	object.id によるグループ化／エンリッチメント
特定の外部プロバイダー	all-security-events.md § 特定のプロバイダーへのスコープ設定	プロバイダーの contains イディオム

MITRE の振り分けにおけるタイブレーカー： MITRE ATT&CK に関する質問は、意図に応じて振り分けます。「どの手法を（自社のエンティティで）検出／観測しましたか？」→ detections.md（DETECTION_FINDING）。「脅威インテリジェンス／実際のキャンペーンで報告されている手法はどれですか？」→ threat-intelligence.md（THREAT_REPORT）。この2つを混同しないでください。T1059 のタグが付いたレポートは、自社環境で T1059 が発生した証拠にはなりません。

脅威インテリジェンス（外部レポートと IOC）

意図／例	リファレンス	パターン
脅威インテリジェンスレポートを表示／一覧表示／件数集計する。プロバイダー、アクター、マルウェアファミリー、標的となった国／業界、TLP、レポート種別ごとのレポート	threat-intelligence.md	THREAT_REPORT + dedup {threat.report.id}（最初に SD ガードを適用）。4キーの summarize は使用しない
レポート全体にわたる上位 IOC（CVE／IP／ドメイン／URL／メール／ハッシュ）または MITRE 手法	threat-intelligence.md § IOC 抽出	dedup → 観測可能項目を expand → countDistinctExact(threat.report.id)
レポート X の脅威にさらされていますか／これらの IOC は自社環境にありますか？（脅威エクスポージャー）	threat-intelligence.md § 脅威エクスポージャーの相関分析	レポートの IOC／CVE／手法を VULNERABILITY_FINDING／RVA／DETECTION_FINDING に join。ログ／スパンの IoC ハンティング → dt-sec-ioc-hunting

コンプライアンス（ポリシー違反とベンチマーク）

意図／例	リファレンス	パターン
合格率／セキュリティ態勢（CIS／DORA／NIST／STIG）	compliance.md	最初に compliance.md を読み込みます — SPM のステップ 1～2 + passRate
重大な設定ミス	compliance.md	最初に compliance.md を読み込みます — ステップ 1～2 + 重大度フィルター
特定のエンティティに関するコンプライアンス／設定ミス	compliance.md § エンティティの Security タブ表示（エンティティスコープの ${entityIdsOrNames} フィルター） · entity-enrichment.md	エンティティの Security タブを再現します（デフォルトは CIS、失敗のみ）：表 1 DT CIS の失敗ルール → 表 2 その他の DT 標準（重複に関する注意事項） → 表 3 外部の設定ミス。広範なセキュリティ態勢／件数に関する質問には、§ CIS 主要標準の概要（スコアカード）を使用します。
コントロール／標準からエンティティへのマッピング。名前空間ごと	compliance.md	compliance.standard.short_name／compliance.rule.id によるエンティティのスコープ指定（⚠ metadata_json は使用しない）
クラウド／非 K8s（PCI／ISO／HIPAA／GDPR、AWS／Azure／GCP）	compliance.md § 外部	外部分類（compliance.standards／policy／control）
標準／フレームワーク別にグループ化した外部違反	compliance.md § 外部	compliance.standards は配列です — summarize の前に expand します
設定のドリフト／前週と比べて新たに失敗したルール（DT）	compliance.md § 週次の設定ドリフト	前期間とのアンチ結合 — 広い取得期間は代替になりません
今期に新たに発生し、前期間には存在しなかった外部コンプライアンスの検出結果	compliance.md § 外部	前期間とのアンチ結合（ドリフトと同じルール）
KSPM（Kubernetes のみ、DT ネイティブ）	compliance.md	product.name=="Security Posture Management"

カバレッジ、エンリッチメント、ダッシュボード

意図／例	参照先	パターン
カバレッジ／「カバー済みか未カバーか」／カバレッジの不足 — ホスト／プロセス／ワークロード	coverage-and-dashboards.md（カウントロジック） · dt-sec-contextualization correlation-and-coverage.md（照合レシピ）	⚠ 必ず smartscapeNodes ＋ lookup スキャンイベントから開始してください — スキャンイベントだけを要約しても分母がなく、カバレッジに関する質問には答えられません
DT の機能（RVA、SPM、RAP、その他の DT ネイティブ機能）ごとの特定エンティティのカバレッジ	coverage-and-dashboards.md	その機能の運用期間内に、そのエンティティに関する該当する検出結果またはスキャン／完了イベントがない場合は、未カバーと回答してください — そのエンティティでは機能が有効化または設定されていない可能性があります
外部の検出結果をワークロード／ホスト／クラウドにマッピング	dt-sec-contextualization entity-enrichment.md	3 方向照合（K8s）／IP によるホスト照合／Path-1（クラウド） — ⚠ 必ず Smartscape に結合してください。生の object.name／k8s.namespace.name／host.name／クラウドリソース ID だけで検出結果をグループ化しないでください
エンティティごとに 1 行のリスク概要	dt-sec-contextualization entity-enrichment.md · coverage-and-dashboards.md	RVA ＋ 外部データのマージ
ダッシュボード — KPI タイル、上位 N 件、傾向、ドーナツチャート	coverage-and-dashboards.md	makeTimeseries、要約レシピ

❌ 次の用途には使用しないでください：

• Dynatrace が検出した問題 → dt-obs-problems
• アプリケーション／インフラストラクチャのログ → dt-obs-logs
• 分散トレーシング → dt-obs-tracing
• サービスパフォーマンス／RED メトリクス → dt-obs-services

AppSec データの概要

すべてのセキュリティイベントは security.events に保存され、event.type によって分類されます。

• RVA の脆弱性 — VULNERABILITY_STATE_REPORT_EVENT（エンティティごとの 15 分間隔のスナップショット）
• KSPM コンプライアンス — COMPLIANCE_FINDING（(rule, K8s object) ごとに記録され、最新スキャンの重複排除のため scan.id で COMPLIANCE_SCAN_COMPLETED と結合）
• 外部コンプライアンス（CSPM／VSPM／外部ポスチャツール） — 外部タクソノミー（compliance.standards／compliance.policy／compliance.control）を持つ COMPLIANCE_FINDING。通常、compliance.rule.* は null です
• 検出 — DETECTION_FINDING（product.name == "Runtime Application Protection" による RAP）、SECURITY_EVENT（一部のテナントの RAP イベント）、event.provider == "Dynatrace Automated Detections" による Automated Detections、外部セキュリティツール。さらに、ルール実行ごとの監査用に DETECTION_EXECUTION_SUMMARY（Automated Detections のみ）
• スキャンカバレッジ — VULNERABILITY_SCAN、COMPLIANCE_SCAN
• 脅威インテリジェンス — THREAT_REPORT（外部 TI プラットフォーム：AlienVault OTX pulses、CrowdStrike Falcon Intelligence）。検出結果とは別種のデータです： finding.*／object.*／dt.security.risk.level はなく、影響を受けるエンティティもスキャンサイクルもありません。プロバイダー横断の検出結果概要やポスチャ概要の内訳には決して含めず、threat-intelligence.md を使って個別にクエリしてください。 threat.report.id で重複排除します。

タクソノミーとフィールドの完全なリファレンス → data-model.md

重要な制約：スナップショットの時間範囲

DT RVA と KSPM は、イベントストリームではなくスナップショットツールです。各パイプラインで必要な最小クエリ時間範囲は次のとおりです。

• RVA：固定の 30m（最新の15分サイクルを取得します）。30分のスナップショットが空、または明らかに古い場合は、vulnerabilities-dynatrace.md に記載されている、制御された24時間の最新既知状態へのフォールバックを使用します。
• KSPM：固定の 1h（内部結合に最新の COMPLIANCE_SCAN_COMPLETED マーカーが必要です）。
• 外部の検出結果（CSPM/VSPM を含む）：2h–24h+（スナップショットのセマンティクスはなく、単発のイベントです）。

これらの時間範囲を広げても、より過去まで遡ることにはなりません。取得できるのは、最新のレポート／スキャンサイクルのみです。履歴の傾向を確認するには、より長い時間範囲で makeTimeseries を使用してください。

DT が生成する VULNERABILITY_FINDING と RVA の状態レポートの違い。 Dynatrace が生成する VULNERABILITY_FINDING クエリ（vulnerabilities-dynatrace-advanced.md § AI-workload vulnerabilities にある AI ワークロードのスコープ指定など）も 30m の時間範囲を使用しますが、DT の検出結果はスキャン実行のたび（約15分ごと）に再出力されるため、重複排除には finding.id を使用します。これは、{vulnerability.display_id, affected_entity.id} で重複排除する RVA の状態レポートの 30m 時間範囲とは異なります。この2種類の重複排除粒度を混在させないでください。

Dynatrace アプリのデフォルト時間範囲

UI アプリには、時間ピッカーであらかじめ設定されたデフォルト値が表示されます。ユーザーが明示的な時間範囲を指定せずに「アプリの表示」を参照する場合は、クエリ結果が UI の表示と一致するよう、次の値を使用してください。

アプリ	デフォルトの時間ピッカー
Vulnerabilities app	30分
Threats & Exploits app	2時間
Security Posture Management app	2時間

これらのアプリのデフォルト値は、上記のスナップショットに必要な最小時間範囲よりも広くなっています（例：SPM アプリは2時間、KSPM パイプラインの最小時間範囲は1時間）。最小時間範囲は、内部結合／最新サイクルの重複排除を機能させるために必要な値です。一方、アプリのデフォルト値は、ユーザーが最初にアプリを開いたときに表示される値です。正規のパイプライン DQL を生成するときは最小時間範囲を使用してください。「SPM アプリには今何が表示されていますか？」とユーザーが尋ねた場合や、アプリの表示に合わせたダッシュボードタイルを作成する場合は、アプリのデフォルト値を使用してください。

詳しくは、vulnerabilities-dynatrace.md § Snapshot vs. History を参照してください。

このスキルの構成

このスキルは拡張性を確保するため、次の2つの部分に分かれています。

1. SKILL.md（このファイル） — エントリーポイント、クイックリファレンス、適切なリファレンスへの案内
2. references/ — 機能またはドメイン別の詳細なガイダンス：
   • data-model.md — fetch security.events のリファレンス — イベントの種類、プロバイダー、フィールド、エンティティのスコープ設定。
   • common-patterns.md — 複数の領域に共通するパターン、避けるべきよくある間違い、クエリのトラブルシューティングに関するリファレンス。

• vulnerabilities-dynatrace.md — Dynatrace Runtime Vulnerability Analytics（RVA）：スナップショットパイプライン、件数、ライフサイクル、ランタイム評価、CLV、追跡、ミュート、エンティティのスコープ設定。
• vulnerabilities-dynatrace-advanced.md — DT の脆弱性に関する高度なガイダンス：ベストプラクティスと AI ワークロード（VULNERABILITY_FINDING）のクエリワークフロー。
• vulnerabilities-external.md — 外部 SCA / SAST / イメージスキャナーによる脆弱性検出結果（VULNERABILITY_FINDING）。
• vulnerabilities-entities.md — DT RVA のエンティティランキング：「最も脆弱なホスト / K8s ワークロード / コンポーネント」＋ CVE の影響範囲。
• compliance.md — Dynatrace Security Posture Management（SPM / XSPM）のコンプライアンス検出結果と、外部プロバイダーのコンプライアンス検出結果。
• detections.md — Runtime Application Protection（RAP）の検出、Automated Detection ルール、外部プロバイダーによる検出。
• threat-intelligence.md — 外部の脅威インテリジェンスレポート（THREAT_REPORT）：AlienVault OTX / CrowdStrike Falcon Intelligence、IOC 抽出、脅威への露出の相関分析。検出結果ではありません — 別途クエリします。
• all-security-events.md — プロバイダー横断クエリ、二重カウント防止、統合サマリー
• coverage-and-dashboards.md — エンティティのカバレッジ計算ロジック（smartscapeNodes の分母、カバレッジ対象と対象外）およびダッシュボードのパターン（KPI タイル、上位 N 件、トレンドチャート、カバレッジドーナツ）。
• entity-enrichment — dt-sec-contextualization の references/entity-enrichment.md に移動しました（3方向の照合 / IP によるホスト特定 / クラウド）。エンティティのマッピングに関する質問には、dt-sec-contextualization を読み込んでください。

共通のベストプラクティス

1. 必ず最初に dt-dql-essentials を読み込んでください — DQL の構文と関数名は SQL とは異なります。クエリを生成する前に、すべての関数を dt-dql-essentials で確認してください。
2. すべてのクエリは、振り分け先リファレンスの標準テンプレートに基づいて作成してください。DQL を独自に考案しないでください。 意図を特定し、該当するリファレンス（使用する場合を参照）を読み込み、その標準パイプラインまたは名前付きの構成要素を基に作成します。SQL の慣習からフィールド名、列挙値、結合構文、パイプラインの構成を決して推測しないでください。テンプレートから逸脱できるのは、スキルの例に構文が明示されている場合、または dt-dql-essentials で検証済みの場合のみです。依頼に適合するテンプレートがない場合は、その旨を伝えて最も近いものを応用してください。フィールドや値を決して捏造しないでください。
3. dt.system.bucket フィルターは使用しないでください — セキュリティイベントデータはどのバケットにも存在する可能性があります。バケットで絞り込むと、検出結果が見えなくなるおそれがあります。
4. データの種類に応じて正しい出所フィールドを使用してください — RVA では event.provider == "Dynatrace"、SPM / 検出では product.vendor == "Dynatrace" を使用します。data-model.md § Provider Taxonomy を参照してください。
5. 必ず明示的な from: 句を含め、クエリの種類に適した期間を使用してください：

   クエリの種類	デフォルトの期間	備考
   DT RVA スナップショット	30m 固定	最新の15分間の状態レポートサイクルを取得します。期間を広げないでください
   DT KSPM スナップショット	1h 固定	スキャン完了サイクルの内部結合に合わせています。期間を広げないでください

| RAP／外部検出の取得または現在の概要 | 最初の試行は 2h | Threats & Exploits アプリのデフォルトに一致します。行が0件の場合、またはユーザーが明示的により長い期間を求めた場合にのみ 24h に広げます（detections.md § 空の場合に期間を広げるフォールバックを参照） | | プロバイダー横断の概要（集計） | 24h | 概要は時間をまたいで集計されるため、広い期間から始めます |

from: を省略すると、スナップショットの意味に合わないデフォルトの期間が適用され、クエリの実行ごとに結果にずれが生じます。30m／1h の期間は 任意に設定したものではありません。基盤となる RVA／SPM のスキャン頻度に合わせています。期間の完全な一覧は common-patterns.md § 7 を参照してください。 DT を含む広範な質問／ポスチャー概要の質問は分解してください（「Dynatrace ネイティブを含め、どのセキュリティ製品が統合されているか」、ポスチャーの概要、DT の脆弱性／コンプライアンスを含むカテゴリー横断の件数など）――security.events 全体を対象とする広範なスキャンを 1 回だけ実行して回答してはいけません。クエリを 3 つ実行して結果を統合してください。Stream A は外部検知＋DT 検知（24h、二重カウント防止）、Stream B は DT RVA（30m）、Stream C は DT KSPM（1h）です。これにより、高カーディナリティのスナップショットストリームを狭い時間枠に保ち、二重カウントを回避できます。「データを送信している外部統合はどれか」という、より限定的な質問には、外部のみを対象とする単一のクエリを使用します。all-security-events.md § 広範な質問に対するクエリの分解を参照してください。 6. 未加工の一覧表示ではエンティティ識別子を保持してください（top／latest／list／show-me――summarize は使用しません）。これにより、各検出結果がどのエンティティに関するものかをユーザーが確認できます。名前空間はファミリーごとに分かれており、相互に置き換えられません。プロバイダー横断の *_FINDING／スキャンイベントでは汎用の dt.smartscape*／dt.entity*／dt.source* フィールドを使用します。RVA の状態／変更イベントではこれらのフィールドが null になり、affected_entity*／related_entities* に参照情報が格納されます。単純な件数／合格率の集計には適用しません。フィールド一覧とワイルドカード参照については、common-patterns.md § 17を参照してください。 7. 広範なエンティティセキュリティに関する質問には、外部ストリームも必要です。 「このホスト／K8s ノード／ワークロード／クラスターのセキュリティ検出結果」のようなプロンプトでは、DT RVA と SPM だけで終わらせないでください。広範なエンティティ OR チェーン（dt.smartscape_source.id、dt.entity.*、object.*、関連する k8s.* フィールド）でスコープを指定した外部／プロバイダー横断の *_FINDING ストリームも 24h で実行し、RVA（30m）および SPM（1h）の結果と統合してください。dt.source_entity はレガシー／スキャン時のフォールバックとして扱い、プロバイダー横断の主要なスコープ指定経路としては使用しないでください。外部ブランチの結果が 0 行の場合は、使用したスコープとともに「外部の検出結果は見つかりませんでした」と報告してください。Smartscape の結合については dt-sec-contextualization → entity-enrichment.md を読み込んでください。all-security-events.mdも参照してください。 8. 未加工の一覧表示と top-N の結果には、必ず上限を設定してください。 ユーザーが「top X」「last X」「first X」を求めた場合は、（ランキング／ソートの後に）| sort ... | limit X で終えてください。ユーザーが検出結果の一覧表示を求めていて、すべてのデータを明示的に求めておらず、出力が集計（summarize／makeTimeseries）でない場合は、既定で | limit 50 を追加してください。セキュリティ検出結果に対して、上限のない未加工の射影を実行してはいけません。完全なルールと例外については、common-patterns.md § 16を参照してください。 9. クエリの形を維持してください――ユーザーがより粗い集計を求めていない限り、by: のキーを省略してはいけません。 標準的なプロバイダー横断の summarize では、常に {event.provider, product.name, event.type, dt.security.risk.level} をキーにします。これらを 1 つでも省略すると、異なるプロバイダー、製品、検出タイプの行が単一の件数に暗黙的にまとめられ、評価で減点されます。ユーザーがより粗い表示を明示的に求めていない限り、4 つのキーによるグループ化を、より単純な by: {dt.security.risk.level} や by: {event.type} に置き換えないでください。common-patterns.md § 15を参照してください。

10. コンプライアンスのステータスには compliance.result.status.level を使用します（PASSED／FAILED／MANUAL／NOT_RELEVANT）。event.status や "PASS"／"FAIL" は決して使用しないでください。合格率は、最新スキャンの重複排除結合（on: {scan.id}）を行った後の、ルールごとの判定に基づいて計算します。フィールドの用語、重複排除結合、合格率のロールアップについては、compliance.mdを参照してください。

11. expand／join／lookupで配列を展開した後は、行数ではなく一意な識別子を数えます。 countDistinctExact(vulnerability.display_id)／countDistinctExact(finding.id)を使用するか、先に識別子とグループキーでdedupします。通常のcount()を安全に使えるのは、expandに入る時点で、カウント対象ごとに1行になっている場合だけです。例と例外については、→ common-patterns.md § Mistakes #55を参照してください。

12. エンティティカバレッジの確認結果が空の場合は、カバレッジなしと解釈します。 特定のエンティティがDynatraceのセキュリティ機能（RVA、SPM／KSPM、RAP、またはその他のDTネイティブ機能）の対象かどうかを確認する際、該当する検出結果やスキャン／完了イベントがなければ、そのエンティティは当該機能の対象ではありません。原因として、その機能が有効になっていないか、そのエンティティを監視するように設定またはデプロイされていない可能性を示してください。ユーザーがカバレッジについて尋ねている場合、「検出結果はありません」と曖昧に表現しないでください。カウント方法についてはcoverage-and-dashboards.mdを、照合レシピについてはdt-sec-contextualizationのcorrelation-and-coverage.mdを参照してください。

13. 空の結果は事実どおりに報告し、数値を捏造しないでください。 0行の場合は、使用した対象範囲とフィルターを明示して「一致するデータはありません」と伝えます。もっともらしい値を作り出してはいけません。フィルターを緩和する前に、各ファミリーで定められたリカバリー手順を適用してください（RVA：30m→24hの最新既知状態、検出結果：2h→24hに範囲を拡大、nullのk8s.*／dt.entity.*／dt.smartscape*に対するRVAフィルター：affected_entity.*／related_entities.*に切り替え）。調整を行った場合は、その旨を明確に伝えてください。リカバリーの詳細については、vulnerabilities-dynatrace.md／detections.mdを参照してください。

ドメイン固有のベストプラクティスと診断項目の全一覧については、上記の「How This Skill Is Organized」セクションに記載されたリファレンスを参照してください。

外部ドキュメント

• https://docs.dynatrace.com/docs/secure/threat-observability/concepts
• https://docs.dynatrace.com/docs/semantic-dictionary/model/security-events
• https://docs.dynatrace.com/docs/semantic-dictionary/fields

関連スキル

• dt-dql-essentials — 最初に読み込みます。DQLの基本構文、コマンドリファレンス、関数カタログ、Smartscapeのパターンを扱います。
• dt-sec-contextualization — エンティティのマッピングに関する質問で読み込みます。3方向の照合（K8sワークロード）、IPアドレスによるホストの照合、クラウドのPath 1、Podからノードへのトポロジー、証拠間の相関、カバレッジの照合レシピを扱います。
• dt-obs-kubernetes — K8sトポロジー。クラスター／ワークロードを対象とするセキュリティ検出結果に役立ちます。
• dt-obs-hosts — ホストインベントリ、プロセスレベルのコンテキスト。検出結果の影響を受けるエンティティがHOSTまたはPROCESS_GROUPの場合に役立ちます。
• dt-obs-services — サービスを対象としたクエリ。「<service-name>に影響する検出結果」というUC-G3や、脆弱なサービスからREDメトリクスへの追跡に役立ちます。
• dt-obs-aws / dt-obs-azure / dt-obs-gcp — クラウドSmartscape。外部のクラウドセキュリティ検出結果をプロバイダーのリソーストポロジーで補足する場合や、ハイパースケーラー固有のプロバイダーフィールドの処理（クラウドリソースID、ARN、アカウントのスコープ指定）に役立ちます。
• dt-obs-tracing — 脆弱なエンティティ／攻撃されたエンティティから代表的なリクエストトレースを調査します。
• dt-obs-problems — セキュリティ検出結果をクエリする前に、問題の影響を受けるエンティティ／関連するエンティティのIDを取得します（UC-G5）。