Security Insights Skill

Query and analyze Dynatrace security data in security.events 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)	all-security-events.md § Broad-Question Query Decomposition	3-stream decomposition (external+detections 24h / RVA 30m / KSPM 1h), merged; lead the count summary with KSPM compliance — CIS first (other standards + RVA + detections beneath) → compliance.md § CIS-Primary Standard Summary
Findings on a specific entity — direct or related (blast radius)	dt-sec-contextualization entity-enrichment.md · all-security-events.md	Broad entity-security questions must decompose: external *_FINDING by dt.smartscape_source.id / dt.entity.* / k8s.* (24h) + DT RVA entity scope (30m) + DT SPM entity scope (1h)
Findings from a specific provider	all-security-events.md § Scoping to a Specific Provider	contains(lower(event.provider | product.vendor), "<p>")
Which third-party / external tools are sending data (DT-native excluded)	all-security-events.md § 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)	all-security-events.md § Broad-Question Query Decomposition	3-stream decomposition; never a single wide security.events scan
Which products cover a specific entity	dt-sec-contextualization correlation-and-coverage.md · all-security-events.md	summarize by product.*; 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 + expand typed related_entities.<group>.ids → smartscapeNodes lookup on id_classic — ⚠ k8s.*/dt.entity.* 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	related_entities.* indirect-relation expand
Lifecycle — new / resolved / open-duration / MTTR	vulnerabilities-dynatrace.md	post-derive resolution.change_date; MTTR via change-events-only snippet (§ Resolution time)
Runtime advanced — function-in-use, exposure, exploit, data-assets	vulnerabilities-dynatrace.md	Davis-assessment fieldsAdd (Step 3)
External scanner vulns — containers / artifacts / components	vulnerabilities-external.md	VULNERABILITY_FINDING + external routing
Verify external vulnerability findings with RVA	vulnerabilities-external.md § Verify external vulnerability findings with RVA · dt-sec-contextualization entity-enrichment.md	First match the same vulnerability by vulnerability.references.cve; then prove runtime relatedness via direct dt.smartscape* IDs, container-image digest → running CONTAINER, or host host.ip → Smartscape HOST
"Newly reported this period and not in the previous period" (external)	vulnerabilities-external.md · common-patterns.md § 18	prior-period anti-join (isNull(right.*)) — a finding.time.created filter is NOT equivalent
AI/LLM/GenAI workload vulnerabilities; "which AI services have vulnerabilities?"	vulnerabilities-dynatrace-advanced.md § AI-workload vulnerabilities	Probe smartscapeNodes "GENAI_SERVICE" first — zero rows → report cannot be determined (no GenAI-monitored services); non-zero → DT findings + GENAI scope (30m, dedup finding.id). ⚠ Zero rows = hard stop — no fallbacks permitted: entity/namespace/workload name substrings, ML library component lists, process/image/label patterns are all prohibited substitutes.
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)	detections.md · all-security-events.md	DETECTION_FINDING summary; default unqualified timeframe is 2h, widen to 24h only if empty
By attack type (SQL injection, crypto-mining, …)	detections.md	finding.type substring match
Attacker IPs / campaigns	detections.md	expand actor.ips + ip()
MITRE technique / sub-technique	detections.md	threat.attack.* arrays
RAP-only / Automated-Detections-only	detections.md § Provider Routing	product.name=="Runtime Application Protection" / event.provider=="Dynatrace Automated Detections"
Map detections to entities; repeated firing	detections.md · dt-sec-contextualization entity-enrichment.md	object.id grouping / enrichment
A specific external provider	all-security-events.md § Scoping to a Specific Provider	provider contains idiom

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 (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	threat-intelligence.md	THREAT_REPORT + dedup {threat.report.id} (SD guard first); never the four-key finding summarize
Top IOCs (CVEs / IPs / domains / URLs / emails / hashes) or MITRE techniques across reports	threat-intelligence.md § IOC extraction	dedup → expand observable → countDistinctExact(threat.report.id)
Am I exposed to report X / are these IOCs in my environment? (threat-exposure)	threat-intelligence.md § Threat-Exposure Correlation	join report IOCs/CVEs/techniques to VULNERABILITY_FINDING/RVA/DETECTION_FINDING; logs/spans IoC hunt → dt-sec-ioc-hunting

Compliance (policy violations & benchmarks)

Intent / example	Reference	Pattern
Pass-rate / posture (CIS / DORA / NIST / STIG)	compliance.md	Load compliance.md first — SPM Steps 1–2 + passRate
Critical misconfigurations	compliance.md	Load compliance.md first — Steps 1–2 + severity filter
Compliance / misconfigurations on a specific entity	compliance.md § Entity Security-Tab View (entity-scoped ${entityIdsOrNames} filter) · entity-enrichment.md	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	compliance.md	entity scoping via compliance.standard.short_name / compliance.rule.id (⚠ never metadata_json)
Cloud / non-K8s (PCI/ISO/HIPAA/GDPR; AWS/Azure/GCP)	compliance.md § External	external taxonomy (compliance.standards/policy/control)
External violations grouped by standard / framework	compliance.md § External	compliance.standards is an array — expand it before summarize
Config drift / newly failing rules vs previous week (DT)	compliance.md § 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	compliance.md § External	prior-period anti-join (same rule as drift)
KSPM (Kubernetes-only, DT-native)	compliance.md	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 smartscapeNodes + lookup 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 entity-enrichment.md	3-way match (K8s) / host-by-IP / Path-1 (cloud) — ⚠ always join to Smartscape; never group findings by raw object.name / k8s.namespace.name / host.name / cloud resource IDs alone
One-row-per-entity risk summary	dt-sec-contextualization entity-enrichment.md · coverage-and-dashboards.md	RVA + external merge
Dashboards — KPI tiles, top-N, trends, donuts	coverage-and-dashboards.md	makeTimeseries, summarization recipes

❌ Don't use for:

• Dynatrace-detected problems → dt-obs-problems
• Application/infrastructure logs → dt-obs-logs
• Distributed tracing → dt-obs-tracing
• Service performance/RED metrics → dt-obs-services

Introduction to AppSec Data

All security events are stored in security.events and are categorized by 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.

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: 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)

Widening these windows does NOT look back further — they only capture the latest report/scan cycle. For historical trends, use makeTimeseries over longer windows.

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.

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:

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.

Universal Best Practices

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

| RAP / external detection retrieval or current summary | 2h first attempt | Matches Threats & Exploits app default. Widen to 24h 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) | 24h | Summaries aggregate over time; start broad |

Omitting from: 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.