Using Security Health Analytics

This page explains how to manage Security Health Analytics findings using Security Command Center.

Security Health Analytics is a built-in service in Security Command Center that scans the resources in your cloud environment and generates findings for any misconfigurations that it detects.

To receive Security Health Analytics findings, the service must be enabled in Security Command Center Services settings.

To create findings related to Amazon Web Services (AWS) resources, Security Command Center must be connected to AWS.

Findings from Security Health Analytics detectors are searchable in the Google Cloud console and using the Security Command Center API.

Before you begin

To get the permissions that you need to manage Security Health Analytics findings, ask your administrator to grant you the following IAM roles on your organization, folder, or project:

Enable and disable detectors

Disabling detectors can impact the state of active findings. When a detector is disabled, existing findings are automatically marked as inactive.

When you activate Security Command Center at the organization level, you can disable Security Health Analytics or specific detectors for specific folders or projects. If Security Health Analytics or detectors are turned off for folders and projects, any existing findings attached to assets in those resources are marked as inactive.

The following Security Health Analytics detectors for Google Cloud are disabled by default:

Console

If the Security Health Analytics service is enabled, you can set the enablement state of its individual modules.

In the Google Cloud console, go to the Modules page for Security Health Analytics.
Go to Modules
Select your organization or project.
On the Modules tab, in the Status column, select the current status of the module that you want to enable or disable, and then select one of the following:
- Enable: Enable the module.
- Disable: Disable the module.

gcloud

The gcloud scc manage services update command updates the state of a Security Command Center service or module.

Before using any of the command data below, make the following replacements:

RESOURCE_TYPE: the type of resource to update (organization, folder, or project).
RESOURCE_ID: the numeric identifier for the organization, folder, or project to update. For projects, you can also use the alphanumeric project ID.
MODULE_NAME: the name of the module to enable or disable. For valid values, see Security Health Analytics built-in detectors.
NEW_STATE: ENABLED to enable the module; DISABLED to disable the module; or INHERITED to inherit the enablement status of the parent resource (valid only for projects and folders).

Save the following content in a file called request.json:

{
  "MODULE_NAME": {
    "intendedEnablementState": "NEW_STATE"
  }
}

Execute the gcloud scc manage services update command:

Linux, macOS, or Cloud Shell

gcloud scc manage services update security-health-analytics \
    --RESOURCE_TYPE=RESOURCE_ID \
    --module-config-file=request.json

Windows (PowerShell)

gcloud scc manage services update security-health-analytics `
    --RESOURCE_TYPE=RESOURCE_ID `
    --module-config-file=request.json

Windows (cmd.exe)

gcloud scc manage services update security-health-analytics ^
    --RESOURCE_TYPE=RESOURCE_ID ^
    --module-config-file=request.json

You should receive a response similar to the following. For brevity, this example shows a subset of all Security Health Analytics modules.

effectiveEnablementState: ENABLED
intendedEnablementState: ENABLED
modules:
  ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED:
    effectiveEnablementState: DISABLED
  ACCESS_KEYS_ROTATED_90_DAYS_LESS:
    effectiveEnablementState: ENABLED
  ACCESS_TRANSPARENCY_DISABLED:
    effectiveEnablementState: ENABLED
  ADMIN_SERVICE_ACCOUNT:
    effectiveEnablementState: ENABLED
  ALLOYDB_AUTO_BACKUP_DISABLED:
    effectiveEnablementState: DISABLED
name: projects/1070293378382/locations/global/securityCenterServices/SECURITY_HEALTH_ANALYTICS
updateTime: '2026-02-11T21:15:41.269584764Z'

REST

The Security Command Center Management API's RESOURCE_TYPE.locations.securityCenterServices.patch method updates the state of a Security Command Center service or module.

Before using any of the request data, make the following replacements:

RESOURCE_TYPE: the type of resource to update (organizations, folders, or projects).
QUOTA_PROJECT: the project ID to use for billing and quota tracking.
RESOURCE_ID: the numeric identifier for the organization, folder, or project to update. For projects, you can also use the alphanumeric project ID.
MODULE_NAME: the name of the module to enable or disable. For valid values, see Security Health Analytics built-in detectors.
NEW_STATE: ENABLED to enable the module; DISABLED to disable the module; or INHERITED to inherit the enablement status of the parent resource (valid only for projects and folders).

HTTP method and URL:

PATCH https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/security-health-analytics?updateMask=modules

Request JSON body:

{
  "modules": {
    "MODULE_NAME": {
      "intendedEnablementState": "NEW_STATE"
    }
  }
}

To send your request, expand one of these options:

curl (Linux, macOS, or Cloud Shell)

Note: The following command assumes that you have logged in to the gcloud CLI with your user account by running gcloud init or gcloud auth login , or by using Cloud Shell, which automatically logs you into the gcloud CLI . You can check the currently active account by running gcloud auth list.

Save the request body in a file named request.json, and execute the following command:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "x-goog-user-project: QUOTA_PROJECT" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/security-health-analytics?updateMask=modules"

PowerShell (Windows)

Note: The following command assumes that you have logged in to the gcloud CLI with your user account by running gcloud init or gcloud auth login . You can check the currently active account by running gcloud auth list.

Save the request body in a file named request.json, and execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred"; "x-goog-user-project" = "QUOTA_PROJECT" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/security-health-analytics?updateMask=modules" | Select-Object -Expand Content

You should receive a response similar to the following. For brevity, this example shows a subset of all Security Health Analytics modules.

{
  "effectiveEnablementState": "ENABLED",
  "intendedEnablementState": "ENABLED",
  "modules": {
    "ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED": {
      "effectiveEnablementState": "DISABLED"
    },
    "ACCESS_KEYS_ROTATED_90_DAYS_LESS": {
      "effectiveEnablementState": "ENABLED"
    },
    "ACCESS_TRANSPARENCY_DISABLED": {
      "effectiveEnablementState": "ENABLED"
    },
    "ADMIN_SERVICE_ACCOUNT": {
      "effectiveEnablementState": "ENABLED"
    },
    "ALLOYDB_AUTO_BACKUP_DISABLED": {
      "effectiveEnablementState": "DISABLED"
    }
  },
  "name": "projects/1070293378382/locations/global/securityCenterServices/SECURITY_HEALTH_ANALYTICS",
  "updateTime": "2026-02-11T21:15:41.269584764Z"
}

Filtering findings in the Google Cloud console

A large organization might have many vulnerability findings across their deployment to review, triage, and track. By using filters that are available on the Security Command Center Vulnerabilities and Findings pages in the Google Cloud console, you can focus on the highest severity vulnerabilities across your organization, and review vulnerabilities by asset type, project, and more.

Manage findings with cases

Security Command Center automatically opens a case in the Security Operations console for threats, toxic combinations, and findings related to toxic combinations. A single case can contain multiple related findings.

Use the case, which can be integrated with your preferred ticketing system, to manage the investigation and remediation of findings, by assigning owners, reviewing related information, and, with playbooks, automate your response workflow.

If a finding has a corresponding case, you can find a link to its case on the details page of the finding. Open the details page for a finding from the Findings page.

Mute findings

To control the volume of findings in Google Cloud console, you can manually or programmatically mute individual findings, or create mute rules that automatically mute findings based on filters you define. There are two types of mute rules you can use to control finding volume:

We recommend using dynamic mute rules exclusively to reduce the number of findings you review manually. To avoid confusion, we don't recommend using both static and dynamic mute rules simultaneously. For a comparison of the two rule types, see Types of mute rules.

Findings that you mute in the Google Cloud console are hidden and silenced, but continue to be logged for audit and compliance purposes. You can view muted findings or unmute them at any time. To learn more, see Mute findings in Security Command Center.

Marking assets and findings with security marks

You can add custom properties to findings and assets in Security Command Center by using security marks. Security marks enable you to identify high-priority areas of interest like production projects, tag findings with bug and incident tracking numbers, and more.

Add assets to allowlists

Although it is not a recommended method, you can suppress unneeded findings by adding dedicated security marks to assets so that the Security Health Analytics detectors don't create security findings for those assets.

The recommended and most effective approach for controlling finding volume is to Mute findings. Mute findings that you don't need to review, because they are either for assets that are isolated or because the findings fall within acceptable business parameters.

When you apply dedicated security marks to assets, the assets are added to an allowlist in Security Health Analytics, which marks any findings for those assets as resolved during the next batch scan.

Dedicated security marks must be applied directly to assets, not findings, as described in How allowlists work later on this page. If you apply a mark to a finding, the underlying asset can still generate findings.

How allowlists work

Each Security Health Analytics detector has a dedicated mark type for allowlists, in the form of allow_FINDING_TYPE:true. Adding this dedicated mark to an asset that is supported by Security Command Center lets you exclude the asset from the detection policy.

For example, to exclude the finding type SSL_NOT_ENFORCED, set the security mark, allow_ssl_not_enforced:true, on the related Cloud SQL instance. The specified detector won't create findings for marked assets.

Asset types

Security marks are only updated during batch scans, not real-time scans. If a dedicated security mark is removed, and the asset has a vulnerability, it might take up to 24 hours before the mark is deleted and a finding is written.

Special-case detector: Customer Supplied Encryption Keys

The DISK_CSEK_DISABLED detector isn't on by default. To use this detector, you must mark the assets for which you want to use self-managed encryption keys.

To enable the DISK_CSEK_DISABLED detector for specific assets, apply the security mark enforce_customer_supplied_disk_encryption_keys to the asset with a value of true.

Viewing active finding count by finding type

You can use the Google Cloud console or the Google Cloud CLI to view active finding counts by finding type.

Console

The Google Cloud console lets you view a count of active findings for each finding type.

To view Security Health Analytics findings by finding type, do the following:

To display Security Health Analytics findings, go to the legacy Vulnerabilities page.

Go to Vulnerabilities
To sort findings by the number of active findings for each finding type, click the Active column header.

gcloud

To use the gcloud CLI to get a count of all active findings, you query Security Command Center to get the Security Health Analytics source ID. Then you use the source ID to query the active findings count.

Step 1: Get the source ID

To get the source ID, run one of the following commands:

If you activated Security Command Center at the organization level, run the following command:

gcloud scc sources describe organizations/ORGANIZATION_ID \
    --source-display-name="Security Health Analytics"

If you activated Security Command Center at the project level, run the following command:

gcloud scc sources describe projects/PROJECT_ID \
    --source-display-name="Security Health Analytics"

If you haven't already enabled the Security Command Center API, you are prompted to enable it. When the Security Command Center API is enabled, run the previous command again. The command should display output like the following:

description: Scans for deviations from a GCP security baseline.
displayName: Security Health Analytics
name: organizations/ORGANIZATION_ID/sources/SOURCE_ID

Note the SOURCE_ID to use in the next step.

Step 2: Get the active findings count

Use the SOURCE_ID you noted in the previous step to filter findings from Security Health Analytics. The following gcloud CLI commands return a count of findings by category.

If you activated Security Command Center at the organization level, run the following command:

gcloud scc findings group organizations/ORGANIZATION_ID/sources/SOURCE_ID \
    --group-by=category --page-size=PAGE_SIZE

If you activated Security Command Center at the project level, run the following command:

gcloud scc findings group projects/PROJECT_ID/sources/SOURCE_ID \
    --group-by=category --page-size=PAGE_SIZE

You can set the page size to any value up to 1000. The command should display output like the following, with results from your organization:

groupByResults:
- count: '1'
properties:
  category: MFA_NOT_ENFORCED
- count: '3'
properties:
  category: ADMIN_SERVICE_ACCOUNT
- count: '2'
properties:
  category: API_KEY_APIS_UNRESTRICTED
- count: '1'
properties:
  category: API_KEY_APPS_UNRESTRICTED
- count: '2'
properties:
  category: API_KEY_EXISTS
- count: '10'
properties:
  category: AUDIT_CONFIG_NOT_MONITORED
- count: '10'
properties:
  category: AUDIT_LOGGING_DISABLED
- count: '1'
properties:
  category: AUTO_UPGRADE_DISABLED
- count: '10'
properties:
  category: BUCKET_IAM_NOT_MONITORED
- count: '10'
properties:
  category: BUCKET_LOGGING_DISABLED
nextPageToken: TOKEN
readTime: '2023-08-05T21:56:13.862Z'
totalSize: 50

Programmatically manage findings

Using the Google Cloud CLI and the Security Command Center client libraries, you can automate almost anything you can do with Security Command Center in the Google Cloud console. You can also remediate many findings using the gcloud CLI. For more information, review the documentation for the resource types described in each finding:

To export or list assets programmatically, use the Cloud Asset Inventory API. For more information, see Export asset history and metadata.

The asset methods and fields of the Security Command Center API are deprecated and will be removed on or after June 26, 2024.

Until they are removed, users who activated Security Command Center before June 26, 2023 can use the asset methods of the Security Command Center API to list assets, but these methods support only the assets that Security Command Center supports.

For information about using the deprecated asset API methods, see listing assets.

Scanning projects protected by a service perimeter

If you have a service perimeter that blocks access to certain projects and services, you must grant the Security Command Center service account inbound access to that service perimeter. Otherwise, Security Health Analytics can't produce findings related to the protected projects and services.

Console

Navigate to the service perimeter

In the Google Cloud console, go to the VPC Service Controls page.

Go to VPC Service Controls
Select your organization.
In the drop-down list, select the access policy that contains the service perimeter that you want to grant access to.

The service perimeters associated with the access policy appear in the list.
Click the name of the service perimeter that you want to update.

To find the service perimeter you need to modify, you can check your logs for entries that show RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER violations. In those entries, check the servicePerimeterName field:
```
accessPolicies/ACCESS_POLICY_ID/servicePerimeters/SERVICE_PERIMETER_NAME
```
Click Edit.

Add an ingress rule

Click Ingress policy.
Click Add an ingress rule.
In the From section, set the following details:
1. For Identities > Identity, select Select identities & groups.
2. Click Add identities.
3. Enter the email address that identifies the Cloud Security Command Center Service Agent. This address has the following format:
```
service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com
```
  Replace ORGANIZATION_ID with your organization ID.
4. Select the service agent or press ENTER, and then click Add identities.
In the To section, set the following details:
1. For Resources > Projects, select All projects.
2. For Operations or IAM roles, select All operations, or select specific services for which VPC Service Controls violations appear.
Click Save.

gcloud

If a quota project isn't already set, then set it. Choose a project that has the Access Context Manager API enabled.
```
gcloud config set billing/quota_project QUOTA_PROJECT_ID
```
Replace QUOTA_PROJECT_ID with the ID of the project that you want to use for billing and quota.
Create a file named ingress-rule.yaml with the following contents:
```
- ingressFrom:
    identities:
    - serviceAccount:service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - serviceName: '*'
    resources:
    - '*'
```
Alternatively, you can use operations to specify services for which VPC Service Controls violations appear and resources to specify the project that appeared in the finding.

Replace ORGANIZATION_ID with your organization ID.
Add the ingress rule to the perimeter:
```
gcloud access-context-manager perimeters update PERIMETER_NAME \
    --set-ingress-policies=ingress-rule.yaml
```
Replace the following:
- PERIMETER_NAME: the name of the perimeter. For example, accessPolicies/1234567890/servicePerimeters/example_perimeter.
  
  To find the service perimeter you need to modify, you can check your logs for entries that show RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER violations. In those entries, check the servicePerimeterName field:
```
accessPolicies/ACCESS_POLICY_ID/servicePerimeters/SERVICE_PERIMETER_NAME
```

For more information, see Ingress and egress rules.

Using Security Health Analytics Stay organized with collections Save and categorize content based on your preferences.

Before you begin

Enable and disable detectors

Console

gcloud

Linux, macOS, or Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

REST

curl (Linux, macOS, or Cloud Shell)

PowerShell (Windows)

Filtering findings in the Google Cloud console

Manage findings with cases

Mute findings

Marking assets and findings with security marks

Add assets to allowlists

How allowlists work

Asset types

Special-case detector: Customer Supplied Encryption Keys

Viewing active finding count by finding type

Console

gcloud

Step 1: Get the source ID

Step 2: Get the active findings count

Programmatically manage findings

Scanning projects protected by a service perimeter

Console

Navigate to the service perimeter

Add an ingress rule

gcloud

What's next