GCP security assessment

Common findings (examples)

• An identity with more privilege than its job needs, or a path from a low-privilege role to administrator.
• Storage buckets or databases reachable from the internet without a good reason.
• Security groups or firewall rules that leave management ports open to the world.
• Long-lived access keys or secrets in instance metadata, pipelines or code repositories.
• Logging turned off, or alerts that would not fire on the paths an attacker actually uses.

What we need from you

• List of in-scope projects (and organisation or management structure if used).
• Read-only access for the review role, created by you and revoked when we finish.
• A named contact for production change windows and out-of-scope services.
• Architecture notes or diagrams if you have them (helpful, not required).

Typical timeline

Duration depends on how many projects and services are in scope. A single project with a focused service set is often a short engagement; a multi-project organisation with containers, data stores and custom identity federation takes longer. Dates are agreed after the scope call.

Standards and method

Coverage is guided by Google’s cloud security foundations and CIS-aligned GCP controls, then validated by a tester. Assessment practices follow NIST SP 800-115.

Depth by service family

• IAM. Bindings, custom roles, service accounts and keys, workload identity, domain-wide delegation.
• Network. VPC firewalls, hierarchical policies, Shared VPC, Cloud NAT, public load balancers and open databases.
• Compute. Compute Engine metadata and OS Login, GKE RBAC and node identity, Cloud Run and Cloud Functions permissions.
• Data. Cloud Storage IAM and public access, Cloud SQL exposure and encryption, backups and snapshots.
• Keys. Cloud KMS, Secret Manager, and secrets found in images or pipelines during the review.
• Detection. Cloud Audit Logs, Security Command Center findings that matter, organisation sinks and exclusions.

What stays out of scope by default

• Changing IAM or firewall rules (review is read-only).
• Projects or folders you did not name.
• Denial-of-service against production.
• Google Workspace admin review unless you add it as a separate scope.

Multi-project and Shared VPC notes

Many GCP estates span folders and a Shared VPC host project. We treat that as one attack surface when you name it in scope: a weak binding in a spoke project that can reach a host-project network or a central secret is reported as a path, not as three unrelated ticks on a checklist.

Service account keys and workload identity

Long-lived service account keys remain a common path into GCP. We look for keys that still exist, where they are stored and what they can do, and we prefer findings that push you toward short-lived workload identity where it fits. The report explains the blast radius in project terms your owners already use.

Scope and rules

• Scope call. Projects, services in use, production limits and any services that must not be touched.
• Read-only access. You grant a least-privilege review role. We confirm it before testing starts.
• Configuration review. Identity, network, compute, data, keys and logging against the GCP security benchmark and common CIS control language.
• Attack-path analysis. From realistic starting identities (a developer role, a compromised workload identity, an over-permissive service account), we map what could be reached.
• Controlled validation. High-risk paths are checked safely where agreed. Destructive actions stay out of scope.
• Report and retest. Findings with evidence, a walkthrough and a retest of fixes that are ready within 6 months of the original test (up to 10 issues).