Monitoring rules - Third-party Vulnerability Analytics
- How-to guide
To include or exclude specific entities from being monitored by Runtime Vulnerability Analytics, you can set up fine-grained monitoring rules for third-party vulnerabilities based on different criteria.
If you define custom monitoring rules, the global third-party vulnerability detection control mode applies to all entities that are not matched by a rule.
Monitoring criteria
There are currently two ways to set up monitoring rules:
-
Based on resource attributes and Kubernetes labels Recommended
- For details, see New monitoring rules.
-
Based on process group tag, host tag, and management zones
- For details, see Classic monitoring rules.
To start monitoring based on your rules, you need to activate the corresponding monitoring criteria. The two criteria cannot be in place at the same time. When one is activated, the other one is deactivated. You can switch between them at any time.
For environments created on Dynatrace version 1.313+, classic monitoring rules based on process group tag, host tag, and management zones aren't available; you can set up monitoring rules based on resource attributes and Kubernetes labels.
Activate the preferred monitoring criteria
To activate your preferred way to define monitoring
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics.
-
Make one of the following changes:
- To activate the new rules, turn on Enable new monitoring rules.
- To activate the classic rules, turn off Enable new monitoring rules.
Your setting will persist until you change it again.
For environments created on Dynatrace version 1.313+, new monitoring rules are activated by default (no action is required from your side).
New monitoring rules
Recommended
With the new monitoring rules, you can define which processes and Kubernetes nodes and hosts should be monitored.
-
Process rules are based on resource attributes.
-
Kubernetes node and host rules are based on Kubernetes labels.
Kubernetes‑related resource attributes (for example, k8s.cluster.uid) apply to process groups, not Kubernetes nodes. To include or exclude Kubernetes nodes or hosts from monitoring, you must define Kubernetes label rules. If you only configure resource attribute rules, Kubernetes nodes may continue to be monitored and generate usage even when the related process groups are excluded.
Define rules
You can define new monitoring rules through the Dynatrace web UI or the Settings API.
In Dynatrace
-
In Dynatrace, go to Settings > Application Security > New monitoring rules: Third-party.
-
In the Resource attribute monitoring rules (…) tab, select Add new rule.
-
Follow the on-screen instructions.
A condition's key and value fields are free text fields. On-screen suggestions aren't mandatory.
-
Select Preview matching process group instances to verify if the condition matches the expected processes.
All conditions of a rule must match for the rule to apply.
-
Select Save changes.
To start monitoring based on your preferred monitoring criterion, make sure it's activated.
You can edit, disable, enable, or remove rules at any time.
Via Settings API
You can read or modify the rules using the Settings API.
-
To view a monitoring rule, use the GET an object request. Set the following parameters:
schemaIds=builtin:appsec.third-party-vulnerability-rule-settingsscopes=tenant
Example JSON response
{"items": [{"objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACQ1YWYzOWNiZC0xM2I0LTNlZmItYTViYi1iYzljNTgyOTQxNze-71TeFdrerQ","value": {"enabled": true,"vulnerabilityDetectionControl": {"monitoringMode": "MONITORING_OFF"},"resourceAttributeConditions": [{"resourceAttributeKey": "dt.entity.host","matcher": "EQUALS","resourceAttributeValue": "HOST-ABD42981B3D483AC"}],"metadata": {"comment": ""}}},{"objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACQ4NDQ1OGRjNC1lM2Q2LTM2MGYtOWQyYy1lNmYwMTY1MzAwMza-71TeFdrerQ","value": {"enabled": false,"vulnerabilityDetectionControl": {"monitoringMode": "MONITORING_ON"},"resourceAttributeConditions": [{"resourceAttributeKey": "attribute_2","matcher": "EXISTS"}],"metadata": {"comment": ""}}},{"objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACRjNzk3M2I4YS1kYmFjLTMxMzAtYjdjMy0zYjYxNGMxOWU1NzK-71TeFdrerQ","value": {"enabled": false,"vulnerabilityDetectionControl": {"monitoringMode": "MONITORING_OFF"},"resourceAttributeConditions": [{"resourceAttributeKey": "my.app.name","matcher": "EQUALS","resourceAttributeValue": "cool-app"}],"metadata": {"comment": ""}}}],"totalCount": 3,"pageSize": 100} -
To modify a monitoring rule, use the POST an object request.
Example JSON body
[{"value": {"enabled": true,"vulnerabilityDetectionControl": {"monitoringMode": "MONITORING_OFF"},"resourceAttributeConditions": [{"resourceAttributeKey": "dt.entity.host","matcher": "EQUALS","resourceAttributeValue": "HOST-ABD42981B3D483AC"}],"metadata": { "comment": "" }},"schemaId": "builtin:appsec.third-party-vulnerability-rule-settings","scope": "tenant"},{"value": {"enabled": false,"vulnerabilityDetectionControl": { "monitoringMode": "MONITORING_ON" },"resourceAttributeConditions": [{"resourceAttributeKey": "attribute_2","matcher": "EXISTS"}],"metadata": { "comment": "" }},"schemaId": "builtin:appsec.third-party-vulnerability-rule-settings","scope": "tenant"},{"value": {"enabled": false,"vulnerabilityDetectionControl": {"monitoringMode": "MONITORING_OFF"},"resourceAttributeConditions": [{"resourceAttributeKey": "my.app.name","matcher": "EQUALS","resourceAttributeValue": "cool-app"}],"metadata": {"comment": ""}},"schemaId": "builtin:appsec.third-party-vulnerability-rule-settings","scope": "tenant"}]
Preview monitored hosts
You can easily verify which hosts are covered by your monitoring rules, regardless of whether the rules are currently enabled.
-
Go to Settings > Application Security > New monitoring rules: Third-party.
-
Select Show monitored hosts. This takes you to Hosts, filtered to display only the hosts covered by your rules.
-
Optional Use the timeframe selector to choose a period and view the hosts that were monitored during that time. Keep in mind that this doesn't confirm whether those hosts are still being actively monitored.
For the most accurate view of currently monitored hosts, select a shorter timeframe. For example, if a host was monitored 23 hours ago, only for one hour, and you select a 24-hour timeframe, the host will still appear in the list, even if it's no longer actively monitored.
Newly monitored hosts may take up to 10 minutes to appear in the preview.
Why use host preview?
- It works independently of monitoring rule activation: Hosts appear in the preview, regardless of whether rules are enabled.
- It helps validate rule scope: You can ensure your rule configuration covers the intended hosts.
- It supports rule optimization: Based on the preview, you can adjust the rules to ensure your configuration is effective before enforcement.
Monitoring rules evaluation
After you add, edit, or remove a rule, it can take up to 10 minutes for changes to take effect throughout the system. The configured monitoring rules are evaluated periodically (on internal worker runs) and on-demand (through calls to the REST API).
Exception: After an entity that was previously monitored is excluded from monitoring, it can take up to 70 minutes for changes to take effect throughout the system. For details, see How host coverage is calculated.
Regardless of the calling context, the rule evaluation stays the same: given a set of entities, the algorithm decides whether a specific entity should be monitored. The rules are processed in order until the first match.
- If a rule matches a specific entity, the configured mode (Monitor or Do not monitor) is used and subsequent rules aren't evaluated for this particular entity.
- If no rule matches a specific entity, the configured default mode (Monitor or Do not monitor) is used.
Classic monitoring rules
Classic monitoring rules are based on process group tag, host tag, and management zones.
Define rules
You can define classic monitoring rules through the Dynatrace web UI or the Settings API.
In Dynatrace
To add a new rule
-
Go to Settings > Application Security > Vulnerability Analytics > Monitoring rules: Third-party.
-
Select Add new rule to add a new rule.
-
Enter the requested information (mode, property, condition operator, and condition value).
The
Process tagproperty applies to process groups, not processes. -
Select Save changes.
You can edit, disable, enable, or remove rules at any time.
Via Settings API
You can read or modify the rules using the Settings API.
-
To view a monitoring rule, use the GET an object request. Set the following parameters:
schemaIds=builtin:appsec.rule-settingsscopes=tenant
Example JSON response
{"items": [{"objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkYTc4NjY0NGItZmVjNC0zNzliLWI0MWItNThmYzgzOWZmYWY5vu9U3hXa3q0","value": {"enabled": true,"mode": "MONITORING_OFF","property": "PROCESS_TAG","operator": "EQUALS","value": "super secret process"}},{"objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkNDhkZGYxNDMtYzc2Mi0zYzIwLWI1ODAtNTNhODEwOGZlMDBivu9U3hXa3q0","value": {"enabled": true,"mode": "MONITORING_ON","property": "HOST_TAG","operator": "NOT_EQUALS","value": "Test"}},{"objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkNmY1NjZkNmItYWMyNy0zOTg2LWE1OGItNTU2ZTI1NTE5NTcyvu9U3hXa3q0","value": {"enabled": false,"mode": "MONITORING_ON","property": "MANAGEMENT_ZONE","operator": "EQUALS","value": "Monitorme"}}],"totalCount": 3,"pageSize": 100} -
To modify a monitoring rule, use the POST an object request.
Example JSON body
[{"value": {"enabled": true,"mode": "MONITORING_ON","property": "HOST_TAG","operator": "EQUALS","value": "REST"},"scope": "tenant","schemaId": "builtin:appsec.rule-settings"},{"value": {"enabled": true,"mode": "MONITORING_OFF","property": "PROCESS_TAG","operator": "NOT_EQUALS","value": "Test-Process"},"scope": "tenant","schemaId": "builtin:appsec.rule-settings"}]
For Kubernetes environments, you need to add tags both on the host and on the Kubernetes node.
Preview monitored hosts
You can easily verify which hosts are covered by your monitoring rules, regardless of whether the rules are currently enabled.
-
Go to Settings > Application Security > Classic monitoring rules: Third-party.
-
Select Show monitored hosts. This takes you to Hosts, filtered to display only the hosts covered by your rules.
-
Optional Use the timeframe selector to choose a period and view the hosts that were monitored during that time. Keep in mind that this doesn't confirm whether those hosts are still being actively monitored.
For the most accurate view of currently monitored hosts, select a shorter timeframe. For example, if a host was monitored 23 hours ago, only for one hour, and you select a 24-hour timeframe, the host will still appear in the list, even if it's no longer actively monitored.
Newly monitored hosts may take up to 10 minutes to appear in the preview.
Why use host preview?
-
It works independently of monitoring rule activation: Hosts appear in the preview, regardless of whether rules are enabled.
-
It helps validate rule scope: You can ensure your rule configuration covers the intended hosts.
-
It supports rule optimization: Based on the preview, you can adjust the rules to ensure your configuration is effective before enforcement.
To transition from classic to new monitoring rules, open both previews side by side for a direct comparison. Once you've confirmed that the migration aligns with your expectations, you can confidently enable the new monitoring rules.
Monitoring rules evaluation
-
After you add, edit, or remove a rule, it can take up to 15 minutes for changes to take effect throughout the system. The configured monitoring rules are evaluated periodically (on internal worker runs) and on-demand (through calls to the REST API).
Regardless of the calling context, the rule evaluation stays the same: given a set of entities, the algorithm decides whether a specific entity should be monitored. The rules are processed in order until the first match. Note that each rule must be unique.
-
When you have a rule in place for a management zone or tag, and you add an entity to the same management zone or add the same tag to an entity, it can take up to 15 minutes until the change is reflected in your monitoring rule.
For example, if you have a
Do not monitor if host tag equals 'testsystem'rule, and you add the tagtestsystemto a host, it can take up to 15 minutes until the newly tagged host stops being monitored. -
If a rule matches a specific entity, the configured mode (
Monitor,Do not monitor) is used and subsequent rules are not evaluated for this particular entity. -
If no rule matches a specific entity, the global third-party vulnerability detection control mode is used.
Coverage impact
Monitoring rules directly influence host and process coverage. If a host or process group is excluded by a rule, it won't be monitored for vulnerabilities.
Latest Dynatrace To review how your monitoring rules affect overall coverage, see Assess coverage.
Use cases for new monitoring rules
Below are some common scenarios for defining monitoring rules for third-party vulnerabilities based on resource attributes and Kubernetes labels.
Monitor only the processes on specific hosts
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
-
Find the host on which you want to monitor processes (for example, via Hosts).
-
Copy the hostname (for example,
exchange.mycompany.local) from the overview. -
Add a new resource attribute monitoring rule:
-
Set Third-party vulnerability control to
Monitor. -
Select Add new condition and enter the following data:
-
Resource attribute key:
host.name -
Matcher:
equals -
Resource attribute value: hostname from step 3.
-
-
Check the preview to see if the condition matches the expected processes.
-
Save the rule.
-
Monitor only the Java processes on specific hosts
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
-
Find the host on which you want to monitor processes (for example, via Hosts).
-
Copy the hostname (for example,
exchange.mycompany.local) from the overview. -
Add a new resource attribute monitoring rule:
-
Set Third-party vulnerability control to
Monitor. -
To create a condition that matches the host, select Add new condition and enter the following data:
-
Resource attribute key:
host.name -
Matcher:
equals -
Resource attribute value: hostname from step 3.
-
-
To create a condition that matches the technology, select Add new condition and enter the following data:
-
Resource attribute key:
java.main.class -
Matcher:
exists
-
-
Check the preview to see if the conditions match the expected processes.
-
Save the rule.
-
Exclude .NET processes of specific hosts from monitoring
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Monitor.
-
Find the host on which you want to monitor processes (for example, via Hosts).
-
Copy the hostname (for example,
exchange.mycompany.local) from the overview. -
Add a new resource attribute monitoring rule:
-
Set Third-party vulnerability control to
Do not monitor. -
To create a condition that matches the host, select Add new condition and enter the following data:
-
Resource attribute key:
host.name -
Matcher:
equals -
Resource attribute value: hostname from step 3.
-
-
To create a condition that matches the technology, select Add new condition and enter the following data:
-
Resource attribute key:
dotnet.dll.file -
Matcher:
exists
-
-
Check the preview to see if the conditions match the expected processes.
-
Save the rule.
-
Monitor only processes with a custom resource attribute
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
-
Add a custom resource attributes (for example,
{"stage":"production"}) to your entities. -
Add a new resource attribute monitoring rule:
-
Set Third-party vulnerability control to
Monitor. -
Select Add new condition and enter the following data:
-
Resource attribute key: key of the custom resource attribute from step 2 (for example,
stage) -
Matcher:
equals -
Resource attribute value: value of the custom resource attribute from step 2 (for example,
production)
-
-
Check the preview to see if the condition matches the expected processes.
-
Save the rule.
-
Monitor only processes of a specific process group
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
-
Find the process group on which you want to monitor processes (for example, via the Technologies & Processes Classic app).
-
Copy the process group ID (for example,
PROCESS_GROUP-0123456789ABCDEF) from the URL. -
Add a new resource attribute monitoring rule:
-
Set Third-party vulnerability control to
Monitor. -
Select Add new condition and enter the following data:
-
Resource attribute key:
dt.entity.process_group -
Matcher:
equals -
Resource attribute value: ID of the process group from step 3.
-
-
Check the preview to see if the condition matches the expected processes.
-
Save the rule.
-
Monitor only processes running in a specific Kubernetes namespace
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
-
Add a new resource attribute monitoring rule:
-
Set Third-party vulnerability control to
Monitor. -
Select Add new condition and enter the following data:
-
Resource attribute key:
k8s.namespace.name -
Matcher:
equals -
Resource attribute value: namespace name that should be monitored
-
-
Check the preview to see if the condition matches the expected processes.
-
Save the rule.
-
Monitor only Kubernetes nodes and hosts running a Linux-based OS for Kubernetes vulnerabilities
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
-
Add a new Kubernetes monitoring rule:
-
Set Third-party vulnerability control to
Monitor. -
Select Add new condition and enter the following data:
-
Kubernetes label key:
kubernetes.io/os -
Matcher:
equals -
Kubernetes label value:
linux
-
-
Check the preview to see if the condition matches the expected Kubernetes nodes.
-
Save the rule.
-
Monitor only EC2 instances for Kubernetes vulnerabilities
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
-
Add a new Kubernetes monitoring rule:
-
Set Third-party vulnerability control to
Monitor. -
Select Add new condition and enter the following data:
-
Kubernetes label key:
kubernetes.io/hostname -
Matcher:
ends with -
Kubernetes label value:
.ec2.internal
-
-
Check the preview to see if the condition matches the expected Kubernetes nodes.
-
Save the rule.
-
Exclude ARM-based nodes from monitoring of Kubernetes vulnerabilities
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Monitor.
-
Add a new Kubernetes monitoring rule:
-
Set Third-party vulnerability control to
Do not monitor. -
Select Add new condition and enter the following data:
-
Kubernetes label key:
kubernetes.io/arch -
Matcher:
contains -
Kubernetes label value:
arm
-
-
Check the preview to see if the condition matches the expected Kubernetes nodes.
-
Save the rule.
-
Monitor all Java processes except the Java demo application process on the development hosts
-
In Dynatrace, go to Settings > Application Security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
-
Copy the fully qualified name (FQN) of the Java main class of your demo application (for example,
com.example.my.DemoMain). -
Find the development host on which you don't want to monitor the demo application process (for example, via
Infrastructure & Operations). -
Copy the hostname (for example,
exchange.mycompany.local) from the overview. -
Add a new resource attribute monitoring rule to exclude the demo application process on the development host:
-
Set Third-party vulnerability control to
Do not monitor. -
To create a condition that matches the development host, select Add new condition and enter the following data:
-
Resource attribute key:
host.name -
Matcher:
equals -
Resource attribute value: hostname from step 4.
-
-
To create a condition that matches the demo application process, select Add new condition and enter the following data:
-
Resource attribute key:
java.main.class -
Matcher:
equals -
Resource attribute value: main class from step 2.
-
-
Check the preview to see if the conditions match the expected processes.
-
Save the rule.
-
-
Add a new resource attribute monitoring rule to monitor all remaining Java processes:
-
Set Third-party vulnerability control to
Monitor. -
To create a condition that matches the technology, select Add new condition and enter the following data:
-
Resource attribute key:
java.main.class -
Matcher:
exists
-
-
Check the preview to see if the condition matches the expected processes.
-
Save the rule.
-
The order of the monitoring rules is important: As soon as a rule matches an entity, the entity won't be considered by any of the later rules. Consequently, specific rules should come before general rules.
FAQ
Does the order of the rules matter?
The order of the monitoring rules is important: As soon as a rule matches an entity, the entity won't be considered by any of the later rules. Consequently, specific rules should come before general rules.
Can existing classic monitoring rules be automatically migrated to the new ones?
Automatic migration from the classic to the new monitoring rules isn't possible. You need to recreate the rules, or you can create new rules from scratch and preview the monitored hosts to ensure the desired hosts are covered.
Is process restart required after enabling or disabling a monitoring rule?
Classic monitoring rules
No restart is required. For more information, see FAQ: Is restart required after enabling or disabling an Application Security feature or functionality?
What happens if a Do not monitor rule that applies gets added?
New monitoring rules Classic monitoring rules
- New vulnerabilities for the processes that match the rule won't be created.
- Existing vulnerabilities that only relate to matching processes are resolved.
What happens if a Do not monitor rule is deleted or doesn't apply anymore?
New monitoring rules Classic monitoring rules
- New vulnerabilities for the processes that match the rule will be created.
- Related resolved vulnerabilities are reopened.
Related topics
Third-Party Vulnerabilities
Vulnerabilities (Preview)Application Security