This page explains how to reduce the volume of findings that you receive in Security Command Center by muting findings.
Muting a finding hides it from the default view of your findings in the Google Cloud console. You can manually or programmatically mute findings and create filters to automatically silence existing and future findings based on criteria you specify.
The Security Command Center detection services provide broad security assessments of your Google Cloud deployment, but you might find that certain findings are not appropriate or relevant for your organization or projects. A high volume of findings also can make it difficult for your security analysts to effectively identify and remediate the most critical risks. Muting findings saves you time from reviewing or responding to security findings for assets that are isolated or fall within acceptable business parameters.
Muting findings has several advantages over disabling detectors:
- You can create custom filters to fine-tune which findings are muted.
- You can use mute rules to temporarily or indefinitely mute findings.
- Muting findings doesn't stop underlying assets from being scanned. Findings are still generated but remain hidden until you decide to view them.
Permissions
To mute findings, you need one of the following Identity and Access Management (IAM) roles at the organization, folder, or project level:
- View mute rules:
- Security Center Admin Viewer (
roles/securitycenter.adminViewer
) - Security Center Settings Viewer (
roles/securitycenter.settingsViewer
) - Security Center Mute Configurations Viewer
(
roles/securitycenter.muteConfigsViewer
)
- Security Center Admin Viewer (
- View, create, update, and delete mute rules:
- Security Center Admin (
roles/securitycenter.admin
) - Security Center Admin Editor (
roles/securitycenter.adminEditor
) - Security Center Settings Editor
(
roles/securitycenter.settingsEditor
) - Security Center Mute Configurations Editor
(
roles/securitycenter.muteConfigsEditor
)
- Security Center Admin (
- Manually mute findings:
- Security Center Findings Editor
(
roles/securitycenter.findingsEditor
)
- Security Center Findings Editor
(
You can also create and grant custom roles with some or all of the following permissions:
- Mute rule read permissions
securitycenter.muteconfigs.get
securitycenter.muteconfigs.list
- Mute rule write permissions
securitycenter.muteconfigs.create
securitycenter.muteconfigs.update
securitycenter.muteconfigs.delete
- Finding write permissions
securitycenter.findings.setMute
securitycenter.findings.bulkMuteUpdate
Your ability to mute findings adheres to roles granted at the organization, folder, or project level. You can mute findings in specific folders or projects, and restrict the ability of others to mute findings based on the access they are granted. For example, if you have access to a single project, you can only mute findings in that project. If you have access to a folder, you can mute findings in any subfolder or project inside that folder.
To learn more about Security Command Center roles, see Access control.
Create and manage mute rules
Mute rules are Security Command Center configurations that use filters you create to automatically mute future and existing findings based on criteria you specify. You can create filters with static or dynamic mute rules.
Static mute rules mute future findings indefinitely. Dynamic mute rules mute future and existing findings temporarily until a specified date or indefinitely until a finding no longer matches the configuration.
Types of mute rules
Security Command Center supports static and dynamic mute rule configurations. Although you can use static and dynamic mute rules simultaneously, we don't recommend it. Static mute rules override dynamic mute rules when they are applied to the same finding. As a result, dynamic mute rules won't work as intended, which can create confusion when managing your findings. Therefore, we recommend that you use one mute rule type exclusively.
Unless you are already using static mute rules, we recommend using dynamic mute rules exclusively because they offer more flexibility.
The following table provides a high-level comparison of the two mute rule types. For more details, see Static mute rules and Dynamic mute rules.
Static mute rules | Dynamic mute rules |
---|---|
Indefinitely act on findings. | Can act on a finding either temporarily with an expiration time or indefinitely if no expiration time is set. |
Don't apply to existing findings. | Apply to existing and new findings. |
Take precedence over dynamic mute rules. | Are a lower priority and are overridden by static mute rules when both types apply to a finding. |
Static mute rules
- Static mute rules act indefinitely. When a finding matches your static mute
configuration, Security Command Center automatically sets the
mute
property of the finding toMUTED
until you manually change it. - Static mute rules have no effect on existing findings. They only apply to findings that are newly created or updated after the rule is defined. If you also want to mute similar existing findings, use the same filters to bulk mute findings.
- Static mute rules take precedence over dynamic mute rules. Therefore, all new findings that match a defined static mute rule are considered muted even if they also match a defined dynamic mute rule.
Dynamic mute rules
- Dynamic mute rules can act on a finding either temporarily with an expiration
time or indefinitely if no expiration time is set. When an existing or newly
created finding matches your dynamic mute configuration, Security Command Center
automatically sets the
mute
property of the finding toMUTED
until the specified expiration date or until there are changes in the finding or the configuration itself. When a dynamic mute rule expires, Security Command Center removes the rule from the finding. If the finding does not match any other dynamic mute rules, themute
property is automatically reset toUNDEFINED
. - Dynamic mute rules automatically apply to existing findings that match your configuration, as well as to findings that are newly created or updated.
- Dynamic mute rules are a lower priority and are overridden by static mute rules when both types apply to a finding.
We recommend using dynamic mute rules exclusively. The ability to temporarily mute and automatically unmute findings makes dynamic mute rules a more flexible option than static mute rules.
If you are using static mute rules to reduce the number of findings that you review manually, and you want to migrate to dynamic mute rules, see Migrate from static to dynamic mute rules.
Scope of mute rules
Consider the scope of a mute rule when creating filters.
For example, if a filter is written to mute findings in Project A
, but
the filter itself is created under Project B
, the filter might not match
any findings.
Similarly, if data residency
is enabled, the scope of a mute rule
is limited to the Security Command Center location in which the mute rule is
created. For example, if you create a mute rule in the United States
(us
) location, the mute rule does not mute findings that are stored in
the European Union (eu
) or Global (global
) locations.
For more information about data residency and mute rules, see
Mute rules, continuous exports, and data residency.
For more information on creating filters, see Filtering notifications.
Mute rule restrictions
Mute rules don't support all finding properties. For a list of properties that mute rules don't support, see Unsupported finding properties for mute rules.
You can create, view, update, and delete mute rules based on the scope of your IAM roles. With organization-level roles, you see mute rules for all folders and projects within the organization. If you have folder-level roles, you can access and manage mute rules for specific folders and all subfolders and projects within those folders. Project-level roles let you manage mute rules in specific projects.
Security Command Center Premium supports granting roles at the organization, folder, and project levels. Security Command Center Standard only supports granting roles at the organization level. For more information, see Access control.
Data residency and mute rules
If data residency is enabled, the
configurations that define mute rules—muteConfig
resources—are
subject to data residency control and are stored in a
Security Command Center location
that you select.
To apply a mute rule to the findings in a Security Command Center location, you must create the mute rule in the same location as the findings to which it applies.
Because the filters that are used in mute rules can contain data that is subject to residency controls, make sure you specify the correct location before you create them. Security Command Center does not restrict which location you create mute rules or streaming exports in.
Mute rules are stored only in the location in which they are created and cannot be viewed or edited in other locations.
After you create a mute rule, you can't change its location. To change the location, you need to delete the mute rule and recreate it in the new location.
To view mute rules in the Google Cloud console, you first need to set the Google Cloud console view to the location in which they were created.
The same rules apply to the API representation of a mute rule, MuteConfig
.
To retrieve a MuteConfig
by using API calls,
you need to specify the location in the full resource name of
the MuteConfig
. For example:
GET https://securitycenter.googleapis.com/v2/{name=organizations/123/locations/eu/muteConfigs/my-mute-rule-01}
Similarly, to retrieve a muteConfig
by using
the gcloud CLI, you can specify the location
by using the --locations
flag. For example:
gcloud scc muteconfigs list --organizations=123 --location=us
Create a mute rule
Your organization can create a maximum of 1,000 mute rules.
You can create static or dynamic mute rules by using the Google Cloud console, the gcloud CLI, or the Security Command Center API. We recommend using dynamic mute rules exclusively in your mute rule configurations because they are more flexible than static mute rules. For a comparison of mute rule types, see Types of mute rules.
For sample code that creates a mute rule, see Create a mute rule.
To create a mute rule, click the tab for the procedure that you want to use:
Console
In the Google Cloud console, go to the Security Command Center Findings page.
If necessary, select your Google Cloud project or organization.
Optional: If data residency is enabled for Security Command Center, then change the data location as necessary.
To change the data location, click the location selector in the action bar.
A list of locations appears. Select the new location.
Click Mute options, and then select Manage mute rules.
Click Create mute rule, and then select either Dynamic mute rule or Static mute rule. For more information on mute rule types, see Types of mute rules.
Enter a Mute rule ID. This value is required.
Enter a Mute rule description that provides context for why findings are muted. This value is optional but recommended.
Parent resource indicates the scope at which the mute rule will be created and applied.
If you are creating a static mute rule or a dynamic mute rule with no expiration, continue to the next step. If you are creating a dynamic mute rule to temporarily mute findings, complete the following steps:
- Select the Mute matching findings temporarily checkbox.
- Select or enter the expiration date for the dynamic mute rule. This value indicates how long the rule will mute matching findings.
In the Findings query field, build your query statements by clicking Add filter. Alternatively, you can type in the query statements manually.
The Select filter dialog lets you choose supported finding attributes and values.
- Select a finding attribute or type its name in the Search finding attributes box. A list of the available sub-attributes displays.
- Select a sub-attribute. A selection field displays where you can build the query statement using the sub-attribute you selected, a query operator, and one or more values for the sub-attribute.
- Select the operator and one or more values for the sub-attribute from the panel. For more information about query operators and functions that they use, see Query operators in the Add filters menu.
- Click Apply.
The dialog closes and your query is updated.
- Repeat until the findings query contains all the attributes you want.
Review the filter for accuracy. To make changes, delete or add properties and filter values as needed.
Click Preview matching findings.
A table displays findings that match your query.
Click Save.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To create mute rules, run the
gcloud scc muteconfigs create
command:gcloud scc muteconfigs create CONFIG_ID \ --PARENT=PARENT_ID \ --location=LOCATION --description="RULE_DESCRIPTION" \ --filter="FILTER" \ --type=MUTE_TYPE \ --expiry-time=TIMESTAMP
Replace the following:
CONFIG_ID
: the name of the mute rule. The ID must use alphanumeric characters and hyphens and be between 1 and 63 characters.PARENT
: the scope in the resource hierarchy to which the mute rule applies,organization
,folder
, orproject
.PARENT_ID
: the ID of the parent organization, folder, or project, specified in the format oforganizations/123
,folders/456
, orprojects/789
.LOCATION
: if data residency is enabled, the Security Command Center location in which to create a mute rule; if data residency is not enabled, use the valueglobal
.RULE_DESCRIPTION
: a description of the mute rule of no more than 1,024 characters.FILTER
: the expression you define to filter findings. For example, to muteOPEN_FIREWALL
findings, your filter can beFILTER="category=\"OPEN_FIREWALL\""
.MUTE_TYPE
: the type of mute rule you want to create. Valid mute rule types areDYNAMIC
andSTATIC
. The mute rule type is set toSTATIC
by default. You can't change the type of a mute rule after you've created it.TIMESTAMP
: only applies if you are creating a dynamic mute rule. The date/time string that indicates when the dynamic mute rule expires. The value must be set to at least one day in the future or the request will be rejected. For information about time formats, seegcloud topic datetimes
. When a dynamic mute rule expires, it is removed from all matched findings. If you want the dynamic mute rule to act indefinitely on matching findings, omit this field.
The response includes the mute rule ID, which you can use to view, update, and delete mute rules, as described in Manage mute rules.
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the muteConfigs create
method to
create a mute rule. The request body is an instance of MuteConfig
.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, use the version 1 endpoint
to call muteConfigs create
.
In the request body, use the version 1 MuteConfig
definition:
POST https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/muteConfigs?muteConfigId=MUTE_CONFIG_ID -d { "description": "RULE_DESCRIPTION", "filter": "FILTER", "type": "MUTE_TYPE", "expiryTime": "TIMESTAMP" }
If you are using Security Command Center API v2, use the version 2
endpoint to call
muteConfigs create
.
In the request body, use the version 2
MuteConfig
definition:
POST https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/locations/LOCATION/muteConfigs?muteConfigId=MUTE_CONFIG_ID -d { "description": "RULE_DESCRIPTION", "filter": "FILTER", "type": "MUTE_TYPE", "expiryTime": "TIMESTAMP" }
Replace the following:
PARENT
: the parent resource for your mute rule (organizations
,folders
, orprojects
)PARENT_ID
: the ID of the parent organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to create a mute rule; if data residency is not enabled, use the valueglobal
MUTE_CONFIG_ID
: the name of the mute rule (between 1 and 63 characters)RULE_DESCRIPTION
: a description of the mute rule (max: 1,024 characters)FILTER
: the expression you define to filter findingsFor example, to mute
OPEN_FIREWALL
findings, your filter can be"category=\"OPEN_FIREWALL\""
.MUTE_TYPE
: the type of mute rule you want to create. Valid mute rule types areDYNAMIC
andSTATIC
. You can't change the type of a mute rule after you've created it.TIMESTAMP
: only applies if you are creating a dynamic mute rule. The date/time string that indicates when the dynamic mute rule expires. The value must be set to at least one day in the future or the request will be rejected. For information about time formats, seegcloud topic datetimes
. When a dynamic mute rule expires, it is removed from all matched findings. If you want the dynamic mute rule to act indefinitely on matching findings, omit this field.
The response includes the mute config ID, which you can use to view, update, and delete mute rules, as described in Manage mute rules.
New findings that exactly match the filter are hidden, and the mute
attribute for the findings is set to MUTED
.
Unsupported finding properties for mute rules
Mute rules don't support all finding properties in filters. The following properties are not supported in mute rule filters.
createTime
eventTime
mute
mute_initiator
mute_update_time
name
parent
security_marks
source_properties
state
List mute rules
You can list the mute rules in an organization, folder, or project by using the Google Cloud console, the gcloud CLI, or the Security Command Center API.
Your ability to list mute rules for a given scope, depends on the permissions that are granted to your IAM roles.
If data residency is enabled for Security Command Center, the scope of the list command is also limited to the selected Security Command Center location.
For sample code that lists mute rules, see List mute rules.
To list the mute rules for an organization, folder, or project, click the tab for the procedure that you want to use:
Console
In the Google Cloud console, go to the Mute rules tab in the Security Command Center Settings page.
If necessary, select your Google Cloud project or organization.
Optional: If data residency is enabled for Security Command Center, then change the data location as necessary.
To change the data location, click the location selector in the action bar.
A list of locations appears. Select the new location.
In the Mute rules section, you see details for active mute rules, including the following:
- Name: mute rule ID
- Parent resource: the resource where the mute rule lives
- Description: the mute rule description, if available
- Last updated by: the principal who last updated the rule
- Last updated: the date and time the rule was last updated
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To list mute rules, run the
gcloud scc muteconfigs list
command:gcloud scc muteconfigs list --PARENT=PARENT_ID --location=LOCATION
Replace the following:
PARENT
: the parentorganization
,folder
, orproject
for which to list mute rulesPARENT_ID
: the ID of the parent organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to list mute rules; if data residency is not enabled, use the valueglobal
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the muteConfigs list
method to list
mute rules. The request body is empty.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, use the v1
endpoint to call
muteConfigs list
:
GET https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/muteConfigs
If you are using Security Command Center API v2, use the v2
endpoint to call
muteConfigs list
:
GET https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/locations/LOCATION/muteConfigs
Replace the following:
PARENT
: the parent resource for your mute rule (organizations
,folders
, orprojects
)PARENT_ID
: the ID of the parent organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to list mute rules; if data residency is not enabled, use the valueglobal
The response includes the names, descriptions, and mute config IDs for your mute rules.
View a mute rule configuration
You can view a mute rule configuration by using the Google Cloud console, the gcloud CLI, or the Security Command Center API.
For sample code that retrieves a mute rule configuration, see View a mute rule.
To view a mute rule configuration, click the tab for the procedure that you want to use:
Console
In the Google Cloud console, go to the Mute rules tab in the Security Command Center Settings page.
If necessary, select your Google Cloud project or organization.
Optional: If data residency is enabled for Security Command Center, then change the data location as necessary.
To change the data location, click the location selector in the action bar.
A list of locations appears. Select the new location.
In the Mute rules section, you see a list of mute rules.
Click the name of the rule you want to view.
A page opens with the mute rule's configuration.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To view the configuration of a mute rule, run the
gcloud scc muteconfigs get
command:gcloud scc muteconfigs get MUTE_CONFIG_ID \ --PARENT=PARENT_ID --location=LOCATION
Replace the following:
MUTE_CONFIG_ID
: the ID for the mute rulePARENT
: the parent resource for your mute rule (organization
,folder
, orproject
)PARENT_ID
: the ID of the organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to view the mute rule's configuration; if data residency is not enabled, use the valueglobal
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the muteConfigs get
method to return
the configuration of a mute rule. The request body is empty.
To get the CONFIG_ID
for a mute rule, first execute an API call to
List mute rules.
The response includes config IDs for returned mute rules.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, use the v1
endpoint to call
muteConfigs get
:
GET https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/muteConfigs/CONFIG_ID
If you are using Security Command Center API v2, use the v2
endpoint to call
muteConfigs get
:
GET https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/locations/LOCATION/muteConfigs/CONFIG_ID
Replace the following:
PARENT
: the parent resource for your mute rule (organizations
,folders
, orprojects
)PARENT_ID
: the ID for the organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to view the mute rule's configuration; if data residency is not enabled, use the valueglobal
CONFIG_ID
: the numeric ID of the mute rule
Update mute rules
You can update the description or finding filter of a mute rule by using the Google Cloud console, the gcloud CLI, or the Security Command Center API.
You can't change the ID; the parent organization, folder, or project; or the location of a mute rule. To change any of these values, you must create a new mute rule.
If you previously unmuted findings, they will be muted again if they are matched by a mute rule updated in the Google Cloud console. For more information, see Unmute individual findings.
For sample code that updates a mute rule, see Update a mute rule.
To update a mute rule, click the tab for the procedure that you want to use:
Console
In the Google Cloud console, go to the Mute rules tab in the Security Command Center Settings page.
Select the Google Cloud project or organization that is the parent resource for the mute rule you want to modify.
Optional: If data residency is enabled for Security Command Center, then change the data location as necessary.
To change the data location, click the location selector in the action bar.
A list of locations appears. Select the new location.
Click the name of the mute rule you want to modify.
If you didn't select the appropriate project or organization, you might see a note informing you that you don't have permission to modify the mute rule.
Enter a new description, and then click Save.
For dynamic mute rules, update or change the expiration time of the rule.
Update or change the filter.
For instructions, see Create mute rules.
To view findings that match the updated filter, click Preview Matching Findings.
A table loads with findings that match the new query.
Click Save.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To update mute rules, run the
gcloud scc muteconfigs update
command:gcloud scc muteconfigs update MUTE_CONFIG_ID \ --PARENT=PARENT_ID \ --location=LOCATION --description=RULE_DESCRIPTION \ --filter=FILTER --type=MUTE_TYPE \ --expiry-time=TIMESTAMP
Replace the following:
MUTE_CONFIG_ID
: the ID for the mute rule.PARENT
: the parent resource for your mute rule (organization
,folder
, orproject
).PARENT_ID
: the ID for the organization, folder, or project.LOCATION
: if data residency is enabled, the Security Command Center location in which to update the mute rule; if data residency is not enabled, use the valueglobal
.RULE_DESCRIPTION
: a description of the mute rule (max: 1,024 characters).FILTER
: the expression you define to filter findings.For example, to mute
OPEN_FIREWALL
findings, your filter could beFILTER="category=\"OPEN_FIREWALL\""
.MUTE_TYPE
: the type of mute rule you are updating. Valid mute rule types areDYNAMIC
andSTATIC
. You can't change the type of a mute rule once you've created it.TIMESTAMP
: only applies if you are updating a dynamic mute rule. The date/time string that indicates when the dynamic mute rule expires. The value must be set to at least one day in the future or the request will be rejected. For information about time formats, seegcloud topic datetimes
. When a dynamic mute rule expires, it is removed from all matched findings. If you want the dynamic mute rule to act indefinitely on matching findings, omit this field.
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the muteConfigs patch
method to
update a mute rule. The request body is an instance of MuteConfig
.
To get the CONFIG_ID
for a mute rule, execute an API call to
list mute rules.
The response includes config IDs for returned mute rules.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, use the v1
endpoint to
call muteConfigs patch
:
PATCH https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/muteConfigs/CONFIG_ID { "description": "RULE_DESCRIPTION", "filter": "FILTER", "type": "MUTE_TYPE", "expiryTime": "TIMESTAMP" }
If you are using Security Command Center API v2, use the v2
endpoint to
call muteConfigs patch
:
PATCH https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/locations/LOCATION/muteConfigs/CONFIG_ID { "description": "RULE_DESCRIPTION", "filter": "FILTER", "type": "MUTE_TYPE", "expiryTime": "TIMESTAMP" }
Replace the following:
PARENT
: the parent resource for your mute rule (organizations
,folders
, orprojects
)PARENT_ID
: the ID for the organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to update the mute rule; if data residency is not enabled, use the valueglobal
CONFIG_ID
: the numeric ID of the mute ruleRULE_DESCRIPTION
: a description of the mute rule (max: 1,024 characters)FILTER
: the expression you define to filter findingsFor example, to mute
OPEN_FIREWALL
findings, your filter can be"category=\"OPEN_FIREWALL\""
.MUTE_TYPE
: the type of mute rule you are updating. Valid mute rule types areDYNAMIC
andSTATIC
. You can't change the type of a mute rule once you've created it.TIMESTAMP
: only applies if you are updating a dynamic mute rule. The date/time string that indicates when the dynamic mute rule expires. The value must be set to at least one day in the future or the request will be rejected. For information about time formats, seegcloud topic datetimes
. When a dynamic mute rule expires, it is removed from all matched findings. If you want the dynamic mute rule to act indefinitely on matching findings, omit this field.
New findings that exactly match the filter are hidden, and the mute
attribute
for the findings is set to MUTED
.
Delete mute rules
You can delete a mute rule by using the Google Cloud console, the gcloud CLI, or the Security Command Center API.
Before deleting mute rules, understand the following:
- You can't recover deleted mute rules.
- Deleting static mute rules doesn't automatically unmute any findings that are muted. You must manually or programmatically unmute findings.
- Deleting dynamic mute rules automatically removes the rule from all previously matching findings and unmutes them if they don't match any additional rules.
- Future findings that match filters in deleted mute rules aren't muted.
For sample code that deletes a mute rule, see Delete a mute rule.
To delete a mute rule, click the tab for the procedure that you want to use:
Console
In the Google Cloud console, go to the Mute rules tab in the Security Command Center Settings page.
If necessary, select your Google Cloud project or organization.
Optional: If data residency is enabled for Security Command Center, then change the data location as necessary.
To change the data location, click the location selector in the action bar.
A list of locations appears. Select the new location.
Click the name of the mute rule you want to delete.
Click delete Delete.
Read the dialog and, if satisfied, click Delete.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To delete mute rules, run the
gcloud scc muteconfigs delete
command:gcloud scc muteconfigs delete MUTE_CONFIG_ID \ --PARENT=PARENT_ID --location=LOCATION
Replace the following:
MUTE_CONFIG_ID
: the ID for the mute configPARENT
: the parent resource for your mute rule (organization
,folder
, orproject
)PARENT_ID
: the ID for the organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to delete the mute rule; if data residency is not enabled, use the valueglobal
Confirm your request to delete the mute rule.
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the muteConfigs delete
method to
delete a mute rule. The request body is empty.
To get the CONFIG_ID
for a mute rule, execute an API call to
List mute rules.
The response includes config IDs for returned mute rules.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, use the v1
endpoint to call
muteConfigs delete
:
DELETE https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/muteConfigs/CONFIG_ID
If you are using Security Command Center API v2, use the v2
endpoint to call
muteConfigs delete
:
DELETE https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/locations/LOCATION/muteConfigs/CONFIG_ID
Replace the following:
PARENT
: the parent resource for your mute rule (organizations
,folders
, orprojects
)PARENT_ID
: the ID for the organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to delete the mute rule; if data residency is not enabled, use the valueglobal
CONFIG_ID
: the numeric ID of the mute rule
Mute an individual finding
You can statically mute an individual finding by using the Google Cloud console, the gcloud CLI, or the Security Command Center API.
Statically muting a finding doesn't affect whether it is active or not. If an
active finding is muted, the state
attribute remains unchanged:
state="ACTIVE"
. The finding is hidden, but remains active until the underlying
vulnerability, misconfiguration, or threat is resolved. In addition, by
statically muting a finding, you are overriding any dynamic mute rules that
apply to the finding.
Muting a toxic combination finding closes the corresponding toxic combination case.
To mute all future findings that match criteria that you specify, see Create mute rules.
For sample code to mute a finding, see Mute a finding.
To statically mute an individual finding, click the tab for the procedure that you want to use:
Console
In the Google Cloud console, go to the Security Command Center Findings page.
If necessary, select your Google Cloud project or organization.
Optional: If data residency is enabled for Security Command Center, then change the data location as necessary.
To change the data location, click the location selector in the action bar.
A list of locations appears. Select the new location.
If you don't see the finding that you need to mute in the Findings query results panel, select the category of the finding in the Category section of the Quick filters panel.
Select the checkbox next to the finding that you need to mute. You can select one or more findings.
On the Findings query results action bar, click Mute options, and then select Apply mute override.
The
mute
attribute for the selected findings is set toMUTED
and the finding is removed from the Findings query results panel.
Alternatively, you can mute a finding from its details panel:
- In the Finding query results panel of the Findings page, in the Category column, click the name of an individual finding. The details panel of the finding opens.
- Click Take action.
From the Take action menu, select Apply mute override.
If you select Mute findings like this instead, the Create mute rule page opens where you can create a mute rule for findings of the same type or that include the same
Indicator
attribute.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To set a finding's mute state to
MUTED
, use theset-mute
command in the gcloud CLI:gcloud scc findings set-mute FINDING_ID \ --PARENT=PARENT_ID \ --location=LOCATION --source=SOURCE_ID \ --mute=MUTED
Replace the following:
FINDING_ID
: the ID for the finding you want to muteTo retrieve finding IDs, use the Security Command Center API to list findings. The finding ID is the last part of the
canonicalName
attribute, for example,projects/123456789012/sources/1234567890123456789/findings`/5ee30aa342e799e4e1700826de053aa9
.PARENT
: the parent resource (project
,folder
, ororganization
), case-sensitivePARENT_ID
: the ID of the parent organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to mute the finding; if data residency is not enabled, use the valueglobal
SOURCE_ID
: the source IDFor instructions on retrieving a source ID, see Getting the source ID.
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the setMute
method to mute a
finding. The request body is an enum that indicates the resulting
mute state.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, call
setMute
by using the v1
endpoint:
POST https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/sources/SOURCE_ID/findings/FINDING_ID:setMute { "mute": "MUTED" }
If you are using Security Command Center API v2, call
setMute
by using the v2
endpoint:
POST https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/sources/SOURCE_ID/locations/LOCATION/findings/FINDING_ID:setMute { "mute": "MUTED" }
Replace the following:
PARENT
: the parent resource (organizations
,folders
, orprojects
).PARENT_ID
: the ID of the parent organization, folder, or project.LOCATION
: if data residency is enabled, the Security Command Center location in which to mute the finding; if data residency is not enabled, use the valueglobal
SOURCE_ID
: the numeric ID for the source.For instructions on retrieving a source ID, see Getting the source ID.
FINDING_ID
: the ID for the finding you want to mute.To retrieve finding IDs, use the Security Command Center API to list findings. The finding ID is the last part of the
canonicalName
attribute, for example,projects/123456789012/sources/1234567890123456789/findings/5ee30aa342e799e4e1700826de053aa9
.
After you mute a finding, its mute
attribute is set to MUTED
.
Unmute individual findings
You can statically unmute an individual finding by using the Google Cloud console, the gcloud CLI, or the Security Command Center API.
Unmuting a finding is useful when you need to prevent a finding from being hidden by an overly broad mute rule, or by a rule that might be too complex to modify to exclude findings you deem important.
For sample code to unmute a finding, see Unmute a finding.
Unmuted findings are muted again only if the findings are manually muted. Mute rules created with the gcloud CLI or Security Command Center API won't affect findings unmuted by users.
For sample code to unmute a finding, see Unmute a finding.
Console
In the Google Cloud console, go to the Security Command Center Findings page.
If necessary, select your Google Cloud project or organization.
The Findings page opens with the default query displayed in the Query preview section. The default query filters out muted findings, so you need to edit the query before muted findings appear in the Findings query results panel.
Optional: If data residency is enabled for Security Command Center, then change the data location as necessary.
To change the data location, click the location selector in the action bar.
A list of locations appears. Select the new location.
To the right of the Query preview section, click Edit query to open the Query editor.
In the Query editor field, replace the existing mute statement with the following:
mute="MUTED"
Click Apply. The findings in the Findings query results panel are updated to include only muted findings.
If necessary, filter out other muted findings. For example, in the Quick filters panel under Category, select the name of the finding that you need to unmute to filter out all other categories of finding.
Select the checkbox next to the finding that you want to unmute. You can select one or more findings.
On the Findings query results action bar, click Mute Options, and then select Apply unmute override.
The
mute
attribute for the selected findings is set toUNMUTED
and the finding is removed from the Findings query results panel.
Alternatively, you can unmute a finding from its details panel:
- In the Finding query results panel of the Findings page, in the Category column, click the name of an individual finding. The details panel of the finding opens.
- Click Take action.
- From the Take action menu, select Apply unmute override.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To set a finding's mute state to
UNMUTED
, use theset-mute
command in the gcloud CLI:gcloud scc findings set-mute FINDING_ID \ --PARENT=PARENT_ID \ --location=LOCATION --source=SOURCE_ID \ --mute=UNMUTED
Replace the following:
FINDING_ID
: the ID for the finding you want to muteTo retrieve finding IDs, use the Security Command Center API to list findings. The finding ID is the last part of the
canonicalName
attribute, for example,projects/123456789012/sources/1234567890123456789/findings/5ee30aa342e799e4e1700826de053aa9
.PARENT
: the parent resource (project
,folder
, ororganization
), case-sensitivePARENT_ID
: the ID of the parent organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to unmute the finding; if data residency is not enabled, use the valueglobal
SOURCE_ID
: the source IDFor instructions on retrieving a source ID, see Getting the source ID.
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the setMute
method to unmute a
finding. The request body is an enum that indicates the resulting
mute state.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, call
setMute
by using the v1
endpoint:
POST https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/sources/SOURCE_ID/findings/FINDING_ID:setMute { "mute": "UNMUTED" }
If you are using Security Command Center API v2, call
setMute
by using the v2
endpoint:
POST https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/sources/SOURCE_ID/locations/LOCATION/findings/FINDING_ID:setMute { "mute": "UNMUTED" }
Replace the following:
PARENT
: the parent resource (organizations
,folders
, orprojects
)PARENT_ID
: the ID of the parent organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to unmute the finding; if data residency is not enabled, use the valueglobal
SOURCE_ID
: the numeric ID for the sourceFor instructions on retrieving a source ID, see Getting the source ID.
FINDING_ID
: the ID for the finding you want to mute.To retrieve finding IDs, use the Security Command Center API to list findings. The finding ID is the last part of the
canonicalName
attribute, for example,projects/123456789012/sources/1234567890123456789/findings/5ee30aa342e799e4e1700826de053aa9
.
Selected findings are no longer hidden, and the mute
attribute for the
findings is set to UNMUTED
.
Remove a mute state override from individual findings
You apply a mute state override when you intentionally modify a finding's mute state to statically mute or unmute the finding. For example, you might want to apply a mute state override to hide a low-severity finding that is not worth creating a dynamic mute rule for.
You can remove a mute state override from an individual finding by using the Google Cloud console, the gcloud CLI, or the Security Command Center API.
Before removing the mute state override from a finding, understand the following:
- A finding has a mute state override if it is statically muted or unmuted. You can apply a mute state override to any finding manually or automatically with static mute rules.
- A mute state override applies to a finding indefinitely and takes priority over any matching mute rules.
- Removing the mute state override from a finding resets the finding's mute state so that it can be processed by static or dynamic mute rules.
- Removing the mute state override from a finding is different than unmuting a finding. When you unmute a finding (apply an unmute override), mute rules can't mute that finding until you've manually removed the mute state override.
To remove the mute override from an individual finding, do the following:
Console
In the Google Cloud console, go to the Security Command Center Findings page.
Select your Google Cloud project or organization.
Optional: If data residency is enabled for Security Command Center, then change the data location as necessary.
To change the data location, click the location selector in the action bar.
A list of locations appears. Select the new location.
To the right of the Query preview section, click Edit query to open the Query editor.
In the Query editor field, replace the existing mute statement with the following:
mute="MUTED" OR mute="UNMUTED"
Click Apply. The findings in the Findings query results panel are updated to include statically muted and unmuted findings.
If necessary, filter out other findings. For example, in the Quick filters panel under Category, select the name of the finding that you need to reset to filter out all other categories of finding.
Select the checkbox next to the finding that you want to reset. You can select one or more findings.
On the Findings query results action bar, click Mute Options, and then select Remove mute overrides.
The
mute
attribute for the selected findings is set toUNDEFINED
and the finding is removed from the Findings query results panel.
Alternatively, you can unmute a finding from its details panel:
- In the Finding query results panel of the Findings page, in the Category column, click the name of an individual finding. The details panel of the finding opens.
- Click Take action.
- From the Take action menu, select Remove mute overrides.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To set a finding's mute state to
UNDEFINED
, use theset-mute
command in the gcloud CLI:gcloud scc findings set-mute FINDING_ID \ --PARENT=PARENT_ID \ --location=LOCATION --source=SOURCE_ID \ --mute=UNDEFINED
Replace the following:
FINDING_ID
: the ID for the finding you want to resetTo retrieve finding IDs, use the Security Command Center API to list findings. The finding ID is the last part of the
canonicalName
attribute, for example,projects/123456789012/sources/1234567890123456789/findings/5ee30aa342e799e4e1700826de053aa9
.PARENT
: the parent resource (project
,folder
, ororganization
), case-sensitivePARENT_ID
: the ID of the parent organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to remove the mute state override from a finding; if data residency is not enabled, use the valueglobal
SOURCE_ID
: the source IDFor instructions on retrieving a source ID, see Getting the source ID
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the setMute
method to reset the mute
state of a finding. The request body is an enum that indicates the resulting
mute state.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, call setMute
by using the v1
endpoint:
POST https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/sources/SOURCE_ID/findings/FINDING_ID:setMute { "mute": "UNDEFINED" }
If you are using Security Command Center API v2, call setMute
by using the v2
endpoint:
POST https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/sources/SOURCE_ID/locations/LOCATION/findings/FINDING_ID:setMute { "mute": "UNDEFINED" }
Replace the following:
PARENT
: the parent resource (organizations
,folders
, orprojects
)PARENT_ID
: the ID of the parent organization, folder, or projectLOCATION
: if data residency is enabled, the Security Command Center location in which to remove the mute state override from a finding; if data residency is not enabled, use the valueglobal
SOURCE_ID
: the numeric ID for the source
Mute or reset multiple existing findings
You can perform the following bulk mute operations for multiple existing
findings by using either the gcloud scc findings bulk-mute
gcloud CLI command, or the bulkMute
method of the
Security Command Center API:
Mute multiple existing findings. Muting existing findings in bulk mutes them statically and overrides any dynamic mute rules that apply to the finding. If you need to mute similar future findings, create a mute rule.
Remove the mute state override on multiple existing findings. By removing the mute state override on a finding, you are resetting the mute state from
MUTED
(statically muted) orUNMUTED
(statically unmuted) toUNDEFINED
. This capability can be useful if you are migrating from static to dynamic mute rules.
Specify the set of findings that you need to mute by defining a finding filter. Bulk mute filters don't support all finding properties. For a list of unsupported properties, see Unsupported finding properties for mute rules.
If data residency is enabled for Security Command Center, bulk mute operations are limited in scope to the Security Command Center location in which they are executed.
For sample code that mutes findings in bulk, see Bulk mute findings.
To mute or reset findings in bulk, click the tab for the procedure that you want to use:
Console
In the Google Cloud console, you can only bulk mute findings by creating mute rules. In the Google Cloud console, creating mute rules silences existing and future findings.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
To mute or reset multiple findings in bulk, run the
gcloud scc findings bulk-mute
command:gcloud scc findings bulk-mute --PARENT=PARENT_ID \ --location=LOCATION \ --filter="FILTER" \ --mute-state=MUTE_STATE
Replace the following:
PARENT
: the scope in the resource hierarchy to which the mute rule applies,organization
,folder
, orproject
.PARENT_ID
: the ID of the parent organization, folder, or project, specified in the format oforganizations/123
,folders/456
, orprojects/789
.LOCATION
: if data residency is enabled, the Security Command Center location in which to mute or reset findings in bulk; if data residency is not enabled, use the valueglobal
.FILTER
: the expression you define to filter findings.For example, to mute all existing low-severity
OPEN_FIREWALL
andPUBLIC_IP_ADDRESS
findings in theinternal-test
project, your filter can be"category=\"OPEN_FIREWALL\" OR category=\"PUBLIC_IP_ADDRESS\" AND severity=\"LOW\" AND resource.projectDisplayName=\"internal-test\""
.MUTE_STATE
: the value that indicates whether the finding is statically muted or not. Valid values areMUTED
andUNDEFINED
. The value is set toMUTED
by default. Only set this value toUNDEFINED
if you are resetting the mute state of multiple existing findings.
Go
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Java
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
Python
The following sample uses the v1 API. To modify
the sample for v2, replace v1
with v2
and add
/locations/LOCATION
to the resource name.
For most resources, add /locations/LOCATION
to the
resource name after /PARENT/PARENT_ID
, where
PARENT
is organizations
, folders
,
or projects
.
For findings, add /locations/LOCATION
to the resource
name after /sources/SOURCE_ID
, where SOURCE_ID
is the ID of the
Security Command Center service
that issued the finding.
REST API
In the Security Command Center API, use the bulkMute
method to mute or reset
the mute state of multiple existing findings. The request body contains the
expression used to filter findings.
Unless data residency is enabled, you can use either v1 or v2 of the Security Command Center API. API v2 is available as a Preview release. When data residency is enabled, API v2 is the only available API.
If you are using Security Command Center API v1, call
bulkMute
by using the v1
endpoint:
POST https://securitycenter.googleapis.com/v1/PARENT/PARENT_ID/findings:bulkMute -d { "filter": "FILTER", "muteState": "MUTE_STATE" }
If you are using Security Command Center API v2, call
bulkMute
by using the v2
endpoint:
POST https://securitycenter.googleapis.com/v2/PARENT/PARENT_ID/locations/LOCATION/findings:bulkMute -d { "filter": "FILTER", "muteState": "MUTE_STATE" }
Replace the following:
PARENT
: the parent resource (organizations
,folders
, orprojects
).PARENT_ID
: the ID of the parent organization, folder, or project.LOCATION
: if data residency is enabled, the Security Command Center location in which to mute or reset findings in bulk; if data residency is not enabled, use the valueglobal
.FILTER
: the expression you define to filter findings.For example, to mute all existing low-severity
OPEN_FIREWALL
andPUBLIC_IP_ADDRESS
findings in theinternal-test
project, your filter can be"category=\"OPEN_FIREWALL\" OR category=\"PUBLIC_IP_ADDRESS\" AND severity=\"LOW\" AND resource.projectDisplayName=\"internal-test\""
.MUTE_STATE
: the value that indicates whether the finding is muted or not. Valid values areMUTED
orUNDEFINED
. The value is set toMUTED
by default. Only set this value toUNDEFINED
if you are resetting the mute state of multiple existing findings.
All existing findings in the resource you select, and which exactly match the
filter, are hidden. The mute
attribute for the findings is set to MUTED
.
Muting findings doesn't change their state. If active findings are muted, they are hidden but remain active until the underlying vulnerabilities, misconfigurations, or threats are resolved.
View muted findings in the Google Cloud console
You can view muted findings in the Google Cloud console by editing the finding
query to select findings that include the property value mute="MUTED"
.
For example, the following findings query displays only active findings that are muted:
state="ACTIVE"
AND mute="MUTED"
To display all active findings, both muted and unmuted, omit the
mute
attribute from the query entirely:
state="ACTIVE"
By default, the finding query in the Google Cloud console displays only findings that are not muted.
View findings muted by mute rule type
The following sections describe how to query active findings by mute rule type.
For more information on listing specific findings, see Filter findings.
Query findings muted by static mute rules
To display active findings that were muted by a static mute rule after a
specified time, use the following query and inspect the muteInitiator
attribute to determine if the finding was muted by a static mute rule.
state="ACTIVE" AND
muteInfo.staticMute.applyTime>=TIMESTAMP AND
muteInfo.staticMute.state="MUTED"
Replace the TIMESTAMP
with the date/time string that
indicates the beginning of the time period you want to query. For information
about time formats, see gcloud topic datetimes
.
Query findings muted by dynamic mute rules
To display active findings that were muted by a dynamic mute rule after a specified time, use the following query:
state="ACTIVE" AND
muteUpdateTime>=TIMESTAMP AND
contains(muteInfo.dynamicMuteRecords, muteConfig="PARENT_ID/muteConfigs/CONFIG_ID")
Replace the following:
TIMESTAMP
: The date/time string that indicates the beginning of the time period you want to query. For information about time formats, seegcloud topic datetimes
.PARENT_ID
: the ID of the parent organization, folder, or project, specified in the format oforganizations/123
,folders/456
, orprojects/789
.CONFIG_ID
: the name of the mute rule. The ID must use alphanumeric characters and hyphens and be between 1 and 63 characters.
For more information about editing finding queries, see Create or edit a findings query in the dashboard.
Finding properties related to muting
This section lists finding properties that are related to the mute state of a finding, and describes how they are impacted by mute operations:
mute
: set toUNDEFINED
when findings are created and changes in the following scenarios:MUTED
: a finding is muted manually or by a mute rule.UNMUTED
: a user unmutes a finding.
muteUpdateTime
: the time that a finding gets muted or unmuted.muteInitiator
: the identifier for the principal or mute rule that muted a finding.muteInfo
: mute information about the finding, such as mute rule type (static or dynamic) and which mute rules the finding matched.muteInfo.staticMute
: a static mute state overrides any dynamic mute rules that apply to this finding.state
: a static mute state that can be set by muting the finding directly or a static mute rule.applyTime
: time when the static mute state was applied to the finding.
muteInfo.dynamicMuteRecords
: The record of a dynamic mute rule that matches the finding.muteConfig:
the relative resource name of the mute rule, represented by the mute configuration that created the record. For example,organizations/123/muteConfigs/examplemuteconfig
.matchTime
: time when a dynamic mute rule matched the finding.
Stop notifications and exports of muted findings
If you enable finding notifications, new or updated muted findings that match your notification filters are still exported to Pub/Sub.
To stop exports and notifications for muted findings, use the mute
attribute to exclude muted findings in your NotificationConfig
filter.
For example, the following
filter only sends notifications for active findings that are not muted or where
the mute attribute hasn't been set:
FILTER="state=\"ACTIVE\" AND -mute=\"MUTED\""
What's next
Learn more about filtering finding notifications.
Look through more examples of filters you can use.