How vulnerabilities are evaluated

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

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

The third-party vulnerability feeds (SNYK and NVD) 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 Troubleshoot Application Security: 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.

Code-level vulnerabilities

Code-level vulnerabilities are identified based on the code-level insights and transaction analysis that Application Protection provides.

Received attacks are used to create code-level vulnerabilities. When an attack is detected, Dynatrace checks if the code-level vulnerability is already known and updates it. If it's not known, a new code-level vulnerability is created.

Risk assessment

The risk score of a vulnerability is always 10, and the risk is always 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)

Muting

You can mute (silence) code-level vulnerabilities if

• You don't consider them important
• The code has been fixed

Resolution

A code-level vulnerability is automatically resolved if there was no new attack candidate for the vulnerability within the last year.