Application Security FAQ
See below for answers to some of the most frequently asked questions about Dynatrace Application Security.
How can I detect security risks?
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
- Activate and enable Application Security.
Select any of the options below:
- Latest Dynatrace To detect, prioritize, and monitor third-party, code-level, and runtime vulnerabilities, enable Runtime Vulnerability Analytics, then open Vulnerabilities
.
- To detect and monitor third-party vulnerabilities, enable third-party vulnerability detection, then go to Third-Party Vulnerabilities.
- To detect and monitor code-level vulnerabilities, enable code-level vulnerability detection, then go to Code-Level Vulnerabilities.
- For a unified view of third-party and code-level vulnerabilities and information about host coverage, enable Runtime Vulnerability Analytics, then go to Security Overview.
- To detect and monitor attacks on vulnerabilities, enable Runtime Application Protection, then go to Attacks.
What's the impact of enabling Application Security?
What should I consider before enabling Application Security? Can it impact anything?
When you enable Application Security:
Expect some slight overhead, depending on your applications (it should be negligible in most cases).
- Be aware that Application Security consumes GiB-hours if you're using the Dynatrace Platform Subscription (DPS) licensing model, or Application Security units (ASUs) if you're using the Dynatrace classic licensing.
Can I manually start a security scan?
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.
Why are there different values on the vulnerabilities page versus Data Explorer?
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.
Why are there different values on the Third-party vulnerabilities and vulnerability details pages?
There can be two reasons why values on these pages don't match:
Different number of affected entities
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.
-
Different risk factors
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.
How can I export and share a vulnerability report?
Can I export a report with the vulnerability information so I can share it with developers?
There are several ways to share vulnerability information:
- Latest Dynatrace In Vulnerabilities, you can share results of your findings by downloading them as CSV.
- Latest Dynatrace Security data on Grail enables security data query, aggregation, visualization, and reporting on multiple levels. For details, see Security data analysis and reporting and DQL examples for security data.
-
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.
Does Dynatrace resolve vulnerabilities?
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
- Latest Dynatrace Vulnerabilities: Capabilities
Once the root cause is gone, the vulnerability is automatically resolved. For more information about vulnerability resolution, see:
How do I fix detected vulnerabilities?
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
- Latest Dynatrace Filter by DSA fixes in Vulnerabilities .
- Latest Dynatrace Set up tracking links and follow up with their remediation progress in Vulnerabilities .
- Use the recommended fixes from Davis Security Advisor to upgrade to a non-vulnerable version of the vulnerable component
- Set up tracking links for affected entities and follow up with their remediation progress
How can I stop receiving notifications for an irrelevant or false-positive vulnerability or entity?
If you think a vulnerability or an entity isn't relevant or is a false positive, you can mute (silence) it.
For instructions, see
- Latest Dynatrace Change the vulnerability and remediation entity status in Vulnerabilities .
Where can I see the origin of a vulnerable library?
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 software components.
Example:
For information on how to navigate there, see Remediation tracking.
Why is a fixed vulnerability still showing as open?
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.
Why are some vulnerabilities resolved without any mitigation?
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.
In the case of .NET framework runtime vulnerabilities, support has been halted due to an elevated false positive rate. All open .NET framework runtime vulnerabilities have been automatically closed. .NET core runtime vulnerabilities and .NET library vulnerabilities are not affected.
Why do resolved vulnerabilities show up in every management zone?
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.
How can I limit Application Security monitoring to a specific management zone?
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.
How can I give someone view-only access to vulnerabilities?
To restrict specific users to view-only access, so they can view but not manage vulnerabilities, see Fine-tune permissions.
How does Davis Security Advisor calculate recommended fixes?
Basis for calculation
To calculate recommended fixes, Davis Security Advisor takes into consideration all third-party vulnerabilities that are currently open and not muted; resolved or muted vulnerabilities aren't taken into account. Fixes are tailored to your environment and ranked based on how much they improve the overall security of your environment.
Grouping
Because every third-party vulnerability is triggered by a vulnerable library, those libraries are used for grouping. When calculating the advice, Davis Security Advisor ignores the specific version of the library. All shown libraries contain known vulnerabilities and should be updated to the latest version.
Advice ranking
Advice is ranked based on the severity of the third-party vulnerabilities. Advice regarding a critical vulnerability, for example, is ranked higher than advice for a high-severity vulnerability.
The severity of a vulnerability is calculated based on Davis Security Score (DSS), so you can focus on fixing vulnerabilities that are relevant in your environment, instead of on those that have only a theoretical impact.
Why is Davis Security Score better than CVSS?
Davis Security Score (DSS) is an enhanced risk-calculation score based on the industry-standard Common Vulnerability Scoring System (CVSS). Davis AI is designed to provide a more precise risk-assessment score by considering additional parameters like public internet exposure, public exploit availability, and whether or not data assets are reachable from an affected entity.
Virtually all security products use the CVSS Base Score to set the severity of security vulnerabilities. CVSS was designed to be risk-averse, which means that, for any given vulnerability, the assigned score assumes the worst-case scenario. The CVSS specification does allow for some modifications based on environmental influences, but this is usually not factored into the risk score calculation, which leads to many high or critical vulnerability scores that the user needs to handle.
DSS is more accurate: Davis doesn't assume the worst-case scenario. Instead, Davis adapts the characteristics of the vulnerability to your particular environment, taking into consideration its structure and topology, and advises you as to which elements are prone to errors and how to handle security issues. With Davis AI, you can find out if the affected entity is reachable from the Internet and if there is any data storage in reach of an affected entity.
DSS makes you more efficient: By including additional parameters in its analysis, Davis is designed to leverage data to more precisely calculate the security score and predict the potential risk of a vulnerability to your environment. By reducing the score of vulnerabilities that are considered less relevant for your environment, you gain time to focus on the most critical issues and fix them faster.
How does Davis Security Score calculate the vulnerability score?
-
Starts from the CVSS base.
Calculation starts from the base CVSS Score, and takes into consideration metrics pertaining to
- Public internet exposure: Attack vector (AV)
- Reachable data assets: Confidentiality (C) and Integrity (I)
The current supported CVSS version standard is v3. Some older vulnerabilities still use CVSS v2, which is deprecated. In this case, the Davis Security Score can't be assessed.
-
Adds context to public internet exposure.
To influence the security score of a third-party vulnerability based on the public internet exposure, Davis uses the Modified Attack Vector (MAV) metric. This metric reflects the context by which vulnerability exploitation is possible.
If the original AV value shows exploitation is possible via network access, but, based on the topology information extracted from your environment, the service isn't actually exposed, Davis lowers the MAV value.
In all other cases, the MAV value doesn't differ from the original AV value.
-
Adds context to reachable data assets.
To influence the security score of a third-party vulnerability based on reachable data assets, Davis uses the Modified Confidentiality (MC) and Modified Integrity (MI) metrics. These metrics reflect the actual accessibility of a reachable data asset to an affected service.
If the original C and I values show that data exposure or manipulation are possible, but, based on Davis' evaluation, there aren't any reachable data assets accessible by the affected service, Davis lowers the corresponding MC and MI values.
In all other cases, the MC and MI values don't differ from the original C and I values.
-
Calculates the final score, based on the previous results.
Davis modifies the scores on the service level. If a vulnerability has more than one affected service, the highest score is used.
DSS is never higher than the base CVSS. The values for public internet exposure and reachable data assets can only lower the score or leave it unchanged.
Example calculation in Vulnerabilities , on the details page of a vulnerability:
DSS risk levels
The DSS scale ranges between 0.1 (lowest risk) and 10.0 (most critical risk):
Low risk: Vulnerabilities ranging between 0.1 and 3.9- Medium risk: Vulnerabilities ranging between 4.0 and 6.9
High risk: Vulnerabilities ranging between 7.0 and 8.9
Critical risk: Vulnerabilities ranging between 9.0 and 10.0
How is the assessment of risk factors calculated?
- To learn how Dynatrace determines exposure and affected data assets for third-party vulnerabilities, see Third-party vulnerabilities: Risk assessment.
- To learn how Dynatrace determines exposure and affected data assets for code-level vulnerabilities, see Code-level vulnerabilities: Risk assessment.
- To learn how the risk factors are taken into account for the final vulnerability score, see Calculation process.
- Latest Dynatrace For information on Davis Security Score calculations on Grail-powered apps, see Calculation differences.
How is public internet exposure determined?
To determine public internet exposure, Dynatrace:
Evaluates all the IP addresses detected in the last hour.
Discards the private IP ranges.
Groups the remaining IPs by subnet.
As soon as the respective subnets reach a certain (low) threshold, public internet exposure is triggered.
How is an attacker's IP determined?
In Runtime Application Protection, to determine an attacker's IP, Dynatrace verifies
-
Specific HTTP headers, such as
X-Client-IPorX-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.
Why is there a "Restart required" notification on some Application Security pages?
OneAgent version 1.279+
See How can I know if information about vulnerable functions is outdated and what can I do about it?.
How can I know if information about vulnerable functions is outdated and what can I do about it?
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 is there no information on vulnerable functions?
There are two cases when information about vulnerable functions is not available:
If no vulnerable function information is provided by Snyk.
For runtime vulnerabilities, which are based on the NVD feed.
How are vulnerable functions determined?
-
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.
Why is there no data available for vulnerable functions?
-
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?.
How do I know which processes to restart?
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:
- On the Process group overview card, select View all process groups.
- Filter by
Vulnerable functions: Restart required. - For each of the resulting process groups, select Details, then select the link provided in the Restart required notification to navigate to the list of processes that require a restart.
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.
Why does my process still need to be restarted after I already restarted it?
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.
Why do we keep receiving notifications for the same vulnerability?
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 the vulnerable library. For details, see Vulnerability status fluctuations. To stop receiving notifications for this vulnerability, you can
- Exclude the respective process from Application Security monitoring by setting up a third-party monitoring rule/code-level monitoring rule.
- Mute the third-party vulnerability/mute the code-level vulnerability.
Why is the Snyk link missing for some vulnerabilities?
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.
Does the Snyk container scan detect vulnerabilities in libraries?
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?
Latest Dynatrace
DevSecOps Lifecycle Coverage with Snyk monitors your container workload devtime and runtime coverage. It doesn't detect vulnerabilities.
- A container image is considered covered if it has been scanned by Snyk. The coverage results are displayed in DevSecOps Lifecycle Coverage with Snyk, while the results of the Snyk scans are displayed on the Snyk side.
- A running container is considered covered if all of its processes are monitored by Application Security. The coverage results are displayed in DevSecOps Lifecycle Coverage with Snyk, while the results of Application Security monitoring are displayed on the Third-party vulnerabilities page.
How do I know if the DevSecOps Lifecycle Coverage with Snyk app is working?
Latest Dynatrace
The spinning radar on top of the DevSecOps Lifecycle Coverage with Snyk pages lets you know that
Application Security is actively monitoring the coverage status of your running containers.
Container image data from Snyk is available and recent.
When coverage analysis fails, the radar stops spinning and you are informed of the problem. For potential reasons, see Radar stopped on DevSecOps Lifecycle Coverage with Snyk app.
How can I see which hosts are covered by Application Security?
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.
Why is my vulnerability still open if there's no affected process group anymore?
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.
What is Exploitation Risk Score?
Latest Dynatrace
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.
How ERS is calculated
DSS average and vulnerability counts are calculated per risk level (critical, high, etc.).
A weighted function is applied per risk level to adjust the averages to the respective vulnerability counts.
All scores are aggregated in an iterative manner starting with the highest risk level to derive a single score out of 100.
Higher scores represent higher risk. Scores above 90 involve critical vulnerabilities.
ERS examples
For one critical vulnerability with a score of 9.1 and 100 low vulnerabilities with an average score of 2.2, the resulting Exploitation Risk Score is 90.
For 100 low vulnerabilities with an average score of 2.2, the resulting Exploitation Risk Score is 5,7.
For 100 critical vulnerabilities with an average score of 9.1, the resulting Exploitation Risk Score is 91.
Does a vulnerability have the same values (risk assessment and Davis Security Score) as its affected entities?
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.
Can a vulnerability be resolved while there are still affected entities?
No. A vulnerability is resolved if there are no longer any affected entities.
If a vulnerability is muted, are the affected entities muted as well?
No. The MUTE state does not automatically transfer to its affected entities; there is no interdependence between the two when assessing this state.
What's the data retention period for vulnerabilities, events, and attacks?
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:
If a vulnerability is resolved before 365 days since it was first opened, it's deleted after 365 days.
If a vulnerability is resolved after 365 days since it was first opened, it's deleted on its closest anniversary of the date when it was first opened.
Examples:
First opened First resolved Reopened Resolved again Delete date 2022-05-12 2023-05-06 2023-05-13 2022-05-12 2023-08-06 2024-05-13 2022-05-12 2023-08-06 2024-01-01 2024-02-08 2024-05-13
Events
Vulnerability evolution events are stored for 365 days and can only be queried up to the timestamp of when the vulnerability was first detected.
- Latest Dynatrace Security events are stored for five years.
Attacks
Attacks are stored for approximately 550 days.
How can I create dashboards for vulnerabilities?
- Latest Dynatrace In Vulnerabilities, you can create reports or open the data from the vulnerabilities table in Dashboards based on your selected filters.
- Latest Dynatrace Security data on Grail allows you to create reports and visualize, save, and share data in Notebooks or Dashboards. For details, see Security data analysis and reporting and DQL examples for security data.
- You can chart Application Security metrics and pin them to your dashboard. For instructions, see Add metric to dashboard.
How can I exclude hosts, management zones, process groups, or processes from monitoring with Application Security?
-
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.
What does "last update" on vulnerabilities list pages refer to?
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?.
What are status changes
How can I check which hosts consume DPS/ASUs and how much they consume?
Find the hosts consuming DPS/ASUs
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.
Find out how much your hosts consume
- If you're using Dynatrace Platform Subscription, see Analyze consumption via built-in usage metrics.
- If you're using Dynatrace classic licensing, see How capabilities affect monitoring consumption.
Why do some vulnerabilities keep being resolved and reopened?
If a vulnerability keeps being resolved and reopened, even if the third-party application containing the vulnerability has been upgraded, it might be that a process is still using that vulnerable library, and that process isn't running all the time.
When the process is not in use, the vulnerability is resolved. When it starts running again, 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.
Why am I seeing different vulnerabilities in production vs non-production environment?
You have the same vulnerabilities in two environments only if all of the following are the same in both environments:
Deployment (including the OneAgent version)
Settings
Application usage
Traffic