dt-sec-insights

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)

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)

Detections (threats & attacks)

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)

Compliance (policy violations & benchmarks)

Coverage, enrichment & dashboards

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

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:

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.

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 security.events. Run three separate queries and merge: Stream A external + DT detections (24h, double-counting guard), Stream B DT RVA (30m), Stream C DT KSPM (1h). 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.

1. Preserve entity identifiers on raw listings (top / latest / list / show-me — no summarize) so users see which entity each finding is on. The namespaces split by family and are not interchangeable: cross-provider *_FINDING / scan events use the generic dt.smartscape* / dt.entity* / dt.source* fields; RVA state/change events leave those null and carry refs in affected_entity* / related_entities*. Not for pure count / pass-rate summaries. Field lists and wildcard reference → common-patterns.md § 17.
2. 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 *_FINDING stream scoped with the wide entity OR chain (dt.smartscape_source.id, dt.entity.*, object.*, and relevant k8s.* fields) in 24h, then merge with RVA (30m) and SPM (1h). Treat dt.source_entity 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 → entity-enrichment.md for the Smartscape join. See also all-security-events.md.
3. Always bound raw listing and top-N results. If the user asks for "top X", "last X", or "first X", end with | sort ... | limit X (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 (summarize / makeTimeseries), add | limit 50 by default. Do not run unbounded raw projections on security findings. Full rule and exceptions → common-patterns.md § 16.
4. Preserve query shape — do not drop `by:` keys unless the user asks for coarser aggregation. The canonical cross-provider summarize 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 by: {event.type} unless the user explicitly requests a coarser view. See common-patterns.md § 15.

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.

1. 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.

1. 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.

1. 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.

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

• 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

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