• Vulnerability management — open CVEs on running code from DT-native RVA (risk-ranked with Dynatrace Security Score and the four-dimension runtime assessment: vulnerable-function-in-use, public network exposure, reachable data assets, public exploit available) plus external SCA / SAST / image scanners.
• Compliance posture — DT-native KSPM (Kubernetes-only: CIS, DORA, NIST, STIG) plus CSPM/VSPM and external compliance/posture providers.
• Runtime attacks and threats — DT-native detections (RAP runtime attacks, Automated Detections rules) plus external detection providers.
• Threat intelligence — external threat-intelligence reports (AlienVault OTX pulses, CrowdStrike Falcon Intelligence) with actor / campaign / targeting context and indicators of compromise (IOCs); correlate reported IOCs / CVEs / techniques against your monitored environment. These are threat intel about the wild — not findings on your entities — and are queried separately.
• Scan coverage analysis — covered vs. not-covered k8s workloads/hosts/processes, by Dynatrace scanning feature (

  Library Vulnerability Analytics

  ,

  Operating System Vulnerability Analytics

  ,

  Code-level Vulnerability Analytics

  ) or by external product.
• Entity enrichment — map external findings to Dynatrace runtime entities (hosts, K8s workloads, cloud resources) via Smartscape.
• Dashboards / KPIs — tiles, top-N tables, trend charts, coverage donuts.

all-security-events.md

24h

30m

1h

compliance.md

entity-enrichment.md

all-security-events.md

*_FINDING

dt.smartscape_source.id

dt.entity.*

k8s.*

24h

30m

1h

all-security-events.md

contains(lower(event.provider | product.vendor), "<p>")

all-security-events.md

all-security-events.md

security.events

correlation-and-coverage.md

all-security-events.md

product.*

Routing tie-breaker: an unqualified "which security products are integrated? / are we covered? / what do we have?" defaults to the DT-inclusive 3-stream decomposition (it must query DT vulnerabilities and compliance). Take the external-only single query only when the user explicitly scopes to external / third-party tools ("which external tools are sending us data?").

vulnerabilities-dynatrace.md

vulnerabilities-entities.md

expand

related_entities.<group>.ids

smartscapeNodes

id_classic

k8s.*

dt.entity.*

vulnerabilities-dynatrace.md

vulnerabilities-entities.md

related_entities.*

vulnerabilities-dynatrace.md

resolution.change_date

vulnerabilities-dynatrace.md

fieldsAdd

vulnerabilities-external.md

VULNERABILITY_FINDING

vulnerabilities-external.md

entity-enrichment.md

vulnerability.references.cve

dt.smartscape*

CONTAINER

host.ip

vulnerabilities-external.md

common-patterns.md

isNull(right.*)

finding.time.created

vulnerabilities-dynatrace-advanced.md

30m

finding.id

vulnerabilities-dynatrace-advanced.md

{genai_service.id, vulnerability.id}

detections.md

all-security-events.md

DETECTION_FINDING

2h

24h

SQL injection

detections.md

finding.type

detections.md

expand actor.ips

ip()

detections.md

threat.attack.*

detections.md

product.name=="Runtime Application Protection"

event.provider=="Dynatrace Automated Detections"

detections.md

entity-enrichment.md

object.id

all-security-events.md

contains

MITRE routing tie-breaker: a MITRE ATT&CK question routes by intent. "Which techniques did we detect / observe (on our entities)?" →

detections.md

(

DETECTION_FINDING

). "Which techniques are reported in threat intel / campaigns in the wild?" →

threat-intelligence.md

(

THREAT_REPORT

). Don't merge the two — a report tagged T1059 is not evidence T1059 occurred in your environment.

threat-intelligence.md

THREAT_REPORT

dedup {threat.report.id}

threat-intelligence.md

dedup

expand

countDistinctExact(threat.report.id)

threat-intelligence.md

join

VULNERABILITY_FINDING

DETECTION_FINDING

dt-sec-ioc-hunting

compliance.md

compliance.md

compliance.md

compliance.md

compliance.md

${entityIdsOrNames}

entity-enrichment.md

compliance.md

compliance.standard.short_name

compliance.rule.id

metadata_json

compliance.md

compliance.standards

policy

control

compliance.md

compliance.standards

expand

summarize

compliance.md

compliance.md

compliance.md

product.name=="Security Posture Management"

coverage-and-dashboards.md

correlation-and-coverage.md

smartscapeNodes

lookup

coverage-and-dashboards.md

entity-enrichment.md

object.name

k8s.namespace.name

host.name

entity-enrichment.md

coverage-and-dashboards.md

coverage-and-dashboards.md

makeTimeseries

• Dynatrace-detected problems →

  dt-obs-problems

• Application/infrastructure logs →

  dt-obs-logs

• Distributed tracing →

  dt-obs-tracing

• Service performance/RED metrics →

  dt-obs-services

security.events

event.type

• RVA vulnerabilities —

  VULNERABILITY_STATE_REPORT_EVENT

  (15-minute snapshots per entity)
• KSPM compliance —

  COMPLIANCE_FINDING

  (per

  (rule, K8s object)

  , joined with

  COMPLIANCE_SCAN_COMPLETED

  on

  scan.id

  for latest-scan dedup)
• External compliance (CSPM / VSPM / external posture tools) —

  COMPLIANCE_FINDING

  with the external taxonomy (

  compliance.standards

  /

  compliance.policy

  /

  compliance.control

  );

  compliance.rule.*

  typically null
• Detections —

  DETECTION_FINDING

  (RAP via

  product.name == "Runtime Application Protection"

  ),

  SECURITY_EVENT

  (RAP events in some tenants), Automated Detections via

  event.provider == "Dynatrace Automated Detections"

  , external security tools; plus

  DETECTION_EXECUTION_SUMMARY

  for per-rule-run audit (Automated Detections only)
• Scan coverage —

  VULNERABILITY_SCAN

  ,

  COMPLIANCE_SCAN

• Threat intelligence —

  THREAT_REPORT

  (external TI platforms: AlienVault OTX pulses, CrowdStrike Falcon Intelligence). A separate class of data — not a finding: no

  finding.*

  /

  object.*

  /

  dt.security.risk.level

  , no affected entity, no scan cycle. Never folded into the cross-provider finding summary or the posture-overview decomposition — queried on its own via threat-intelligence.md. Dedup by

  threat.report.id

  .

• RVA:

  30m

  fixed window (captures latest 15-min cycle); if a 30m snapshot is empty or clearly stale, use the controlled 24h latest-known-state fallback in vulnerabilities-dynatrace.md
• KSPM:

  1h

  fixed window (needs latest

  COMPLIANCE_SCAN_COMPLETED

  marker for the inner-join)
• External findings (incl. CSPM/VSPM):

  2h–24h+

  (no snapshot semantics — these are one-shot events)

makeTimeseries

DT-generated

VULNERABILITY_FINDING

vs. RVA state reports. Dynatrace-generated

VULNERABILITY_FINDING

queries (e.g. AI-workload scoping in vulnerabilities-dynatrace-advanced.md § AI-workload vulnerabilities) also use a

30m

window, but dedup on

finding.id

because DT findings are re-emitted on every scan run (~15 min) — distinct from the RVA state-report

30m

window, which dedups on

{vulnerability.display_id, affected_entity.id}

. Do not mix the two dedup grains.

1. SKILL.md (this file) — Entry point, quick lookup, routing to the right reference
2. references/ — Detailed guidance by capability or domain:
   • data-model.md — Reference for

     fetch security.events

     — event types, providers, fields, entity scoping.
   • common-patterns.md — Cross-cutting patterns, common mistakes to avoid, and query troubleshooting reference.

• vulnerabilities-dynatrace.md — Dynatrace Runtime Vulnerability Analytics (RVA): snapshot pipeline, counts, lifecycle, runtime assessment, CLV, tracking, mute, and entity scoping.
• vulnerabilities-dynatrace-advanced.md — Advanced DT vulnerability guidance: best practices and AI-workload (

  VULNERABILITY_FINDING

  ) query workflows.
• vulnerabilities-external.md — External SCA / SAST / image-scanner vulnerability findings (

  VULNERABILITY_FINDING

  ).
• vulnerabilities-entities.md — DT RVA entity rankings: "most vulnerable hosts / K8s workloads / components" + CVE blast radius.
• compliance.md — Dynatrace Security Posture Management (SPM / XSPM) compliance findings and external provider compliance findings.
• detections.md — Runtime Application Protection (RAP) detections, Automated Detection rules, and external provider detections.
• threat-intelligence.md — External threat-intelligence reports (

  THREAT_REPORT

  ): AlienVault OTX / CrowdStrike Falcon Intelligence, IOC extraction, and threat-exposure correlation. Not findings — queried separately.
• all-security-events.md — Cross-provider queries, double-counting guard, unified summaries
• coverage-and-dashboards.md — Entity coverage counting logic (

  smartscapeNodes

  denominator, covered vs. not-covered) and dashboard patterns (KPI tiles, top-N, trend charts, coverage donuts).
• entity-enrichment — Moved to dt-sec-contextualization

  references/entity-enrichment.md

  (3-way match / host-by-IP / cloud). Load

  dt-sec-contextualization

  for any entity-mapping question.

1. Always load dt-dql-essentials first — DQL syntax and function names differ from SQL. Confirm all functions in

   dt-dql-essentials

   before generating queries.
2. Ground every query in the routed reference's canonical template — do not improvise DQL. Identify intent, load the matching reference (per When to Use), and build from its canonical pipeline / named building block. Do not invent field names, enum values, join syntax, or pipeline shape from SQL habits. Deviate from a template only with syntax explicitly shown in a skill example or validated in

   dt-dql-essentials

   . If no template covers the request, say so and adapt the closest one — never fabricate fields or values.
3. No

   dt.system.bucket

   filters — security event data may live in any bucket; filtering by bucket risks hiding findings.
4. Use the correct provenance field for the family — RVA uses

   event.provider == "Dynatrace"

   , SPM/detections use

   product.vendor == "Dynatrace"

   . See data-model.md § Provider Taxonomy.
5. Always include an explicit

   from:

   clause — use the correct window for the query class:

   Query class	Default window	Notes
   DT RVA snapshots	30m fixed	Captures latest 15-min state-report cycle — do not widen
   DT KSPM snapshots	1h fixed	Aligned with scan-completion cycle inner-join — do not widen

2h

24h

24h

from:

security.events

24h

30m

1h

summarize

*_FINDING

dt.smartscape*

dt.entity*

dt.source*

affected_entity*

related_entities*

*_FINDING

dt.smartscape_source.id

dt.entity.*

object.*

k8s.*

24h

30m

1h

dt.source_entity

entity-enrichment.md

| sort ... | limit X

summarize

makeTimeseries

| limit 50

by:

summarize

{event.provider, product.name, event.type, dt.security.risk.level}

by: {dt.security.risk.level}

by: {event.type}

1. Compliance status uses

   compliance.result.status.level

   (

   PASSED

   /

   FAILED

   /

   MANUAL

   /

   NOT_RELEVANT

   ) — never

   event.status

   or

   "PASS"

   /

   "FAIL"

   . Pass rate is computed on per-rule verdicts after the latest-scan dedup join

   on: {scan.id}

   . Field terminology, the dedup join, and the pass-rate rollup → compliance.md.
2. Count distinct identities, not rows, after

   expand

   /

   join

   /

   lookup

   that fan out arrays — use

   countDistinctExact(vulnerability.display_id)

   /

   countDistinctExact(finding.id)

   , or

   dedup

   on identity + group key first. A plain

   count()

   is safe only when the grain entering the

   expand

   is already one row per counted item. Examples and the exception → common-patterns.md § Mistakes #55.
3. Interpret empty entity-coverage probes as not covered. When validating whether a specific entity is covered by a Dynatrace security capability (RVA, SPM/KSPM, RAP, or another DT-native capability), absence of the relevant findings and scan/completion events means the entity is not covered by that capability. State the likely cause: the capability is not enabled, or it is not configured / deployed to monitor that entity. Do not soften this into "no findings" when the user asked about coverage. Counting logic → coverage-and-dashboards.md; match recipes → dt-sec-contextualization

   correlation-and-coverage.md

   .
4. Report empty results truthfully — never fabricate numbers. 0 rows means "no matching data," stated with the scope and filters used; never invent plausible values. Before relaxing a filter, apply the family's documented recovery (RVA 30m→24h latest-known-state, detections 2h→24h widen, RVA filters on null

   k8s.*

   /

   dt.entity.*

   /

   dt.smartscape*

   → pivot to

   affected_entity.*

   /

   related_entities.*

   ) and say so explicitly if you adapt. Recovery details → vulnerabilities-dynatrace.md / detections.md.

• 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 — Load first. Core DQL syntax, command reference, function catalog, Smartscape patterns.
• dt-sec-contextualization — Load for any entity-mapping question: 3-way match (K8s workload), host-by-IP, cloud Path 1, pod→node topology, cross-evidence correlation, coverage match recipes.
• dt-obs-kubernetes — K8s topology; useful for security findings scoped to clusters / workloads
• dt-obs-hosts — Host inventory, process-level context; useful when a finding's affected entity is a HOST or PROCESS_GROUP
• dt-obs-services — Service-scoped queries; useful for UC-G3 "findings affecting

  <service-name>

  " and tracing from a vulnerable service to RED metrics
• dt-obs-aws / dt-obs-azure / dt-obs-gcp — Cloud Smartscape; useful for enriching external cloud-security findings against the provider's resource topology, and for hyperscaler-specific provider field handling (cloud resource IDs, ARNs, account scoping)
• dt-obs-tracing — Drill from a vulnerable / attacked entity to representative request traces
• dt-obs-problems — Get affected/related entity IDs for a problem before querying security findings (UC-G5)