Security Insights Skill
Query and analyze Dynatrace security data in
using DQL. Events
come from
Dynatrace-native sources (RVA, RAP, Automated Detections, SPM) or
external products ingested via integrations (AWS Security Hub, Amazon
GuardDuty, GitHub Advanced Security, Snyk, Qualys, Tenable, and more).
What This Skill Covers
- 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.
When to Use This Skill
✅ Must-first routing rule: identify user intent first, then load the matching primary reference from Quick Start: Find Your Use Case before generating DQL.
Identify the intent, then load the matching reference before writing DQL.
Cross-cutting (any / all finding types)
| Intent / example | Reference | Pattern |
|---|
| Security posture / overview across all products (incl. DT-native) | § Broad-Question Query Decomposition | 3-stream decomposition (external+detections / RVA / KSPM ), merged; lead the count summary with KSPM compliance — CIS first (other standards + RVA + detections beneath) → § CIS-Primary Standard Summary |
| Findings on a specific entity — direct or related (blast radius) | dt-sec-contextualization · | Broad entity-security questions must decompose: external by / / () + DT RVA entity scope () + DT SPM entity scope () |
| Findings from a specific provider | § Scoping to a Specific Provider | contains(lower(event.provider | product.vendor), "<p>")
|
| Which third-party / external tools are sending data (DT-native excluded) | § Which external integrations are active | external-only enumeration (single query) |
| Which security products are integrated? / what security data do we have? (default: include DT-native RVA + KSPM) | § Broad-Question Query Decomposition | 3-stream decomposition; never a single wide scan |
| Which products cover a specific entity | dt-sec-contextualization correlation-and-coverage.md
· | summarize by ; findings-vs-scans split |
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 (CVE management)
| Intent / example | Reference | Pattern |
|---|
| Counts / severity ("how many critical?", by risk + mute status) | vulnerabilities-dynatrace.md
| RVA snapshot Steps 1–3 |
| Most vulnerable components / hosts / workloads (rankings) | vulnerabilities-entities.md
| Steps 1–3 + typed related_entities.<group>.ids
→ lookup on — ⚠ / are null on RVA events |
| CVE / library lookup; "am I vulnerable to log4shell?" | vulnerabilities-dynatrace.md
§ Entity Scoping | Step 2 CVE/component filter; scope RVA to a known entity |
| Blast radius — which entities are affected by CVE X | vulnerabilities-entities.md
| indirect-relation expand |
| Lifecycle — new / resolved / open-duration / MTTR | vulnerabilities-dynatrace.md
| post-derive ; MTTR via change-events-only snippet (§ Resolution time) |
| Runtime advanced — function-in-use, exposure, exploit, data-assets | vulnerabilities-dynatrace.md
| Davis-assessment (Step 3) |
| External scanner vulns — containers / artifacts / components | vulnerabilities-external.md
| + external routing |
| Verify external vulnerability findings with RVA | vulnerabilities-external.md
§ Verify external vulnerability findings with RVA · dt-sec-contextualization | First match the same vulnerability by vulnerability.references.cve
; then prove runtime relatedness via direct IDs, container-image digest → running , or host → Smartscape HOST |
| "Newly reported this period and not in the previous period" (external) | vulnerabilities-external.md
· § 18 | prior-period anti-join () — a filter is NOT equivalent |
| AI/LLM/GenAI workload vulnerabilities; "which AI services have vulnerabilities?" | vulnerabilities-dynatrace-advanced.md
§ AI-workload vulnerabilities | DT findings + GENAI scope (, dedup ) |
| New AI-workload vulnerabilities this period | vulnerabilities-dynatrace-advanced.md
§ UC-AI2 | prior-window anti-join on {genai_service.id, vulnerability.id}
|
Detections (threats & attacks)
| Intent / example | Reference | Pattern |
|---|
| Severity / time-window overview (DT + external) | · | summary; default unqualified timeframe is , widen to only if empty |
| By attack type (, crypto-mining, …) | | substring match |
| Attacker IPs / campaigns | | + |
| MITRE technique / sub-technique | | arrays |
| RAP-only / Automated-Detections-only | § Provider Routing | product.name=="Runtime Application Protection"
/ event.provider=="Dynatrace Automated Detections"
|
| Map detections to entities; repeated firing | · dt-sec-contextualization | grouping / enrichment |
| A specific external provider | § Scoping to a Specific Provider | provider idiom |
MITRE routing tie-breaker: a MITRE ATT&CK question routes by intent. "Which techniques did we
detect / observe (on our entities)?" →
(
). "Which techniques are
reported in threat intel / campaigns in the wild?" →
(
). Don't merge the two — a report tagged T1059 is not evidence T1059 occurred in your environment.
Threat intelligence (external reports & IOCs)
| Intent / example | Reference | Pattern |
|---|
| Show / list / count threat intelligence reports; reports by provider, actor, malware family, targeted country/industry, TLP, report type | | + (SD guard first); never the four-key finding summarize |
| Top IOCs (CVEs / IPs / domains / URLs / emails / hashes) or MITRE techniques across reports | § IOC extraction | → observable → countDistinctExact(threat.report.id)
|
| Am I exposed to report X / are these IOCs in my environment? (threat-exposure) | § Threat-Exposure Correlation | report IOCs/CVEs/techniques to /RVA/; logs/spans IoC hunt → |
Compliance (policy violations & benchmarks)
| Intent / example | Reference | Pattern |
|---|
| Pass-rate / posture (CIS / DORA / NIST / STIG) | | Load first — SPM Steps 1–2 + passRate |
| Critical misconfigurations | | Load first — Steps 1–2 + severity filter |
| Compliance / misconfigurations on a specific entity | § Entity Security-Tab View (entity-scoped filter) · | Mirror the entity Security tab (CIS default, failed-only): Table 1 DT CIS failed rules → Table 2 other DT standards (overlap caveat) → Table 3 external misconfigs. Broad posture/count questions instead use § CIS-Primary Standard Summary (scorecard). |
| Map control/standard → entities; per-namespace | | entity scoping via compliance.standard.short_name
/ (⚠ never ) |
| Cloud / non-K8s (PCI/ISO/HIPAA/GDPR; AWS/Azure/GCP) | § External | external taxonomy (//) |
| External violations grouped by standard / framework | § External | is an array — it before |
| Config drift / newly failing rules vs previous week (DT) | § Week-over-Week Config Drift | prior-period anti-join — a wide fetch window is NOT a substitute |
| External compliance findings new this period, absent in prior | § External | prior-period anti-join (same rule as drift) |
| KSPM (Kubernetes-only, DT-native) | | product.name=="Security Posture Management"
|
Coverage, enrichment & dashboards
| Intent / example | Reference | Pattern |
|---|
| Coverage / "covered vs not covered" / coverage gaps — hosts / processes / workloads | coverage-and-dashboards.md
(counting logic) · dt-sec-contextualization correlation-and-coverage.md
(match recipes) | ⚠ MUST start from + scan events — summarizing scan events alone has no denominator and cannot answer a coverage question |
| Specific entity coverage by a DT capability (RVA, SPM, RAP, other DT-native) | coverage-and-dashboards.md
| If no relevant findings or scan/completion events exist for that entity in the capability's operational window, answer not covered — capability is likely not enabled or not configured for that entity |
| Map external findings → workloads / hosts / cloud | dt-sec-contextualization | 3-way match (K8s) / host-by-IP / Path-1 (cloud) — ⚠ always join to Smartscape; never group findings by raw / / / cloud resource IDs alone |
| One-row-per-entity risk summary | dt-sec-contextualization · coverage-and-dashboards.md
| RVA + external merge |
| Dashboards — KPI tiles, top-N, trends, donuts | coverage-and-dashboards.md
| , summarization recipes |
❌ Don't use for:
- Dynatrace-detected problems →
- Application/infrastructure logs →
- Distributed tracing →
- Service performance/RED metrics →
Introduction to AppSec Data
All security events are stored in
and are categorized by
:
- RVA vulnerabilities —
VULNERABILITY_STATE_REPORT_EVENT
(15-minute snapshots per entity)
- KSPM compliance — (per , joined with
COMPLIANCE_SCAN_COMPLETED
on for latest-scan dedup)
- External compliance (CSPM / VSPM / external posture tools) — with the external taxonomy ( / / ); typically null
- Detections — (RAP via
product.name == "Runtime Application Protection"
), (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 — ,
- Threat intelligence — (external TI platforms: AlienVault OTX pulses, CrowdStrike Falcon Intelligence). A separate class of data — not a finding: no / / , 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 .
Full taxonomy and field reference → data-model.md
Critical Constraint: Snapshot Windows
DT RVA and KSPM are snapshot tools, not event streams. The minimum
query window required for each pipeline:
- RVA: 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: fixed window (needs latest
COMPLIANCE_SCAN_COMPLETED
marker for the inner-join)
- External findings (incl. CSPM/VSPM): (no snapshot semantics — these are one-shot events)
Widening these windows does NOT look back further — they only capture the latest report/scan cycle. For historical trends, use
over longer windows.
DT-generated vs. RVA state reports. Dynatrace-generated
queries (e.g. AI-workload scoping in
vulnerabilities-dynatrace-advanced.md § AI-workload vulnerabilities)
also use a
window, but dedup on
because DT findings are
re-emitted on every scan run (~15 min) — distinct from the RVA state-report
window, which dedups on
{vulnerability.display_id, affected_entity.id}
.
Do not mix the two dedup grains.
Default Time Ranges in the Dynatrace Apps
The UI apps show pre-set defaults in their time picker. When a user
references "the app's view" without giving an explicit window, match
these to align query results with what the user sees in the UI:
| App | Default time picker |
|---|
| Vulnerabilities app | 30 minutes |
| Threats & Exploits app | 2 hours |
| Security Posture Management app | 2 hours |
These app defaults are broader than the minimum snapshot windows above
(e.g. SPM app = 2h vs. KSPM pipeline minimum = 1h). The minimum window is
what the inner-join / latest-cycle dedup needs to function; the app default
is what the user sees on first load. Use the minimum window when
generating canonical pipeline DQL; use the app default when the user
asks "what does the SPM app show me right now?" or builds a dashboard tile
intended to match the app view.
See vulnerabilities-dynatrace.md § Snapshot vs. History for details.
How This Skill Is Organized
The skill is split into two parts for scalability:
- SKILL.md (this file) — Entry point, quick lookup, routing to the right reference
- references/ — Detailed guidance by capability or domain:
- data-model.md — Reference for — 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 () query workflows.
- vulnerabilities-external.md — External SCA / SAST / image-scanner vulnerability findings ().
- 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 (): 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 ( 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 for any entity-mapping question.
Universal Best Practices
-
Always load dt-dql-essentials first — DQL syntax and function names differ from SQL. Confirm all functions in
before generating queries.
-
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
. If no template covers the request, say so and adapt the closest one — never fabricate fields or values.
-
No filters — security event data may live in any bucket; filtering by bucket risks hiding findings.
-
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.
-
Always include an explicit clause — use the correct window for the query class:
| Query class | Default window | Notes |
|---|
| DT RVA snapshots | fixed | Captures latest 15-min state-report cycle — do not widen |
| DT KSPM snapshots | fixed | Aligned with scan-completion cycle inner-join — do not widen |
| RAP / external detection retrieval or current summary |
first attempt | Matches Threats & Exploits app default. Widen to
only if zero rows returned or if the user explicitly asks for a longer window (see
detections.md § Widen-on-empty fallback) |
| Cross-provider summary (aggregated) |
| Summaries aggregate over time; start broad |
Omitting
falls back to a default window that doesn't match snapshot semantics and produces drift between query runs. The 30m / 1h windows are
not arbitrary — they're tied to the underlying RVA / SPM scan cadence. See
common-patterns.md § 7 for the full window reference.
Decompose DT-inclusive broad / posture-overview questions ("which security products are integrated incl. Dynatrace-native?", posture overview, cross-category counts that include DT vulnerabilities/compliance) — never answer with one wide scan over all of
. Run three separate queries and merge: Stream A external + DT detections (
, double-counting guard), Stream B DT RVA (
), Stream C DT KSPM (
). This keeps the high-cardinality snapshot streams in their tight windows and avoids double-counting. A narrower "which
external integrations are sending data?" stays a single external-only query. See
all-security-events.md § Broad-Question Query Decomposition.
6.
Preserve entity identifiers on raw listings (top / latest / list / show-me — no
) so users see which entity each finding is on. The namespaces split by family and are
not interchangeable: cross-provider
/ scan events use the generic
/
/
fields; RVA state/change events leave those null and carry refs in
/
. Not for pure count / pass-rate summaries. Field lists and wildcard reference →
common-patterns.md § 17.
7.
Broad entity-security questions require the external stream too. For prompts like "security findings of this host / K8s node / workload / cluster", do not stop after DT RVA and SPM. Also run the external/cross-provider
stream scoped with the wide entity OR chain (
,
,
, and relevant
fields) in
, then merge with RVA (
) and SPM (
). Treat
as a legacy/scan fallback, not a primary cross-provider scoping path. If the external branch returns 0 rows, report "no external findings found" with the scope used. Load
dt-sec-contextualization →
for the Smartscape join. See also
all-security-events.md.
8.
Always bound raw listing and top-N results. If the user asks for "top X", "last X", or "first X", end with
(after the ranking/sort). If the user asks to list/show findings but does
not explicitly ask for all data and the output is not a summary (
/
), add
by default. Do not run unbounded raw projections on security findings. Full rule and exceptions →
common-patterns.md § 16.
9.
Preserve query shape — do not drop keys unless the user asks for coarser aggregation. The canonical cross-provider
always keys by
{event.provider, product.name, event.type, dt.security.risk.level}
. Dropping any of these silently merges rows from different providers, products, or finding types into a single count and will be penalized by evaluators. Do not replace the four-key grouping with a simpler
by: {dt.security.risk.level}
or
unless the user explicitly requests a coarser view. See
common-patterns.md § 15.
-
Compliance status uses compliance.result.status.level
(
/
/
/
) — never
or
/
. Pass rate is computed on per-rule verdicts after the latest-scan dedup join
. Field terminology, the dedup join, and the pass-rate rollup →
compliance.md.
-
Count distinct identities, not rows, after / / that fan out arrays — use
countDistinctExact(vulnerability.display_id)
/
countDistinctExact(finding.id)
, or
on identity + group key first. A plain
is safe only when the grain entering the
is already one row per counted item. Examples and the exception →
common-patterns.md § Mistakes #55.
-
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
.
-
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
/
/
→ pivot to
/
) and say so explicitly if you adapt. Recovery details →
vulnerabilities-dynatrace.md /
detections.md.
For domain-specific best practices and the full diagnostic catalog, see the references listed in the "How This Skill Is Organized" section above.
External Documentation
Related Skills
- 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 " 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)