3,700 CNAPP findings, four engineers, and a board that wants a number
Meridian Health consolidated 480 GCP projects into one organization and enabled Security Command Center Premium plus a third-party CNAPP. The console now shows 3,700 active findings. The four-person cloud security team triaged 300 findings last month and closed 60. Notable items: 71 Cloud Storage buckets allow allUsers read; 210 Compute Engine instances run with the default compute service account and the cloud-platform OAuth scope; 9 GKE clusters allow privileged containers and have no network policies; 34 service account keys are older than 365 days. Application teams say the findings are 'noise' and have stopped answering tickets. The CISO wants a plan that measurably reduces exploitable risk in 60 days, plus one metric she can take to the board.
1. Explain how you would prioritize these 3,700 findings, and why ranking by severity count or by scanner CVSS score will fail here.
Read the worked answer
Severity counts measure scanner output, not risk, and they are why the application teams disengaged: a medium finding on an internet-facing workload with PHI behind it outranks a critical finding on an isolated dev VM, but the score does not say so. Prioritize on attack path, with three factors:
- Exposure - reachable from the internet without authentication. The 71
allUsersbuckets qualify immediately; a bucket readable anonymously is a data breach, not a misconfiguration. - Identity reach - what an attacker gains after the first hop. The 210 instances on the default service account with
cloud-platformscope are the highest-leverage item, because compromising any one of them yields a token whose effective permissions are the IAM roles bound to that account across the project and, if over-granted, the folder. Combine that with the 9 privileged GKE clusters and you have a container escape → node token → project takeover chain. - Data sensitivity - classify buckets and BigQuery datasets for PHI, then intersect with the two factors above.
Rank the 34 stale keys lower: they are real exposure but require the key to have leaked. That is a hygiene item with a scheduled fix, not a 60-day fire.
Practically: use SCC's attack-path and sensitive-data discovery to build a top-50 list of resources, not findings, and assign each a named owner. A single public PHI bucket produces a handful of findings; closing the resource closes all of them, which is how you turn 3,700 into a workable queue.
2. Design the prevention and workflow layer that stops this volume from regenerating, and define the single board-level metric.
Read the worked answer
Prevention first, because triage cannot scale to 480 projects.
- Organization Policy constraints at the organization node, not per project:
storage.publicAccessPrevention(enforced),iam.disableServiceAccountKeyCreation,compute.vmExternalIpAccessrestricted to an allowlisted project set, andiam.automaticIamGrantsForDefaultServiceAccounts. These are policy-as-code and cannot be waived by an application team. - Replace default service accounts with dedicated per-workload accounts and Workload Identity for GKE; drop
cloud-platformscope and use fine-grained scopes plus IAM. - Gatekeeper/Policy Controller on GKE for privileged pods and mandatory NetworkPolicy, enforced in the admission path.
- Deploy new projects from a Terraform module and a golden project factory so the compliant path is the easy path.
Workflow. SCC findings flow to Pub/Sub → ticketing, deduplicated by resource, with auto-close on remediation. Mute rules are allowed only for verified false positives and must carry an expiry and an owner - never mute a whole detector. Weekly 30-minute review of the top-50 list with application owners.
Board metric. Do not report findings closed; report the count of internet-exposed resources holding sensitive data with no compensating control - a number that starts at 71 buckets plus exposed PHI-bearing VMs and must trend to zero. Pair it with mean time to remediate for that class only, so the board sees both the stock and the flow.