17.4 Security Investigator, Notifications & the Remediation Workflow

Key Takeaways

  • Security Investigator streamlines evidence-driven investigations on data in Grail, using logs, metrics, and traces with assisted functionality and automations.
  • The Vulnerabilities app detects, visualizes, analyzes, monitors, and helps fix vulnerabilities across the stack in a combined, prioritized view of code-level, third-party, and runtime findings.
  • Findings move through open, resolved, and muted states, and are constantly reassessed so a risk level can change without any code change.
  • Muting is a documented, reviewable exception for accepted risk, never a way to reduce list length.
  • Workflows turn a security finding into an automatic ticket or notification, which is the intended answer when a scenario asks how detection connects to an organization's existing response process.
Last updated: September 2026

Detection without a response process produces a growing list and no improvement. The official learning path's security call to action makes this explicit, asking candidates to consider what happens in their organization when a vulnerability is detected, whether an automatic process exists to create actionable items or tickets, and how Dynatrace integrates with such a tool. This section answers that question.


The Vulnerabilities App: One Prioritized View

Vulnerabilities helps you detect, visualize, analyze, monitor, and fix vulnerabilities in your application stack. It can identify code-level, third-party, and runtime vulnerabilities, showing all issues in a combined, prioritized view.

The word doing the work is combined. Most organizations run one tool for dependency scanning, another for static analysis, and a third for runtime protection, then manually reconcile three lists that disagree about severity and cannot see each other's context. A single prioritized view — ranked by Davis Security Score, with runtime evidence attached — is the platform argument.

Alongside it, the ready-made Vulnerability coverage dashboard provides insight into process and host coverage, scan activity, and the evolution of vulnerability findings, which is how a security lead answers "are we actually looking everywhere?" rather than only "what did we find?"


Security Investigator

Security Investigator is designed to streamline evidence-driven investigations on data in Grail. It features assisted functionalities and automations to expedite and support investigation resolution, leveraging logs, metrics, and traces.

The design premise is that a security investigation is a query problem. An analyst asked "did this vulnerability get exploited, and what did the attacker touch?" must pivot repeatedly between data types — authentication logs, the traces of the requests in question, the metrics that show whether volume was anomalous — and in most toolchains each pivot means a different system, a different query language, and a manual timestamp translation.

Because everything is in Grail and queryable with DQL, Security Investigator keeps a whole investigation in one place:

  1. Start from an alert, an attack record, or an indicator.
  2. Query logs for the affected time window and entity.
  3. Pivot to the traces of the suspicious requests to see what the code actually did.
  4. Check metrics for anomalous volume, error rates, or egress.
  5. Preserve the query chain as evidence for the incident record.

Step 5 matters more than it appears: an investigation whose reasoning cannot be reconstructed is difficult to defend to an auditor or a regulator. This is the security counterpart of the notebook discipline in Section 15.1.


The Finding Lifecycle

Findings move through three states, and the overview charts them by status — resolved, open, and muted (open) — over the last 30 days, showing when a vulnerability was opened, reopened, resolved, or muted.

StateMeaning
OpenPresent and unaddressed
ResolvedNo longer detected — the vulnerable component is no longer running
Muted (open)Still present, but deliberately suppressed from active work

Reopened is the state that teaches the most. A finding resolves when the vulnerable component stops running and reopens if it comes back — a rollback, a stale image redeployed, an autoscaling group launching from an old template. A team that patches and closes the ticket without noticing the reopen has not fixed anything.

Findings are also constantly reassessed and may change risk level over time. A vulnerability that was medium because the service had no internet exposure becomes high the day an ingress rule changes — with no code change at all. Security posture is a function of the environment, not only of the code.


Muting Discipline

Muting is legitimate and necessary: a finding may be a confirmed false positive, may be mitigated by a compensating control, or may be an accepted risk with a scheduled remediation date. It is also the most commonly abused feature in vulnerability management.

The rules that appear in exam scenarios:

  • Mute with a reason and an owner. A mute with no recorded justification is indistinguishable from negligence at audit.
  • Mute with an expiry or a review date. Permanent mutes accumulate into an invisible risk backlog.
  • Never mute to reduce list length. Muting changes the report, not the risk — the vulnerable code keeps running.

When a scenario proposes muting everything below a threshold to make a dashboard look better, that is the distractor.


Routing Findings into the Response Process

The integration answer connects security to the automation covered in Chapter 12. Workflows, powered by AutomationEngine, react to platform events — including security findings — and can:

  • Create a ServiceNow, Jira, or other ITSM ticket with the finding's context attached
  • Post to a Slack or Microsoft Teams channel for the owning team
  • Call a webhook into a bespoke internal system
  • Trigger a remediation pipeline

The design guidance mirrors alerting profiles (Chapter 8): route by ownership and severity, not by broadcasting everything to one channel. A critical, internet-facing, actively attacked finding should page; a low-severity finding in a development namespace should become a backlog item. Routing everything identically guarantees that everything is ignored equally.


The End-to-End Chain

Putting the chapter together:

  1. Detect — Runtime Vulnerability Analytics finds third-party and code-level vulnerabilities from what is actually running (17.2, 17.3).
  2. Prioritize — the Davis Security Score reduces CVSS pessimism using exposure and data reachability; the Security Advisor names the highest-leverage fixes (17.2).
  3. Protect — Runtime Application Protection blocks exploitation attempts in real time while remediation is in progress (17.3).
  4. Investigate — Security Investigator answers what happened, using logs, traces, and metrics in Grail (17.4).
  5. Route — Workflows create the ticket or notification in the tool the organization already uses (17.4).
  6. Verify — the finding resolves, and reopening is monitored so a regression is caught.

That sequence is the strongest one-paragraph answer to any broad Security question on the Associate exam.

Loading diagram...
The Security Lifecycle: Detect, Prioritize, Protect, Investigate, Route, Verify
Test Your Knowledge

A vulnerability was marked resolved after a patch, but three weeks later it reappears as open with no new code committed. What is the most likely explanation?

A
B
C
D
Test Your Knowledge

A security manager proposes muting every finding scored below 7.0 so the vulnerability dashboard shows only critical and high items. What is the correct assessment of this proposal?

A
B
C
D
Test Your Knowledge

An analyst must determine whether a detected vulnerability was actually exploited and what the attacker accessed, pivoting between authentication logs, the traces of suspicious requests, and traffic volume metrics. Which Dynatrace capability is designed for this?

A
B
C
D
Congratulations!

You've completed this section

Continue exploring other exams