Google Cloud Scc Remediation

Google Cloud Security Command Center Remediation

Overview

A unified remediation skill for Google Cloud Security Command Center findings. It handles both single-domain findings and multi-domain Toxic Combinations.

1. Safety & Consent Gate

Security Command Center remediations modify infrastructure, access policies, or workload deployments.

• Mandatory Consent Gate: NEVER execute mutating gcloud, terraform, or API commands without first presenting a structured remediation plan and the exact command/config diff to the user. STOP after presenting the plan and ALWAYS ask: "Do you approve executing this remediation plan?" before execution. Automatic mutation of security policies or resource configurations can cause unintended outages, lockouts, or compliance violations.

• Confirm the Target Project: Before executing, confirm that the active gcloud account and project match the project of the finding's resource. Every mutating command MUST specify the target explicitly, with --project or a full resource path, rather than relying on the default gcloud project.

• Verification & Rollback Required: Every proposed remediation plan MUST explicitly include, for each mutating step:

  • the mutating remediation command(s),
  • the verification check command(s) (gcloud ... describe or list), and
  • the rollback command(s) that undo the change, or an explicit statement that the step cannot be undone (for example, service account key deletion).

  Use the commands from the loaded playbook where they exist. If the playbook lacks a verification or rollback command for a step, derive the command and label it as not sourced from a playbook.

• Dependency & Impact Checks: Every remediation plan MUST state what could break as a result of each change and ask the user to confirm nothing depends on it. For example:

  • IAM role changes or revocations: you MUST explicitly advise the user to verify cross-project dependencies and CI/CD pipeline workflows that rely on the existing permissions before revoking a project-level role binding.
  • Firewall rule changes: other traffic the same rule allows (such as web traffic on ports 80 or 443).
  • External IP removal: inbound access and outbound internet access for the VM.
  • Public Access Prevention on a bucket: sites or users that legitimately read it publicly.

• CRITICAL WORKFLOW RULE: Do NOT execute any mutating commands in the same turn that you present the remediation plan. You MUST end your turn immediately after asking for approval and wait for the user's next message.

  • If there is no interactive user (for example, a scheduled or pipeline run), stop at the plan and never execute.
  • If the user approves only part of the plan, or the plan changes after approval, present the updated plan and ask for approval again before executing.

• Narrowly Scoped Changes: Always propose the narrowest possible fix that resolves the finding. When more than one fix would work, prefer reversible changes over irreversible ones (for example, disable a key before deleting it), resource-level changes over project, folder, or organization-level changes, and changes that affect only the finding's resource over changes that affect other resources. Do not bundle fixes for unrelated issues noticed along the way; mention them to the user separately.

2. Intent Router & Progressive Disclosure

Do not load all reference playbooks into memory at once. Analyze the Security Command Center finding's category, findingClass, or attack path, then read ONLY the relevant reference document(s).

Match on the finding's category first, and fall back to findingClass only when no category matches. Routing on findingClass alone misroutes IAM findings: Security Health Analytics IAM findings are MISCONFIGURATION class, and IAM recommender findings are Vulnerability class, so neither would ever reach the IAM playbook.