See below for answers to some of the most frequently asked questions about Dynatrace Application Security, grouped by topics.
For troubleshooting articles related to Application Security, visit Dynatrace Community.
With Dynatrace Application Security, you can not only identify and monitor vulnerabilities in applications (third-party libraries, application runtimes, custom code) in your production and pre-production environments, but also detect and block attacks on your applications automatically and in real time.
To get started
What should I consider before enabling Application Security? Can it impact anything?
When you enable Application Security:
Does Application Security perform a scheduled job? What's the scheduled time interval? Can I manually start a security scan after deploying our changes in the environment?
There are no scheduled scans. Once you enable any Dynatrace Application Security functionality, your environment is automatically monitored for the selected functionality continuously and in real time.
Does the Snyk container scan detect vulnerabilities in libraries? In the DevSecOps Lifecycle Coverage with Snyk app, what are the differences between the vulnerabilities detected in container images by Snyk and the ones detected by Runtime Vulnerability Analytics?
DevSecOps Lifecycle Coverage with Snyk monitors your container workload devtime and runtime coverage. It doesn't detect vulnerabilities.
To restrict specific users to view-only access, so they can view but not manage vulnerabilities, see Fine-tune permissions.
Will Dynatrace resolve vulnerabilities or do I need to take any action to fix them?
Dynatrace Application Security does not resolve vulnerabilities. It identifies and monitors vulnerabilities in applications in your production and pre-production environments, and it helps you determine the root cause by providing rich context and information that helps you take the appropriate actions. For more information about capabilities, see
Once the root cause is gone, the vulnerability is automatically resolved. For more information about vulnerability resolution, see:
The rich and precise context and details provided on the vulnerabilities pages help you identify and understand vulnerabilities, prioritize them by risk, and automatically monitor and alert on newly discovered vulnerabilities. Based on this information, you can determine what actions are needed to fix the vulnerabilities.
For example, for third-party vulnerabilities, you can
I removed the vulnerable component, but the vulnerability still shows as open. Why?
A vulnerability is marked as Resolved
when no process group or Kubernetes node has been reporting any vulnerable components for more than two hours.
A vulnerability is still reported if it's still present in other management zones. To see the affected process groups, select All
in the management zone filter.
No. A vulnerability is resolved if there are no longer any affected entities.
After enabling Runtime Vulnerability Analytics, 19 critical vulnerabilities were found. Now they are down to three without any mitigation from our side. Why are some vulnerabilities resolved without any mitigation?
A vulnerability is resolved automatically if the root cause is no longer present. To learn more, see Third-party vulnerability resolution/Code-level vulnerability resolution.
A vulnerability keeps being resolved and reopened when a process using the vulnerable library isn't running all the time:
When the process is terminated, the vulnerability is resolved.
When the process is restarted, the vulnerability is reopened.
For details about the reasons why vulnerabilities are resolved and reopened, see Resolution.
To determine which processes are affected, access the remediation tracking for processes.
Management zone information is not directly attached to a vulnerability. It derives from the vulnerable entities that are affected by the respective vulnerability: a process in a management zone that uses a vulnerable library causes a third-party vulnerability in the respective management zone.
A vulnerability is resolved if there are no vulnerable entities anymore. In the vulnerability list, all resolved vulnerabilities displayed are not filterable by management zone anymore, as that information is not attached to them.
For resolved vulnerabilities, I would like to examine resolved process groups to understand which entities were previously affected, but there are zero resolved process groups in my management zone. Why?
On the Vulnerabilities pages, in the Process group overview section, if there are zero resolved process groups displayed for a resolved vulnerability in your management zone, it means that none of the entities that were previously affected and resolved are in that management zone. To find the respective entities, switch the management zone filter to All
.
See below the restart requirements by functionality.
Third-party vulnerabilities: No restart is required.
Code-level vulnerabilities: An application process restart is required in the following cases:
Attacks: An application process restart is required in the following cases:
OneAgent version 1.279+
See How can I know if information about vulnerable functions is outdated and what can I do about it?.
You can configure Dynatrace to send notifications for vulnerabilities only in two cases:
To configure Dynatrace to send notifications on your desired channels, you can
Set up notifications for Vulnerability (re)opened (alerts when vulnerability is reopened) and New Management zone affected (alerts whenever a new process group in a management zone is affected by the vulnerability)
Latest Dynatrace Set up a workflow to create and automate notifications, allowing you to control this aspect more granularly. For examples of how to set up a workflow, see Workflows use cases.
If you think a vulnerability or an entity isn't relevant or is a false positive, you can mute (silence) it.
For instructions, see
We have configured security notifications through email, but every day we receive notifications for the same vulnerability ID, with the same process group, entity name, and entity link. We have other vulnerabilities detected, but no extra notifications are sent. Why do we keep receiving notifications for the same vulnerability?
A process that does not run all the time might be using a vulnerable library. For details, see Why do some vulnerabilities keep being resolved and reopened?. To stop receiving notifications for this vulnerability, you can
Can I export a report with the vulnerability information so I can share it with developers?
There are several ways to share vulnerability information:
With the Dynatrace API, you can, for example, retrieve all security problems detected in your applications or the vulnerable functions of a security problem.
With Data Explorer, you can share your metric results and export them to a CSV file.
With notification alerts, you can keep track of all the vulnerabilities in your environment.
Go to Security Overview. In the Host coverage section, select Monitored hosts to go to the Hosts page filtered by monitored hosts. For details, see Basic concepts: Host coverage and Application Security overview: Host coverage.
Create a monitoring rule that says Do not monitor
if the management zone does not equal <your-management-zone>
. After you add, edit, or remove a rule, allow up to 15 minutes for your changes to take effect.
For third-party vulnerabilities, you can create monitoring rules to exclude specific hosts, management zones, or processes from monitoring.
For code-level vulnerabilities, you can create monitoring rules to exclude specific process groups from monitoring.
No. The MUTE
state does not automatically transfer to its affected entities; there is no interdependence between the two when assessing this state.
On the third-party and code-level vulnerabilities list pages, does "Last update" refer to the last time when Dynatrace provided an update? How can I request an update for a vulnerability which was last updated two days ago?
Last update refers to the last time when a vulnerability had a status change. It does not refer to the last time when Dynatrace provided an update. For details, see FAQ: Can I manually start a security scan?.
In Third-Party Vulnerabilities, on the Third-party vulnerabilities list page, when I filter for resolved vulnerabilities over the last seven days, I get 3
vulnerabilities. When I use the metric query (builtin:security.securityProblem.resolved.new.global
) in Data Explorer, I get 25
. Why are there different values on the vulnerabilities page versus Data Explorer?
The vulnerability list shows the current state (the total count of vulnerabilities that are currently resolved), while using the metric query in Data Explorer shows the change over time.
For example, if two vulnerabilities are open and resolved several times over a period of time, the Data Explorer chart shows only one spike (which is the maximum over the given timeframe) while the vulnerabilities page shows two (because there are currently two resolved vulnerabilities).
To find out how many vulnerabilities were resolved in the given timeframe using the metric query
In Data Explorer, set the visualization type to Single value
.
Expand Settings and set Fold transformation to Value
.
This shows how many times the vulnerabilities were resolved during the selected timeframe.
There can be two reasons why values on these pages don't match:
In Third-Party Vulnerabilities, the number of affected entities (process groups or hosts) on the Third-party vulnerabilities page (in the Affected entities column for a specific vulnerability) may differ from the number of affected entities on the vulnerability details page for the following reasons:
On the Third-party vulnerabilities page:
Affected entities aren't filtered by management zone.
Calculations take place every 15 minutes.
On the vulnerability details page:
Affected entities are filtered by management zone.
Current data is considered.
In Third-Party Vulnerabilities, the assessment of risk factors (Public exploit
, Public internet exposure
, Reachable data assets
, Vulnerable functions in use
) in the infographic on the vulnerability details page and the Davis Security Score column on the Third-party vulnerabilities page may be different from the assessment of risk factors on the vulnerability details page (in the Vulnerability details section) for the following reason:
For the infographic on the vulnerability details page and the Davis Security Score column on the Third-party vulnerabilities page, calculations take place every 15 minutes For the Vulnerability details section on the vulnerability details page, current data is considered.
A vulnerability is an aggregation of all its affected entities in your environment; therefore, it can have different values (risk assessment and Davis Security Score) than its affected entities. For example, the risk score of an affected entity might be 8.0
, while the score of the aggregated vulnerability is 9.0
. At the same time, if at least one affected entity is exposed to the internet, the aggregated vulnerability is also exposed to the internet.
You have the same vulnerabilities in two environments only if all of the following are the same in both environments:
Runtime Vulnerability Analytics focuses on the runtime aspect, aiming to provide a prioritized list of vulnerabilities that are relevant to your running environments. For this purpose, Dynatrace only reports libraries that are actively used.
On the remediation tracking pages for process groups and processes affected by a vulnerability, you can see where the software component has been loaded from.
This feature is only displayed for vulnerable Java and .NET software components.
Note that to display the origin of .NET software components, the minimum OneAgent version required is OneAgent version 1.301+.
Example:
For information on how to navigate there, see Remediation tracking.
If the Snyk feed provides information about the vulnerable function, and OneAgent monitoring for Java vulnerable functions is enabled, OneAgent determines whether the vulnerable function is in use.
If the Snyk feed provides information about the vulnerable function, but the OneAgent feature is disabled, the number of vulnerable functions is displayed as Not available.
There are two cases when information about vulnerable functions is not available:
Once you enable Third-party Vulnerability Analytics, it will take some time (one hour at the most) until data about vulnerable functions is displayed.
OneAgent monitoring for Java vulnerable functions is disabled. To enable it, see Enable OneAgent monitoring for Java vulnerable functions.
The OneAgent feature must be enabled for all processes affected by the vulnerability. For instructions on how to enable OneAgent monitoring, see Enable OneAgent monitoring for Java vulnerable functions.
No vulnerable functions of the vulnerability are contained in the release version of the third-party libraries (software components) in use.
No vulnerable functions are provided by the Snyk feed.
You need to restart the processes affected by the vulnerability for updated information. For details, see FAQ: How can I know if information about vulnerable functions is outdated and what can I do about it?.
If you see the Restart required notification on the details page of a vulnerability, follow the steps below to determine which processes you need to restart:
Vulnerable functions: Restart required
.Example result:
After a process restart, it takes about a minute for the updated information to be displayed.
This feature only works if OneAgent monitoring for Java vulnerable functions is enabled.
If you followed the instructions to identify the process and restarted it, and the process still requires a restart (the same Restart required notification shows up, and the information about vulnerable functions is unchanged), this can happen in Kubernetes deployments if there's no persistent storage.
To fix this issue, add persistent storage by mounting file storage that isn't deleted when restarting your pods.
OneAgent version 1.279+
If new information about a vulnerability's vulnerable functions is available, a process restart is required so that OneAgent can pick up and use the new data. In this case, a Restart required notification or symbol is displayed on
A vulnerability's details page (in Vulnerability details > Vulnerable functions)
The process groups overview related to a vulnerability (in Details > Risk assessment)
The process list related to a vulnerability (in Vulnerable functions and Details).
Why don't some vulnerabilities contain a link to Snyk, even though I can find the same CVE in Snyk?
To fetch data about vulnerabilities, Dynatrace Application Security uses either Snyk or NVD, depending on the vulnerable component.
A vulnerability with a CVE that is listed in Snyk but that doesn't have any Snyk-related information in Dynatrace is using the NVD feed. For more information, see Third-party vulnerability feeds.
Selecting Block attack
for an attack doesn't automatically block the respective attack; it takes you to the Settings page where you can create a monitoring rule to block that attack in the future. Dynatrace is configured to block future exploit situations, not the current ones.
The request (thread) with the exploit throws an exception in the running code. All other users who aren't attacking are unaffected.
Dynatrace detects when a user-supplied attack payload finds its way to a line of code that uses an insecure way of
The vulnerability is identified with or without an attack. If the data sent by the client includes characteristics of an attack that reaches this line of code, it's deemed an exploit, and Dynatrace alerts or blocks it.
In Runtime Application Protection, to determine an attacker's IP, Dynatrace verifies
Specific HTTP headers, such as X-Client-IP
or X-Forwarded-For
.
For a complete list, see the default header list (before modifying any client IP headers) in Settings > Web and mobile monitoring > IP determination.
The client IP of the socket connection (if the HTTP headers mentioned above aren't available).
For details, see Client IP address detection.
Early Adopter
Exploitation Risk Score (ERS) is a dynamic, weighted score that leverages the Davis Security Score (DSS) of each vulnerability and the actual number of vulnerabilities per risk level. ERS represents the likelihood of a potential attacker exploiting open vulnerabilities from the filtered scope. You can examine the vulnerability ERS using the Threat exposure template for Dashboards.
Higher scores represent higher risk. Scores above 90 involve critical vulnerabilities.
Open third-party and code-level vulnerabilities are stored as long as they are open, regardless of the timeframe.
The storage time for resolved third-party and code-level vulnerabilities depends on when vulnerabilities are resolved:
Examples:
Attacks are stored for approximately 550 days.
In Security Overview, go to the Host coverage section for third-party and code-level vulnerabilities and select Monitored hosts. The resulting list of hosts are the hosts in your environment which consume DPS/ASUs. For more information, see Host coverage.
For an overview of how to use compliance findings, see Stay compliant with Security Posture Management.
For guidelines on how to increase compliance, see Stay compliant with Security Posture Management.
For instructions, see Improve coverage.
Resources on your system are assessed as Failed
(not compliant) according to rules specified in the supported standards.
Maintaining your security posture is fundamental to your overall security strategy. Think of it as basic security hygiene—without it, all other security measures you implement will be significantly less effective. On the compliance side, not addressing these findings means you won't be able to identify, assess, and fix potential issues that could lead to audit failures.
Manually handling the numerous checks required for audits quickly becomes an overwhelming task, consuming countless hours. With our Security Posture Management solution, this entire process is automated, ensuring both security and compliance are effectively managed.
Ignoring compliance issues presents potential exposure risk or compliance failure risk.
For guidelines on how to fix findings, see Stay compliant with Security Posture Management.
For a list of supported versions and distributions, see Supported compliance standards and technologies.
Running Security Posture Management on Kubernetes is entirely independent of OneAgent and thus independent of the Monitoring modes. Analyzed data originates from the Kubernetes API Server and the Kubernetes Node Configuration Collector via ActiveGate. Therefore, you can use Security Posture Management with Kubernetes Platform Monitoring, where OneAgent isn't deployed.