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:
- To detect and monitor third-party vulnerabilities, enable third-party vulnerability detection.
- To detect and monitor code-level vulnerabilities, enable code-level vulnerability detection.
- To detect and monitor attacks on vulnerabilities, enable Runtime Application Protection.
Where can I see how vulnerable my application is?
Once you have enabled any of the above functionalities, sign in to Dynatrace and look for Application Security in the Dynatrace menu. From there, you can view the list of vulnerabilities and/or attacks in your environment, grab detailed information, filter for what you're interested in, set up notification alerts, query metrics, set up monitoring rules, get insights about recommended fixes, prioritize issues, track remediation, and much more.
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 Application Security units (ASUs).
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 the data explorer?
On the Third-party vulnerabilities list, 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 the 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.
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 With Security data analysis and reporting, you can accomplish various reporting tasks, such as
Generating vulnerability reports
Communicating findings to owning teams
Sharing results with stakeholders
-
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 Runtime Vulnerability Analytics: 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 third-party vulnerability details or code-level vulnerability details pages help you identify and understand vulnerabilities, prioritize them by risk, and automatically monitor and alert for 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 use the recommended fixes from Davis Security Advisor to upgrade to a non-vulnerable version of the vulnerable component.
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 active?
I removed the vulnerable component, but the vulnerability still shows as active. 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.
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 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.
- To learn how Dynatrace determines exposure and affected data assets for the remediation tracking of process groups that are related to a vulnerability, see Track remediation progress for process groups.
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 Troubleshooting.
How can I see which hosts are covered by Application Security?
In Dynatrace, go to Security overview. In the Host coverage section, select Monitored hosts to go to the Hosts page filtered by monitored hosts. For more information, see 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.
Why are old resolved vulnerabilities not showing up anymore?
Why aren't resolved vulnerabilities with an older ID showing up in the vulnerabilities list even when I use a very large timeframe filter?
Resolved vulnerabilities have a lifespan of 365 days, after which they are deleted.
What is Exploitation Risk Score?
Latest Dynatrace
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.