With custom modules, you can extend Security Health Analytics's detection
capabilities by creating custom detectors that scan the Google Cloud
resources and policies that you specify using rules that you define to
check for vulnerabilities, misconfigurations, or compliance violations.
The configuration or definition of a custom module, whether you create it in the
Google Cloud console or code it yourself, determines the resources that
the detector checks, the properties the detector evaluates, and the
information that the detector returns when a vulnerability or
misconfiguration is detected.
You can create custom modules for any resource or asset that Security Command Center
supports.
If you code custom module definitions yourself, you use YAML
and Common Expression Language (CEL) expressions. If you use the
Google Cloud console to create your custom modules, most of the coding
is done for you, although you do need to code the CEL expressions.
Custom modules run alongside Security Health Analytics's built-in detectors
in real-time, batch, or mixed-mode. For more information about these modes, see Security Health Analytics scan types.
During a scan, each custom detector is applied to all matching assets in each
organization, folder, or project for which it is enabled.
Findings from custom detectors are written to Security Command Center.
Custom modules offer broader detection capabilities than built-in Security Health Analytics detectors. However, custom modules lack support for some Security Command Center features that the built-in detectors provide.
Feature support
Security Health Analytics custom modules are not supported by attack path
simulations. Findings that are produced by custom modules don't include
attack exposure scores or attack paths.
Comparing detection logic
As an example of some of the things that you can do with a
custom module, compare what the built-in detector PUBLIC_SQL_INSTANCE
checks for with what you can do with a custom module.
The built-in detector PUBLIC_SQL_INSTANCE checks whether the
authorizedNetworks property of Cloud SQL instances is set to 0.0.0.0/0.
If it is, the detector generates a finding that states that the Cloud SQL
instance is open to the public, because it accepts connections from all IP
addresses.
With a custom module, you can implement more complex detection
logic to check Cloud SQL instances for things like:
IP addresses with specific prefixes, by using wildcards.
The value of the state property, which you can use to ignore instances
if the value is set to MAINTENANCE or trigger findings if the value is
something else.
The value of the region property, which you can use to trigger findings
only for instances with public IP addresses in specific regions.
Required IAM roles and permissions
IAM roles determine the actions that you can perform
with Security Health Analytics custom modules.
The following table contains a list of Security Health Analytics custom
module permissions that are required as well as the predefined IAM
roles that include them.
You can use the Google Cloud console or Security Command Center API to apply
these roles at the organization, folder, or project level.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-06-10 UTC."],[],[]]
