Vulnerability evaluation

See below for the mechanism that Dynatrace Application Security uses to generate third-party vulnerabilities and code-level vulnerabilities.

Third-party vulnerabilities

To detect third-party vulnerabilities in your environment, Application Security evaluates software components (libraries) and runtime components (for example, Kubernetes packages).

  • Libraries are reported by OneAgent when a process is loading them. Therefore, only vulnerabilities in libraries that are in use will be reported, thus reducing vulnerability noise. All processes are constantly checked for new library loads.

  • Kubernetes packages are runtime components used by the Kubernetes cluster. They are reported by OneAgent once the component is in use on a node.
    Examples of Kubernetes packages that Dynatrace tracks and scans for vulnerabilities:

    • On the control plane node:
      • kube-apiserver
      • etcd
      • kube-scheduler
      • kube-controller-manager
      • cloud-controller-manager
    • On the worker node:
      • kubelet
      • kubeproxy

Application Security checks the name and version of the vulnerable software and runtime component.

It does not check:

  • Configurations
  • Runtime information
  • Operating systems

As soon as the vulnerable software or runtime component is used by your application, a vulnerability is issued.

Topology changes

Once Dynatrace finds a new third-party vulnerability, it regularly checks for topology changes (for example, when a new reachable data source is involved).

Third-party vulnerability feeds

Depending on the vulnerable component, Dynatrace uses the following feeds:

  • Snyk for

    • Software components (libraries)
    • Runtime components in Kubernetes

  • NVD for runtime components in

    • .NET runtime
    • Java runtime
    • Node.js runtime

Feeds are checked for updates every five minutes. If there's a new feed available, the information is pushed to the Dynatrace Cluster via Cloud Control/Mission Control. Updated vulnerability feeds are imported into the Dynatrace Cluster within two hours.

Based on the existent vulnerability feeds, Dynatrace searches for new vulnerabilities in your environment every minute.

For vulnerability feed problems, see The feed import isn't working.

Risk assessment

To determine external exposure and affected data assets, Dynatrace considers the following:

  • Sources: To calculate exposure, Dynatrace analyzes whether incoming web request services and web service calls from the last day come from a public IP address.
  • Entities: A vulnerable software component is linked to the process of the reporting component, and the running services in that process group are used to calculate the exposure and whether reachable data assets are affected.
  • Dependencies: To see if data assets are reachable, Dynatrace investigates related services and services that are directly called by those related services. If one of those services is a database, a reachable data asset is affected.

Resolution

A third-party vulnerability is closed automatically when the root cause (for example, loading a vulnerable library) is no longer present. When no process group has been reporting any vulnerable components, such as libraries for more than two hours, the vulnerability is marked as Resolved. There are several reasons why this can happen:

  • The vulnerability was fixed in the code
  • The vulnerable component was upgraded or removed
  • The vulnerable component is no longer used by the application
  • The application hasn't received any traffic after a restart, therefore the vulnerable component hasn't been loaded (is inactive)
  • The affected process has been stopped

As long as the affected process is down, a vulnerability isn't considered relevant or impacting the environment. When the process is up again, Dynatrace checks on it immediately and, if the process is affected, the vulnerability is reopened.

Code-level vulnerabilities

Code-level vulnerabilities are identified based on data flows through the application. To gather these insights, OneAgent evaluates all input data that is processed by the application and identifies where user-generated inputs can be used to exploit a vulnerability in the code.

Risk assessment

The risk of a vulnerability is Critical. Additionally, for every code-level vulnerability, all entities related to the affected process group are continuously analyzed. As a result, the code-level vulnerability gets additional information about

  • Public internet exposure (indicates if there are any affected process group instances reachable from the public internet)
  • Reachable data assets affected (indicates if there's any database connected to the affected process group instance)

Resolution

A code-level vulnerability is closed automatically if the vulnerable process has been restarted and OneAgent can't detect any more data flows that can lead to the vulnerability. There are several reasons why this can happen:

  • The root cause (the vulnerable code) has been removed
  • The process hasn't received any traffic
  • There are mitigations outside the application
  • The affected process has been stopped

Frequently asked questions