Finding rules describe the backend logic used to evaluate your runtime security posture by analyzing Agent events. When a finding rule matches, Workload Protection generates a finding for the affected resource.

Unlike detection rules, which surface real runtime security threats, finding rules track ongoing bad practices and misconfigurations. A finding represents a resource (a host or container) that is actively failing a security policy, not a single suspicious activity.

Finding rules use existing Agent events to surface practical security recommendations such as package manager usage in containers, IMDS access patterns, or unnecessary privilege configurations. This helps you address real-world risks that are not direct threats but represent risky practices in production environments.

OOTB finding rules

Workload Protection includes out-of-the-box (OOTB) finding rules maintained by Datadog. These rules continuously surface bad practices and risky configurations in production workloads. Datadog develops new default rules on an ongoing basis, and new rules are automatically imported into your account. For the full list, see OOTB rules list.

Browse and review finding rules deployed to your organization in the Workload Protection finding rules list in Datadog. Each rule includes a description of the security risk, the resource types it applies to, and remediation guidance.

To reduce noise for expected configurations, use a findings automation to mute a rule without disabling it. See Findings automation.

Create a custom finding rule

Custom finding rules follow the same creation process as detection rules, with one key difference: they target a specific resource type—host or container—rather than detecting a point-in-time event.

To create a custom finding rule, go to the Workload Protection finding rules page and click New Rule.

The rule editor walks you through five steps.

Step 1: Select a resource type and define search query

Select the type of resource the finding rule evaluates:

• Host: The rule applies to hosts. Workload Protection automatically prepends -@container.id:* to your query to exclude container events.
• Container: The rule applies to containers. Workload Protection automatically prepends @container.id:* to your query to include only container events.

Define the query that selects which Agent events the rule evaluates. The search query determines which events are considered when deciding whether a resource is failing the rule.

You can:

• Filter on specific fields in Agent events to refine the query and make the finding more precise. For example, filter on @process.executable.path, @file.path, or @agent.rule_id. Similar to detection rules, finding rules can query any field from the backend event schema, which includes all Agent event fields plus additional enrichment such as infrastructure context, process ancestry, and threat intelligence. See Linux backend syntax and Windows backend syntax for the full set of available fields.
• Combine multiple conditions to scope the rule to a subset of your infrastructure or workloads.

Use the Agent Events Explorer to test your query and validate which events match before you publish the rule.

Step 2: Define finding severity

Define the severity a finding has when the rule is triggered.

Step 3: Describe the finding

Configure the name, description, and remediation guidance that appear when a finding is generated.

1. Enter a Rule name. The name appears in the finding rules list and becomes the title of the generated finding.
2. In the Rule message section, use Markdown to describe what the finding means and how to address it. Include a ## Remediation header in the message body—Workload Protection uses this section to surface remediation steps directly in the finding side panel.
3. Use the Tag resulting findings dropdown to add tags to generated findings. For example, security:posture or compliance:pci.

Note: The ## Remediation header is required for remediation steps to display correctly in the finding side panel.