Google Cloud Security Command Center Notifications in Slack with Google Threat Intelligence Enrichment

Stay on top of your Google Cloud security without drowning in alert noise.

In my previous post on the Top 10 Organization Policy Constraints for Google Cloud, I shared the preventive guardrails I recommend to stop risky configurations before they get deployed. But even with solid Organization Policies in place, you still need good visibility into what is already running in your environment. Think of misconfigurations on existing resources, vulnerable packages in your containers or VMs, and active threats detected in your logs.

In Google Cloud, Security Command Center (SCC) is the native tool for this. It brings together findings from Security Health Analytics, Container Threat Detection, Event Threat Detection, and vulnerability scanning in one place.

We see a lot of organizations that have Security Command Center enabled, but nobody is actively looking at the console day to day. A while back, I created a solution on my GitHub (google-cloud-scc-findings-notifications) to push SCC findings straight to a Slack channel using Pub/Sub, a Cloud Run function, and Terraform.

I just updated the repository with a couple of improvements based on what we run into in practice: better filtering and prioritization for CVEs, and IoC and vulnerability enrichment using Google Threat Intelligence (GTI).

What the Alerts Look Like in Slack

Here are two examples from the repo showing what the notifications look like in Slack when GTI enrichment is enabled.

1. Exploitable CVE Alert (CVE-2021-44228 Log4Shell)

2. Threat Alert with GTI IoC Enrichment (GRIDTIDE / UNC2814 Espionage Campaign)

The “Why”: Forwarding Every “High” and “Critical” Finding Causes Alert Fatigue

When teams first wire SCC notifications to Slack or email, they usually filter on severity="CRITICAL" OR severity="HIGH" and call it a day. In a real Google Cloud organization, that creates two problems:

1. CVE alert fatigue: If a base container image or OS package has a HIGH or CRITICAL CVE, SCC reports a VULNERABILITY finding for every workload and project where that package exists—even when there is no known exploit in the wild. Your Slack channel gets flooded with hundreds of duplicate alerts until engineers mute the channel.
2. Manual IoC triage: When Event Threat Detection flags suspicious activity (such as outbound C2 traffic or a suspicious binary), the raw finding only gives you an IP, domain, or SHA-256 hash. Your first step is always copying those Indicators of Compromise (IoCs) into VirusTotal or Google Threat Intelligence to verify if they are truly malicious.

What I Updated

1. Smarter Filtering and CVE Prioritization

First, I updated the Terraform setup to use the SCC v2 Notification API (google_scc_v2_organization_notification_config) with a filter that separates active threats from unexploited CVEs:

(severity="HIGH" OR severity="CRITICAL")
AND state="ACTIVE"
AND -mute="MUTED"
AND (
  finding_class!="VULNERABILITY"
  OR vulnerability.cve.id=""
  OR (
    (
      vulnerability.cve.exploitation_activity="WIDE"
      OR vulnerability.cve.exploitation_activity="AVAILABLE"
      OR vulnerability.cve.exploitation_activity="CONFIRMED"
    )
    AND (
      vulnerability.cve.impact="CRITICAL"
      OR vulnerability.cve.impact="HIGH"
    )
  )
)

• All active HIGH and CRITICAL threats and misconfigurations come through immediately (THREAT, MISCONFIGURATION, TOXIC_COMBINATION).
• CVEs are filtered on real-world exploitability: You only get paged in Slack when a CVE has WIDE, AVAILABLE, or CONFIRMED exploitation activity and CRITICAL or HIGH impact.
• Organization-wide CVE deduplication: If an exploitable CVE appears across 40 projects during a scan, the Cloud Run function deduplicates repeated alerts for the same CVE within a configurable cooldown window (cve_dedup_window_seconds, 1 hour by default) and links to all affected resources in SCC.

2. Google Threat Intelligence (GTI) Enrichment

When you configure an optional GTI API key (powered by Mandiant and VirusTotal threat data), the Cloud Run function automatically enriches findings before posting to Slack:

• For CVE findings: Pulls the GTIG risk rating, priority (P0), exploitation status, EPSS score, CISA KEV status, known ransomware usage, and remediation guidance.
• For Threat findings (IoCs): Queries extracted IPs, domains, and SHA-256 hashes against GTI / VirusTotal to show how many security vendors flag the indicator as malicious (e.g., MALICIOUS 35/76), the IP’s ASN/country, and known threat campaign attribution.

How It Works Under the Hood

The architecture is serverless, least-privilege, and deployed in two Terraform stages:

1. SCC v2 Notification Config & Pub/Sub: Streams matching organization-level findings to Pub/Sub in real time.
2. Eventarc & Cloud Run (2nd Gen): Triggers a Python 3.13 Cloud Run function locked down with ALLOW_INTERNAL_ONLY ingress and dedicated build/runtime service accounts.
3. Cloud KMS & Secret Manager: Your Slack bot token and optional GTI API key are encrypted locally with Cloud KMS (infra/kms), stored only as ciphertext in terraform.tfvars, and mounted into the function from Secret Manager.
4. Resilient Delivery: Transient Slack/network errors (429, 5xx) trigger an Eventarc retry, while permanent errors are logged once as ERROR without looping.

Get the Code on GitHub

The repository includes the full two-stage Terraform setup and realistic test fixtures (Log4Shell and GRIDTIDE/UNC2814) that you can send straight to your Slack channel from your terminal with --send before deploying:

👉 github.com/jorgecalo/google-cloud-scc-findings-notifications

(Using Microsoft Teams instead of Slack? Read Google Cloud Security Command Center Notifications in Microsoft Teams or grab the code at github.com/jorgecalo/google-cloud-scc-findings-notifications-teams.)

Feel free to reach out via LinkedIn or my contact page if you have any questions!