Overview

In certain cases, you may want to suppress specific runtime incidents , especially when they involve known tools, benign processes, or trusted behaviors that are common in your environment.

The Risk Acceptance feature allows you to suppress such incidents by creating targeted suppression rules from existing incidents.

---

Scope of Accepted risk

You can define the scope of the accepted risks to control how broadly it is applied:

💡

Use Cluster or namespace level scoping when behavior is known to be safe only in specific environments.

Entity-Based Risk Acceptance

Suppress future incidents for reviewed runtime behaviors by accepting risk based on specific entities such as files, processes, DNS requests, and more.

This gives you surgical precision in incident suppression, so only incidents matching exact scenarios you've deemed safe are silenced, while everything else stays visible.

---

When to Use This

Use this feature when:

• An incident was investigated and found non-malicious
• You want to suppress repeat incidents of the exact same behavior
• You need fine-grained control over risk acceptance, not just broad suppression

---

Supported Entities & Fields

Each rule can include one or more of the following entity types:

💡

Example: You can suppress future alerts when both a process and a DNS request to are present in the alert.

---

Matching Logic

• AND across entity types: All specified entities must match for the rule to apply
• Exact match by default (In logic) - Values are separated by commas. To include a comma as part of a value, escape it with \ (e.g., import os\,pty\,socket).
• Partial matching: via Contains
• Matches are case-sensitive

Creating Suppression Rules

Suppression rules can be created directly from a specific incident . When doing so, relevant scope and entity details (such as file name, process, domain name, etc.) are auto-populated in the rule creation form. You can review, edit, or expand these before saving the rule.

• Suppression rules are active immediately upon creation.
• You can revoke suppression rules at any time from the Risk Acceptance Management section.
• Auto-prefill from incident: Scope and Entity types and values are pulled directly from the incident you're accepting
• Editable: You can change, remove, or add values
• Preview impact: See how many past incidents would be suppressed by your rule before saving

💡

Note:

When creating a risk acceptance rule, existing incidents that match the rule are marked as resolved. They remain stored in the system and can still be viewed.

However, future incidents that match the rule will not be generated at all, they will not be stored, resolved, or visible in the platform. This ensures reduced noise without losing visibility into past activity

---

Example for accepting the risk - Reverse Shell Patterns Detected

• Process

  • Name: python3
  • Command Line: /usr/local/bin/python3

• File

  • Name: python3.10
  • Directory: /usr/local/bin

Only incidents matching the all of these criteria in the dialog will be suppressed in the future.

---

FAQs

Q: What is the scope of the incident suppression?

• Rules are evaluated against the define scope by Cluster, Namespace, resource, entities, and can be expand to a wider scope

Q: Are suppressed incidents stored?

• Yes. Suppressed incidents are logged and accessible in the system.

Q: Can I edit or delete a rule later?

• Yes. Go to the Risk acceptance section under Policies to manage all risk acceptance rules.

Q: Are rules apply retroactively?

• Yes, they affect all incidents that match the rule criteria

Q: What is the required Helm version for supporting Scope entities?

• “Scope entities” requires Helm chart v1.28.3 or higher