docs: update mutelist docs (#10296)

This commit is contained in:
Daniel Barranquero
2026-03-10 16:58:31 +01:00
committed by GitHub
parent 2768b7ad4e
commit e9855bbf2f
2 changed files with 28 additions and 8 deletions

View File

@@ -77,10 +77,10 @@ If the YAML configuration is invalid, an error message will be displayed
2. Navigate to the Findings page to verify muted findings
![Check muted findings](/images/mutelist-ui-9.png)
<Note>
The Advanced Mutelist configuration takes effect on subsequent scans. Existing findings are not retroactively muted.
<Warning>
The Advanced Mutelist configuration takes effect on **subsequent scans only**. Existing findings from previous scans are **not** retroactively muted. You must run a new scan after saving your YAML configuration to see its effect. Similarly, removing a pattern from the YAML configuration will only stop muting new findings generated by subsequent scans.
</Note>
</Warning>
## YAML Configuration Examples
Below are ready-to-use examples for different cloud providers. For detailed syntax and logic explanation, see [CLI Mutelist documentation](/user-guide/cli/tutorials/mutelist#how-the-mutelist-works).
@@ -421,6 +421,10 @@ Mutelist:
Description: "Mute findings for dev/test environments in alpha project"
```
### Priority: Advanced vs. Simple Mutelist
When both Advanced Mutelist (YAML) and [Simple Mutelist](/user-guide/tutorials/prowler-app-simple-mutelist) rules match the same finding, the **Advanced Mutelist takes higher priority**. The finding will be muted with the reason "Muted by mutelist". If a finding is not matched by the Advanced Mutelist but matches a Simple Mutelist rule, the Simple rule's custom justification is used instead.
### Best Practices
1. **Start Small**: Begin with specific resources and gradually expand

View File

@@ -90,10 +90,10 @@ To toggle a mute rule without deleting it:
3. Locate the mute rule
4. Use the toggle switch in the "Enabled" column to enable or disable the rule
<Note>
Disabled mute rules remain in the system but do not affect findings. Findings associated with disabled rules will appear as unmuted in subsequent scans.
<Warning>
Disabling a mute rule does not retroactively unmute existing findings that were already marked as muted. Those findings retain their muted status as point-in-time historical records. Only **new findings** generated by subsequent scans will appear as unmuted.
</Note>
</Warning>
### Editing Mute Rules
@@ -117,7 +117,7 @@ To permanently remove a mute rule:
5. Confirm the deletion
<Warning>
Deleting a mute rule is permanent. The finding will appear as unmuted in subsequent scans. To temporarily unmute a finding without losing the rule, disable the rule instead of deleting it.
Deleting a mute rule is permanent and cannot be undone. Existing findings that were already muted retain their muted status as historical records — only **new findings** from subsequent scans will appear as unmuted. To temporarily stop muting new findings without losing the rule, disable the rule instead of deleting it.
</Warning>
@@ -129,9 +129,13 @@ Simple Mutelist creates mute rules based on a finding's unique identifier (UID).
- **Historical findings** with the same UID are also muted
- **Future findings** from subsequent scans are automatically muted if they match the UID
### Bulk Muting and Grouping
When muting multiple findings at once, a single mute rule is created containing all selected finding UIDs. However, once a rule is created, **additional findings cannot be added to an existing rule**. To mute new findings, create a separate mute rule.
### Uniqueness Constraint
Each finding UID can only have one mute rule. Attempting to create a duplicate mute rule for the same finding displays an error message indicating the rule already exists.
Each finding UID can only belong to one **enabled** mute rule at a time. Attempting to create a mute rule that includes a finding UID already covered by another enabled rule displays a conflict error. If you need to reorganize mute rules, disable or delete the existing rule first, then create a new one.
## Simple Mutelist vs. Advanced Mutelist
@@ -139,8 +143,12 @@ Each finding UID can only have one mute rule. Attempting to create a duplicate m
| ------------------------ | ----------------------------------------- | ------------------------------------------------------ |
| **Configuration method** | Point-and-click interface | YAML configuration file |
| **Muting scope** | Individual finding UIDs | Patterns based on checks, regions, resources, and tags |
| **When muting applies** | Immediately (current + historical findings) | On subsequent scans only (not retroactive) |
| **Unmuting behavior** | Disabling/deleting a rule only affects new findings from subsequent scans | Removing a pattern stops muting on the next scan |
| **Adding findings later** | Not supported — must create a new rule | Automatic — any finding matching the pattern is muted |
| **Regular expressions** | Not supported | Fully supported |
| **Bulk operations** | Checkbox selection in Findings table | YAML wildcards and patterns |
| **Priority** | Applied after Advanced Mutelist | Highest priority |
| **Best for** | Quick, ad-hoc muting of specific findings | Complex, policy-driven muting rules |
### When to Use Simple Mutelist
@@ -175,6 +183,14 @@ If an error indicates a mute rule already exists for a finding:
3. Edit the existing rule's justification if needed, or
4. Delete the existing rule and create a new one
### Finding Still Appears Muted After Disabling or Deleting a Rule
If a finding still appears as muted after disabling or deleting its mute rule:
1. This is expected behavior — existing findings retain their muted status as historical records
2. Run a new scan to generate new findings that will reflect the updated rule state
3. New findings with the same UID will appear with their actual status (PASS/FAIL) instead of muted
### Finding Still Appears Unmuted
If a muted finding still appears unmuted: