Detection as code & response

Log metrics, Pub/Sub pipelines, auto-response.

Detection is only as good as what happens after a finding fires. A mature GCP setup treats detections as code and wires signals into an automated pipeline that correlates, prioritizes, and responds — the difference between spotting an incident and containing one.

Detection as code

Codify your custom detections — log-based metrics and alerting policies on sensitive actions (SetIamPolicy on a privileged role, cloudkms keys disable, mass storage.objects.get), SCC finding filters, and remediation logic — in version control, tested and reviewed like software. That makes rules auditable, repeatable across the org, and hard to silently weaken. Log-based metric alerts on abnormal use of permitted actions catch what per-permission checks never will: a legitimate action at an illegitimate volume or pattern.

# Log-based metric: count grants of the Owner role via SetIamPolicy.
gcloud logging metrics create owner-grants \
  --description="Owner role granted" \
  --log-filter='protoPayload.methodName="SetIamPolicy" AND
    protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner" AND
    protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"'
# Then attach an alerting policy that pages on any nonzero value.

Route, respond, and rehearse

Send findings and alerts through Pub/Sub to a SIEM (Chronicle/Google SecOps or your own) for correlation across sources, and to Cloud Functions or workflows for automated first response — isolate a resource, disable a key, revoke a session. A high-severity SCC finding can trigger containment before an analyst opens the console. Wrap it all in rehearsed runbooks so the first real run of "compromised service account" is a drill you have practiced, not an improvisation under pressure.