TTechclick ⚡ XP 0% All lessons
GCP · SCC · Security Command CenterInteractive · L1 / L2 / L3

GCP Security Command Center: — One Ranked View of Every Cloud Risk

Forty projects, hundreds of buckets, a firewall someone opened to 0.0.0.0/0 last Tuesday — and no single place that says "fix THIS first." Security Command Center is that single place: it inventories your whole Google Cloud estate, scans it for misconfigurations, watches the logs for live threats, and stacks everything into one severity-ranked list. This lesson builds the mental model the rest of your GCP security work stands on.

📅 2026-06-11 · ⏱ 13 min · 3 live demos · 4 infographics · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

GCP Security Command Center for L1/L2 engineers and the Professional Cloud Security Engineer exam: tiers, the detectors (Security Health Analytics, Event Threat Detection), the findings model, mute rules, Pub/Sub + Chronicle export, and a worked triage pass.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

What SCC is

Inventory, misconfig, threats, web scan — and the tiers.

 2

The detectors

SHA vs ETD, severity, MITRE and compliance maps.

 3

Working findings

The model, mute rules, export to SIEM, auto-fix.

 4

A posture pass

Triage, remediate, watch it clear, set up export.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. A teammate left a Cloud Storage bucket public last week. Which SCC detector is most likely to flag that as a misconfiguration?

Answered in What SCC is.

2. You're drowning in 4,000 low-severity findings for a known test project. What's the right SCC tool to quiet them without deleting them?

Answered in Working findings.

3. After you fix a public bucket, how does the finding usually leave the ACTIVE list in SCC?

Answered in The detectors.

Most engineers think…

Most engineers first hear "Security Command Center" and picture just another dashboard — a pretty wall of red boxes you glance at once a week and then ignore because everything is always on fire.

Wrong — and that mindset is exactly how a real breach hides in plain sight. SCC's actual job is to turn an un-prioritisable mess into a ranked, routable work queue: it inventories every asset, runs Security Health Analytics to catch misconfigurations before attack, runs Event Threat Detection on your logs to catch threats during attack, stamps each finding with a severity, a MITRE tactic and a CIS control, and pushes the real ones to your SIEM. The dashboard is the cover of the book; the finding lifecycle and the mute-and-export loop are the chapters.

① What Security Command Center actually is

Meet Sneha, an L1 cloud security engineer at Flipkart. Her org has 40-odd Google Cloud projects across teams she's never met. On Monday her manager forwards a one-line email: "are we exposed anywhere?" Without a central tool, Sneha's only answer is to log into each project, eyeball the buckets, the firewall rules and the IAM bindings by hand, and hope she didn't miss one. That is the gap Security Command Center (SCC) fills: one screen that already knows every asset and what's wrong with it.

SCC does four jobs at once. First, asset inventory: it keeps a live list of everything you own so nobody can hide a rogue project. Second, misconfiguration findings via Security Health Analytics — public buckets, open firewalls, weak IAM. Third, threat detection: Event Threat Detection reads your logs for live attacks, and Container/VM Threat Detection watch the runtime. Fourth, Web Security Scanner probes your web apps. Every one of those writes into one findings list.

👉 So far: SCC = inventory + misconfig + threats + web scan, all feeding one list. Next: the three tiers, because what you actually get depends on which one is switched on.

Now the catch that trips up every new engineer: features depend on the tier. SCC ships in three tiers. Standard gives you asset inventory and a basic slice of Security Health Analytics and Web Security Scanner — good for a Google-Cloud-only shop with light needs. Premium adds the real value: full Security Health Analytics, Event Threat Detection, attack-path simulation and compliance reports. Enterprise wraps it into a full multi-cloud CNAPP that also covers AWS and Azure, with Chronicle Security Operations built in. If a threat finding isn't showing up, the first question is always: which tier is this org on?

Figure 1 — SCC architecture — one ranked list
Security Command Center is the one ranked window over every cloud risk — misconfig, threat and exposure feeding one Findings list Architecture diagram of Google Cloud Security Command Center. On the left, a Google Cloud organization with projects, buckets, VMs, firewall rules and IAM. Built-in detection services scan that estate: Security Health Analytics for misconfigurations, Event Threat Detection reading Cloud Audit and other logs, Container Threat Detection on GKE, VM Threat Detection on Compute Engine, and Web Security Scanner on App Engine apps. Each service writes findings into one central Findings store, which SCC ranks by severity and shows in a single dashboard, then exports to Pub/Sub and Chronicle SIEM. Red marks untrusted or risky resources, blue the trusted SCC plane, amber the detectors as decision points, green the cleared state. One organization, many detectors, ONE ranked Findings list Your Google Cloud org public Cloud Storage bucket 0.0.0.0/0 firewall on 22 over-broad IAM role Compute Engine VMs GKE containers Cloud Audit Logs asset inventory watches it all Security Health Analyticsmisconfig scan (CIS-mapped) Event Threat Detectionreads logs for threats Container + VM Threat Det.runtime threats Web Security ScannerXSS / outdated libs SCC Findingsone ranked list CRITICAL · public bucket HIGH · open SSH MEDIUM · IAM grant Pub/Sub Chronicle SIEM rank by severity → fix the top one first risky / untrustedSCC / trusteddetector / decisionkey insightcleared / exported
Follow the amber detectors fanning out across your org (left) into the single blue Findings list (right), which ranks by severity and exports green to Pub/Sub and Chronicle. Notice every detector ends in the SAME list.

The four jobs of SCC, one tap each

Tap each card — these are the four things SCC does that no single GCP console page does for you.

📒
Asset inventory
tap to flip

A live catalogue of every resource across all projects. So: nobody can hide a rogue project or a forgotten public bucket.

🔧
Misconfig scan
tap to flip

Security Health Analytics checks config against CIS/PCI. So: you find the open door before an attacker does.

🚨
Threat detection
tap to flip

Event/Container/VM Threat Detection read logs + runtime. So: you catch the burglar who's already moving inside.

🕷️
Web-app scan
tap to flip

Web Security Scanner crawls your apps for XSS and stale libs. So: app-layer holes show up next to infra ones.

Daily-life analogy — the society gate-pass register

Think of SCC as the security desk register in a Mumbai housing society. The asset inventory is the master list of every flat and resident (no unknown occupants). Security Health Analytics is the guard's nightly round checking which doors and gates were left unlocked (misconfig — before anyone breaks in). Event Threat Detection is the CCTV flagging someone walking into a flat at 3 a.m. who shouldn't be there (live threat). And the findings list is the single complaint register the secretary reads top-down — most serious entry first.

Quick check · Q1 of 10

Rahul at Infosys turns on SCC Standard and is puzzled that Event Threat Detection findings (like 'IAM Anomalous Grant') never appear. What's the most likely reason?

Correct: a. Event Threat Detection is a Premium/Enterprise feature; Standard gives asset inventory plus a basic slice of Security Health Analytics and Web Security Scanner. Asset inventory is required, not something you delete; ETD absolutely runs on GCP logs; and Standard doesn't ship a default mute rule that hides ETD — it simply doesn't include ETD.

Pause & Predict

Predict: SCC didn't 'discover' a vulnerability — it just inventoried a public bucket and an open firewall rule that have existed for months. So why is a tool that mostly reports things you could have found yourself still worth the licence? Type your guess.

Answer: Because the value isn't discovery, it's PRIORITISATION AT SCALE. Any one finding you could spot by hand; the problem is you have 40 projects and thousands of resources, and no human can keep them all in their head. SCC's win is that it watches everything continuously, ranks by severity, maps each issue to a MITRE tactic and a CIS control, and gives you ONE list to work top-down — plus it catches the new public bucket someone creates at 2 a.m. tomorrow, which manual review never would.

② The detectors — what finds what, and how it's scored

The two detectors you'll touch most are Security Health Analytics (SHA) and Event Threat Detection (ETD), and the single biggest concept here is that they do opposite jobs. SHA is a config scanner: it looks at the state of your resources on a schedule and asks "is this set up safely?" ETD is a log reader: it watches behaviour in near real time and asks "is something bad happening right now?" SHA finds the unlocked door; ETD spots the burglar already inside.

SHA's findings are CIS-mapped misconfigurations. The three you'll see daily: PUBLIC_BUCKET_ACL (a Cloud Storage bucket readable by allUsers), OPEN_FIREWALL (a VPC rule allowing 0.0.0.0/0 to a sensitive port like SSH 22 or RDP 3389), and weak-IAM categories such as NON_ORG_IAM_MEMBER (a Gmail account granted a role) or a primitive Owner binding. Each carries a default severity — a public bucket is typically HIGH, an open SSH rule HIGH, a stray editor binding MEDIUM.

👉 So far: SHA = config misconfigs (CIS-mapped). Next: ETD's log-based threats and how every finding gets a MITRE tactic and a benchmark stamped on it.

ETD reads streaming logs — Cloud Audit Logs, VPC Flow Logs, Cloud DNS — and matches them against threat rules. Classic categories: Persistence: IAM Anomalous Grant (someone suddenly grants a sensitive role to an external account), Malware: Cryptomining (a VM phones a known mining pool), and Exfiltration: BigQuery Data Extraction (a huge export of a dataset to an external destination). Because these are behaviours, ETD maps them to MITRE ATT&CK tactics, so a finding tells you not just what but where in the attack you are.

Every finding, from either detector, carries the same scoring scaffolding: a severity (so the list ranks itself), a MITRE tactic for threats, and a compliance mapping (CIS, PCI-DSS, NIST 800-53) for misconfigs. That's why one SCC screen serves two audiences at once: the on-call engineer who wants the most dangerous thing first, and the auditor who wants to know which CIS control is failing.

Figure 2 — SHA vs ETD — open door vs burglar inside
Security Health Analytics finds the open door before anyone walks in; Event Threat Detection spots the burglar already inside A two-column comparison of the two main SCC detectors. Left, Security Health Analytics: it is a config scanner that runs on a schedule, looks at the state of your resources, and finds misconfigurations like a public bucket, an open firewall or a weak IAM role before any attack happens. It is preventive and maps to CIS benchmarks. Right, Event Threat Detection: it reads streaming logs in near real time, looks at behaviour, and finds active threats like an anomalous IAM grant, cryptomining or data exfiltration while an attack is in progress. It is detective and maps to MITRE ATT&CK tactics. Amber marks the decision detectors, red the risky findings. Two detectors, two jobs — the open door vs the burglar inside Security Health Analytics Misconfiguration scanner — PREVENTIVE • Looks at the STATE of resources • Runs on a schedule (batch + real-time) • Maps to CIS / PCI / NIST benchmarks Example findings: PUBLIC_BUCKET_ACL OPEN_FIREWALL (0.0.0.0/0 → 22) NON_ORG_IAM_MEMBER (weak IAM) finds the door left open — before the break-in Event Threat Detection Log-based threat detector — DETECTIVE • Reads streaming logs (Audit, DNS, VPC) • Looks at BEHAVIOUR, near real-time • Maps to MITRE ATT&CK tactics Example findings: Persistence: IAM Anomalous Grant Malware: Cryptomining Bad IP Exfiltration: BigQuery Data Extraction spots the burglar already moving inside You need BOTH — config hygiene AND behaviour watch risky findingSCC / trusteddetector / decisionkey insightcleared
Read both columns. Left (amber): Security Health Analytics scans config state, CIS-mapped, preventive. Right (blue): Event Threat Detection reads logs, MITRE-mapped, detective. The point: you need BOTH.
gcloud — list the current HIGH/CRITICAL active findings (Security Health Analytics source)
gcloud scc findings list "organizations/123456789012" \
  --filter='state="ACTIVE" AND severity="HIGH"' \
  --format='table(category, resourceName, severity, state)'
Expected output
CATEGORY               RESOURCE_NAME                                              SEVERITY  STATE
PUBLIC_BUCKET_ACL      //storage.googleapis.com/flipkart-invoices-prod            HIGH      ACTIVE
OPEN_FIREWALL          //compute.googleapis.com/.../firewalls/allow-ssh-any       HIGH      ACTIVE
NON_ORG_IAM_MEMBER     //cloudresourcemanager.googleapis.com/projects/pay-api     MEDIUM    ACTIVE
Common mistake — "SCC shows zero threats, so we're clean"

Symptom: a team on SCC Standard reports "no threats found" and assumes they're safe. Cause: Event Threat Detection, Container Threat Detection and VM Threat Detection are Premium/Enterprise features — on Standard they simply aren't running, so of course there are zero threat findings. A second trap: ETD needs the right logs enabled (Cloud Audit Data Access logs are off by default). Fix: confirm the tier in SCC → Settings → Services, and enable the audit-log types ETD depends on, or you get silence that looks like safety.

Quick check · Q2 of 10

Priya at PhonePe sees a finding: category 'Exfiltration: BigQuery Data Extraction', severity HIGH, from Event Threat Detection. Which statement is correct about what this tells her?

Correct: c. ETD is a log/behaviour detector and tags threats with MITRE ATT&CK tactics — 'Exfiltration' is a MITRE tactic, telling Priya an active attack stage, not a static config gap. SHA (not ETD) finds misconfigs; this is a threat, not a CIS control failure; and ETD is a Premium/Enterprise feature, not Standard.

Pause & Predict

Predict: Security Health Analytics flags a bucket as PUBLIC_BUCKET_ACL the moment it's made public, but if an attacker then downloads 10 GB from it, will SHA raise a second finding about the download? Type your guess.

Answer: No — and this is the whole reason you need both detectors. SHA only looks at CONFIGURATION STATE (is the bucket public?), not at activity. The actual data being pulled out is a BEHAVIOUR, which is Event Threat Detection's job (it would read the access/audit logs and could raise an exfiltration-style finding). SHA tells you the door is open; ETD tells you someone walked through it. Relying on SHA alone means you see the open door but never the theft.

③ Working findings — the model, mute rules, export & auto-fix

To work findings without losing your mind you have to read the finding model. Four fields matter. Source = which detector raised it (Security Health Analytics, Event Threat Detection, or a third party). Category = the specific issue (OPEN_FIREWALL, Persistence: IAM Anomalous Grant). State = ACTIVE (still true) or INACTIVE (resolved / no longer seen). And severity drives the ranking. Learn to say a finding out loud as "source / category / severity / state" and triage stops feeling like guesswork.

On Premium/Enterprise you also get attack-path and exposure analysis. Instead of 500 equal-looking findings, SCC scores how an attacker could chain them — open SSH on a VM that holds an over-broad role that can reach your production database — and tells you the one fix that breaks the chain. That turns a flat list into a 'fix this single thing first' answer, which is exactly how a real incident gets prioritised.

👉 So far: read a finding as source/category/severity/state; Enterprise adds attack-path scoring. Next: cutting the noise with mute rules, then routing the real ones out.

The real-world problem is volume. A fresh SCC org can surface thousands of low findings — a test project full of intentionally-open services, a sandbox with public demo data. The fix is a mute rule. There are two kinds: a static mute rule hides matching findings indefinitely, and a dynamic mute rule mutes them temporarily (great for an accepted-risk you'll revisit). You mute by filter — e.g. all OPEN_FIREWALL findings in the sandbox-* projects. The discipline: mute is not fix — a muted finding is still a real hole, you've just agreed it's out of scope for now.

Figure 3 — The lifecycle of one finding
A finding is born from a log or scan, gets ranked and routed, then dies when you remediate — the full lifecycle Flow of a single Security Command Center finding through its lifecycle. Step one: a Cloud Audit Log entry or a Security Health Analytics scan produces an event. Step two: a detector matches it and creates a finding with a source, a category, a severity and a state of ACTIVE. Step three: SCC maps the finding to MITRE ATT&CK tactics and CIS or compliance benchmarks and ranks it. Step four: the finding shows in the dashboard, is exported over Pub/Sub to a SIEM or ticket, and a mute rule can silence the known-noise ones. Step five: an engineer remediates the resource, the next scan re-evaluates, and the state flips to INACTIVE so it falls off the active list. A break note shows what happens if you only mute instead of fixing. The life of one finding — created, ranked, routed, cleared 1 · Signalaudit log entry ORa SHA misconfig scan 2 · Finding createdsource · category · severitystate = ACTIVE 3 · RankedMITRE ATT&CK tactic+ CIS / PCI benchmark 4 · Routeddashboard + Pub/Submute rule drops noise 5 · Remediatefix the resource → next scanre-evaluates → state = INACTIVE Key idea: SCC RE-checks, it does not just deletea fixed misconfig auto-clears on the next pass Mute ≠ Fixa muted finding is still a real, exploitable hole risky / untrustedSCC / trusteddetector / decisionkey insightcleared / fixed
Follow the numbered boxes left to right: a signal (1) becomes a scored finding (2), gets ranked against MITRE/CIS (3), is routed out and de-noised (4), and finally clears to INACTIVE when you remediate (5). Note the red 'mute ≠ fix' warning at the bottom.
gcloud — create a STATIC mute rule for known-noise findings in a sandbox project
gcloud scc muteconfigs create mute-sandbox-open-fw \
  --organization=123456789012 \
  --location=global \
  --description="Sandbox demo VMs are meant to be open" \
  --filter='category="OPEN_FIREWALL" AND resource.project_display_name="sandbox-demo"' \
  --type=STATIC
Expected output
Created mute config [mute-sandbox-open-fw].
name: organizations/123456789012/locations/global/muteConfigs/mute-sandbox-open-fw
filter: category="OPEN_FIREWALL" AND resource.project_display_name="sandbox-demo"
type: STATIC
muteState applied to 12 existing finding(s)

Once the noise is muted, you route the survivors. SCC streams findings out two main ways. A Pub/Sub notification config publishes matching findings to a topic your SIEM or ticket system subscribes to. And SCC integrates with Chronicle / Google Security Operations for deeper investigation. Filter at export time — state="ACTIVE" AND NOT mute="MUTED" — so only real, un-muted findings leave the building.

gcloud — stream only ACTIVE, un-muted findings to a Pub/Sub topic for the SIEM
gcloud scc notifications create siem-active-findings \
  --organization=123456789012 \
  --location=global \
  --description="Active, un-muted findings to SIEM" \
  --pubsub-topic=projects/sec-ops-prod/topics/scc-findings \
  --filter='state="ACTIVE" AND NOT mute="MUTED"'
Expected output
Created notification config [siem-active-findings].
name: organizations/123456789012/locations/global/notificationConfigs/siem-active-findings
pubsubTopic: projects/sec-ops-prod/topics/scc-findings
streamingConfig:
  filter: state="ACTIVE" AND NOT mute="MUTED"

▶ Watch one finding travel from log to ticket

An attacker grants themselves a sensitive role on a VM at Zomato. Follow the event from the audit log, through ETD, into SCC, and out to the SIEM via Pub/Sub. Press Play for the healthy path, then Break it to see the failure.

① Audit logsetIamPolicy grants roles/owner to attacker@gmail.com — written to Cloud Audit Logs
▼
② ETD matchEvent Threat Detection reads the log, matches Persistence: IAM Anomalous Grant, severity HIGH
▼
③ FindingSCC creates finding: source=ETD, MITRE=Persistence, state=ACTIVE, ranked near the top
▼
④ Routednotification config publishes it to Pub/Sub → SIEM opens a ticket; a Cloud Run fn can revoke the role
Press Play to step through the healthy path. Then press Break it.
🖥️ This is the screen you'll triage from — Google Cloud console → Security → Security Command Center → Findings, with the quick-filter set to ACTIVE + HIGH. (Recreated for clarity — your console matches this.)
console.cloud.google.com · Security · Security Command Center · Findings
1
Quick filter · State
Active
2
Quick filter · Severity
Critical, High
3
Category
PUBLIC_BUCKET_ACL
Source
Security Health Analytics
4
Resource
//storage.googleapis.com/flipkart-invoices-prod
Row action
Mute options ▸ Manage mute rules ▸ Create mute rule
Apply filters
Prove the export is actually flowing, not just configured

Creating a notification config doesn't prove findings are arriving. To verify, pull the messages off the topic: gcloud pubsub subscriptions pull scc-findings-sub --auto-ack --limit=5. If you see JSON finding payloads with state: "ACTIVE", the pipe is live. Empty? Check the export filter (did you accidentally require a category that has no current findings?), that the subscription is attached to the right topic, and that the SCC service account has roles/pubsub.publisher on the topic.

Karthik at ICICI faces this

Karthik, an L2 analyst, gets paged at midnight: 'SCC alert storm — 600 new HIGH findings.' He opens SCC and it's a wall of red. He can't tell the one real problem from the noise.

Likely cause

A new sandbox project full of intentionally-open demo VMs was just onboarded, and every open firewall and public demo bucket fired a finding. The genuinely dangerous finding — a public bucket in a PROD project — is buried somewhere in those 600.

Diagnosis

He triages by source and project, not by raw count: filter to production projects only, then sort by severity. The real finding is one PUBLIC_BUCKET_ACL on a prod bucket; the other 599 are all in sandbox.

Google Cloud console → Security → Security Command Center → Findings → Quick filters: Project = prod-*, State = Active, Severity = High
Fix

Remediate the prod bucket immediately (remove allUsers), then create a STATIC mute rule filtered to the sandbox project so the demo noise stops paging the team — mute the noise, fix the real one.

Verify

Re-run the prod-only filter: the prod PUBLIC_BUCKET_ACL flips to INACTIVE on the next scan, and the sandbox findings no longer appear in the default view or trigger Pub/Sub notifications.

Quick check · Q3 of 10

After Karthik mutes the 599 sandbox findings, his manager asks: 'so those sandbox holes are fixed now, right?' What's the accurate answer?

Correct: a. Mute is a view/noise control, not a remediation: the muted findings still exist (just hidden from the default view and suppressed from notifications) and the sandbox resources are still open. Muting doesn't delete data or change the resource at all, and it certainly doesn't increase exposure — it just stops the noise so the team focuses on real, in-scope findings.

Pause & Predict

Predict: your team wires up a Cloud Run function that auto-revokes a service-account key whenever SCC raises a 'Service Account Key Created' finding. One morning legitimate keys created by your CI pipeline keep getting revoked and deployments break. What went wrong, and what's the SCC-native fix? Type your guess.

Answer: The auto-remediation is firing on a known-good, expected behaviour — your CI's normal key creation — so it's killing legitimate work. The SCC-native fix is a MUTE RULE that matches the CI service account's key-creation findings (e.g. filter on that finding category plus the CI service-account identity), so those expected findings never reach the Pub/Sub export that triggers the function. Auto-remediation should run on the SURVIVORS of your mute rules, never on the raw firehose.

④ A worked posture pass — triage, remediate, export

Time to run the whole loop end to end, the way you'd do it on day one of an SCC role — and the way the exam frames it. Sneha at Flipkart opens Google Cloud console → Security → Security Command Center → Overview, sees the risk score, then clicks into Findings. She sets the quick filters to State = Active and Severity = Critical, High and gets three real problems to work: a public bucket, an over-broad role, and open SSH.

Finding 1 — PUBLIC_BUCKET_ACL on flipkart-invoices-prod (HIGH). A storage bucket holding invoices is readable by allUsers. Finding 2 — over-broad IAM: a service account holds roles/editor on the whole project when it only needs to read one bucket. Finding 3 — OPEN_FIREWALL: a VPC rule allows 0.0.0.0/0 to TCP 22 on a production VM at 10.20.4.7. She works them top-down by severity, fixing the resource each time.

👉 So far: opened the dashboard and triaged three real findings. Next: remediate each, confirm it clears, then make this continuous.
gcloud — remediate all three: lock the bucket, tighten IAM, close SSH
# 1) Remove public access from the invoices bucket
gsutil iam ch -d allUsers:objectViewer gs://flipkart-invoices-prod

# 2) Replace project-wide editor with a least-privilege bucket-only role
gcloud projects remove-iam-policy-binding pay-api \
  --member='serviceAccount:report-sa@pay-api.iam.gserviceaccount.com' --role='roles/editor'
gsutil iam ch serviceAccount:report-sa@pay-api.iam.gserviceaccount.com:objectViewer \
  gs://flipkart-invoices-prod

# 3) Restrict the open SSH rule to the corporate jump-host range only
gcloud compute firewall-rules update allow-ssh-any \
  --source-ranges=172.16.8.0/24
Expected output
Updated IAM policy for gs://flipkart-invoices-prod  (allUsers removed)
Updated IAM policy for project [pay-api].
Updated IAM policy for gs://flipkart-invoices-prod  (report-sa: objectViewer)
Updated [.../firewalls/allow-ssh-any]  sourceRanges now: 172.16.8.0/24

Now the satisfying part: she does not manually close the findings. On the next Security Health Analytics scan, SCC re-evaluates each resource, sees the public ACL gone, the editor role removed and the firewall scoped, and flips all three findings from ACTIVE to INACTIVE on its own. That auto-clear is the proof your fix actually landed — if a finding stays ACTIVE after you 'fixed' it, you fixed the wrong thing.

gcloud — confirm the three findings cleared after remediation
gcloud scc findings list "organizations/123456789012" \
  --filter='category="PUBLIC_BUCKET_ACL" OR category="OPEN_FIREWALL"' \
  --format='table(category, resourceName, state)'
Expected output
CATEGORY            RESOURCE_NAME                                         STATE
PUBLIC_BUCKET_ACL   //storage.googleapis.com/flipkart-invoices-prod      INACTIVE
OPEN_FIREWALL       //compute.googleapis.com/.../firewalls/allow-ssh-any  INACTIVE

Last step makes it permanent: she stands up a continuous export so the next risky bucket someone creates doesn't wait for a human to notice. The Pub/Sub notification config from section 3 streams every new ACTIVE, un-muted finding to the SIEM, where a ticket opens automatically — and for a few high-confidence categories, a Cloud Run function can auto-remediate (e.g. re-private a newly public bucket) before anyone's even awake. Triage → remediate → export: that's the loop the whole SCC product exists to run.

Figure 4 — Security Command Center — the cheat-sheet
Security Command Center on one card — detectors, the finding fields, the triage-remediate-export loop and the first gcloud commands A nine-tile cheat sheet for Security Command Center. Tiles cover the three service tiers, the built-in detectors, the Security Health Analytics misconfig categories, the Event Threat Detection threat categories, the four fields of a finding, the severity ladder, mute rules, the export targets, and the first gcloud commands. Each tile has a one-line role. Security Command Center — your one-glance card TiersStandard: asset + basic SHAPremium: ETD, attack pathsEnterprise: multi-cloud CNAPP DetectorsSHA · misconfig (config state)ETD · threats (logs)Container/VM TD · Web Scanner SHA categoriesPUBLIC_BUCKET_ACLOPEN_FIREWALLNON_ORG_IAM_MEMBER ETD categoriesIAM Anomalous GrantCryptominingBigQuery Exfiltration A finding =source · categoryseverity · statestate: ACTIVE / INACTIVE Severity ladderCRITICAL → HIGH→ MEDIUM → LOWfix top of the list first Mute rulesstatic = foreverdynamic = time-boxedmute ≠ fix the hole Export targetsPub/Sub → SIEM / ticketChronicle (Security Ops)Cloud Run fn = auto-remediate First commandsgcloud scc findings listgcloud scc muteconfigs creategcloud scc notifications create
Your one-card map of this whole lesson — the tiers, the detectors, the SHA and ETD categories, the four finding fields, the severity ladder, mute rules, export targets, and the first gcloud commands. Keep it open in your first week.
Daily-life analogy — the Swiggy order, ranked and routed

Running an SCC posture pass is like a Swiggy restaurant's order screen at lunch rush. The findings list is the incoming order queue; severity is which order is going cold first (work that one). A mute rule is hiding the test orders your own staff placed so they don't clog the screen. Remediation is cooking the dish, and the finding flipping to INACTIVE is the order disappearing once it's handed over. The Pub/Sub export is the KOT printer in the kitchen — every real order routed instantly so nothing depends on someone staring at the screen.

Prove you own the SCC loop

Cold, in 30 seconds: name SCC's four jobs (inventory, misconfig scan, threat detection, web scan); say which detector finds the open door (Security Health Analytics) versus the burglar inside (Event Threat Detection); read a finding as source / category / severity / state; explain why mute ≠ fix; and describe the loop triage → remediate → watch it flip to INACTIVE → continuous export. If you can do that without notes, you're ready for the Security Monitoring domain of the Professional Cloud Security Engineer exam.

Related: GCP VPC Service ControlsNext: GCP Cloud Armor & Firewall
Quick check · Q4 of 10

An interviewer asks Meera: 'You remediated a public bucket via gcloud an hour ago, but its PUBLIC_BUCKET_ACL finding is still ACTIVE in SCC. Most likely explanation?'

Correct: c. Findings auto-clear when the next SHA scan re-checks the resource — so a still-ACTIVE finding means either the scan hasn't run yet or the remediation didn't truly remove the public ACL (check it). SCC findings absolutely do change state; you don't call Support to close misconfig findings; and deleting the resource would typically clear or inactivate the finding, not keep it ACTIVE.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from GCP docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

In Security Command Center, which built-in detector scans resource CONFIGURATION for misconfigurations like a public bucket or an open firewall, and maps them to CIS benchmarks?

Correct: c. Security Health Analytics is the config-state scanner that produces CIS-mapped misconfiguration findings (PUBLIC_BUCKET_ACL, OPEN_FIREWALL, weak IAM). Event Threat Detection reads logs for behaviour-based threats; Web Security Scanner crawls web apps; Container Threat Detection watches GKE runtime — none of those is the misconfig config scanner.
Q6 · Apply

A sandbox project at Airtel is full of intentionally-open demo VMs generating 300 OPEN_FIREWALL findings that page your team nightly. You want to stop the noise WITHOUT touching the demo setup or deleting data. What do you do in SCC?

Correct: a. A static mute rule filtered to the sandbox project's OPEN_FIREWALL findings hides exactly that noise from the default view and suppresses its notifications, leaving the data and the demo VMs untouched. Disabling SHA org-wide blinds you everywhere; hand-editing severity doesn't scale and loses signal; deleting findings daily is manual toil that mute rules exist to replace.
Q7 · Apply

You need only real, un-muted, currently-true findings streamed to your SIEM via Pub/Sub. Which export filter expresses that correctly?

Correct: d. state="ACTIVE" keeps only findings that are still true, and NOT mute="MUTED" drops the ones you've deliberately silenced — exactly 'real and in-scope.' severity="LOW" would forward only the least important ones; state="INACTIVE" forwards resolved findings; mute="MUTED" would forward precisely the noise you wanted to exclude.
Q8 · Analyze

A team on SCC Standard proudly reports 'zero threat findings — we're clean.' Their Cloud Audit Data Access logs are also off. What's the most accurate read of this situation?

Correct: b. Event Threat Detection is a Premium/Enterprise feature and additionally depends on the right audit logs being enabled; on Standard with Data Access logs off, ETD simply isn't looking, so zero findings is silence, not assurance. 'Zero' isn't evidence of safety; you upgrade FROM Standard (to Premium), not to it; and SHA produces misconfigs, not threats, with no default mute hiding them.
Q9 · Analyze

Sneha remediates a public bucket with gsutil, but an hour later SCC still shows the PUBLIC_BUCKET_ACL finding as ACTIVE. She's sure the command ran. What are the two most likely explanations?

Correct: d. Misconfig findings flip to INACTIVE only when the next SHA scan re-evaluates the resource, so a lag is normal — and if it stays ACTIVE past that, the remediation likely didn't truly remove the public ACL (verify the bucket IAM). Findings aren't immutable; Chronicle/severity are irrelevant to whether the resource changed; and Web Security Scanner doesn't touch bucket ACLs.
Q10 · Evaluate

Two engineers describe SCC's value to a hiring manager. (A): 'It's a dashboard that shows all your security alerts in one place.' (B): 'It inventories every asset, runs config scans and log-based threat detection into one severity-ranked, MITRE- and CIS-mapped finding list, then lets you mute noise and export the real findings to a SIEM for response.' Which is the stronger answer and why?

Correct: b. B explains the mechanism that produces the value — continuous inventory, two complementary detectors, a ranked and standards-mapped finding model, and the mute-then-export workflow that drives response — which is exactly what the exam and the job test. A reduces SCC to a passive wall of alerts and misses prioritisation, the SHA/ETD split, and the export/response loop entirely; the two answers are not equivalent.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: In one line, why does muting a noisy finding NOT make your environment any safer? Then compare to the expert version.

Expert version: Because a mute rule only hides the finding from the default view and stops its notifications — the underlying resource (the open firewall, the public bucket) is completely unchanged, so the hole an attacker can use is exactly as exploitable as before; mute manages noise, not risk.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Security Command Center (SCC)
Google Cloud's central security and risk dashboard — asset inventory plus misconfiguration, threat and vulnerability findings, ranked by severity.
Asset inventory
A live catalogue of every Google Cloud resource SCC can see across the organization, so nothing hides.
Security Health Analytics (SHA)
Built-in detector that scans resource configuration for misconfigurations (public bucket, open firewall, weak IAM); maps to CIS/PCI/NIST.
Event Threat Detection (ETD)
Built-in detector that reads streaming logs in near real time for active threats; maps findings to MITRE ATT&CK. Premium/Enterprise.
Web Security Scanner
Crawls your App Engine / Compute / GKE web apps for common flaws like XSS and outdated libraries.
Finding
One issue SCC reports, described by source, category, severity and state (ACTIVE or INACTIVE).
Severity
The CRITICAL / HIGH / MEDIUM / LOW rank on each finding that drives the work-the-top-first ordering.
Mute rule
A filter-based rule that hides matching findings from the default view and notifications. Static = forever, dynamic = time-boxed. Mute is not fix.
Attack path / exposure analysis
Premium/Enterprise scoring of how an attacker could chain findings to reach a high-value resource, so you fix the link that matters.
Pub/Sub notification config
A continuous export that streams findings matching a filter to a Pub/Sub topic for a SIEM, ticketing system or Cloud Run remediation.
Chronicle / Security Operations
Google's cloud-native SIEM; SCC findings flow in for correlation and investigation. Built into the Enterprise tier.
Service tiers
Standard (inventory + basic SHA), Premium (full SHA, ETD, attack paths), Enterprise (multi-cloud CNAPP + Chronicle).

📚 Sources

  1. Security Command Center service tiers — Standard vs Premium vs Enterprise; which detectors (Security Health Analytics, Event Threat Detection, Container/VM Threat Detection, Web Security Scanner) and features (attack paths, compliance, multi-cloud CNAPP) each tier includes. docs.cloud.google.com/security-command-center/docs/service-tiers
  2. Security Command Center overview + built-in detection services — asset inventory and the source/category/severity/state finding model; Security Health Analytics misconfig categories (PUBLIC_BUCKET_ACL, OPEN_FIREWALL, NON_ORG_IAM_MEMBER) and Event Threat Detection threat categories with MITRE ATT&CK mapping. docs.cloud.google.com/security-command-center/docs/security-command-center-overview
  3. Mute findings in Security Command Center — static vs dynamic mute rules; console path (Findings → Mute options → Manage mute rules → Create mute rule) and gcloud scc muteconfigs create --filter syntax. docs.cloud.google.com/security-command-center/docs/how-to-mute-findings
  4. Google Cloud Community / OneUptime practitioner write-up — integrating SCC with a SIEM via Pub/Sub notification configs and the state="ACTIVE" AND NOT mute="MUTED" export filter; the real-world finding-volume / false-positive pain that mute rules solve. oneuptime.com/blog/post/2026-02-17-how-to-integrate-security-command-center-with-siem-tools-via-pubsub · community.google.com
  5. Persistence: Service Account Key Created (ETD finding reference) + 2025 change note — long-lived service-account keys flagged by Event Threat Detection; SCC findings retention moving from 13 months to 90 days for new activations (effective 2025), and Security Health Analytics dropping security-marks allowlisting. docs.cloud.google.com/security-command-center/docs/findings/threats · docs.cloud.google.com/security-command-center/docs/release-notes
  6. Google Professional Cloud Security Engineer certification exam guide — the Security Monitoring and Event Response domain: Security Command Center, log analysis, automated response with Cloud Run functions, Pub/Sub export and event classification. cloud.google.com/learn/certification/guides/cloud-security-engineer

What's next?

You can now rank and route every risk inside SCC. But many of those findings are open doors at the edge — public IPs, web apps taking hits from bots and Layer-7 attacks. Next we put a guard at the front gate.

Next · GCP Cloud Armor & Firewall: Edge Defense for Your Apps → Practice on exam.techclick.in →