/google-cloud-scc-remediation

name: google-cloud-scc-remediation
metadata:
  category: Security
  version: "1.0.0"
description: >-
  Remediates Google Cloud Security Command Center findings, including IAM
  permission fixes, cloud resource misconfigurations, vulnerabilities, and Toxic
  Combinations. Use when asked to fix, remediate, or mitigate a Security Command Center
  finding or address attack paths. Don't use for general IAM policy querying without a
  Security Command Center finding. For runtime threat detections, this skill provides
  containment and investigation guidance rather than automated configuration fixes.

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.

| Match On | Values | Target Reference Playbook | | :---------------------- | :---------------------------------------- | :--------------------------------------------------------------------------- | | `category` | `PRIMITIVE_ROLES_USED`, | [`references/remediation_iam.md`](references/remediation_iam.md) | : (Security Health : `OVER_PRIVILEGED_SERVICE_ACCOUNT_USER`, : : : Analytics) : `ADMIN_SERVICE_ACCOUNT`, : : : : `SERVICE_ACCOUNT_ROLE_SEPARATION`, : : : : `KMS_ROLE_SEPARATION`, : : : : `USER_MANAGED_SERVICE_ACCOUNT_KEY`, : : :