mirror of
https://github.com/prowler-cloud/prowler.git
synced 2026-03-22 03:08:23 +00:00
docs: update mutelist docs (#10296)
This commit is contained in:
committed by
GitHub
parent
2768b7ad4e
commit
e9855bbf2f
@@ -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
|
||||

|
||||
|
||||
<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
|
||||
|
||||
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user