Notifications
Clear all
Topic starter
24/06/2026 5:51 pm
TL;DR: ConfusedFunction shows how a routine Google Cloud Function deployment can trigger Cloud Build under a more powerful default service account, creating indirect privilege escalation and access to sensitive project resources, according to Unosecur. The issue underlines that automated deployment identities need the same governance discipline as human and workload accounts.
NHIMG editorial — based on content published by Unosecur: ConfusedFunction: Privilege Escalation Through Google Cloud's Deployment Automation
Questions worth separating out
Q: How should teams reduce privilege escalation risk in Cloud Functions deployments?
A: Teams should treat the deployment workflow as an access boundary, not just the user who clicked deploy.
Q: Why do cloud build identities create hidden security risk?
A: Cloud build identities create hidden risk because they often execute with broader permissions than the initiating developer or pipeline.
Q: What breaks when service accounts are not reviewed in deployment pipelines?
A: What breaks is the assumption that access reviews capture the identity doing the work.
Practitioner guidance
- Scope the build identity separately from the deployer Inventory every service account involved in Cloud Functions deployment and compare its permissions with the permissions of the user or pipeline that triggers it.
- Review cross-service access reachable from Cloud Build Map what the default Cloud Build service account can reach in storage, registries, source repositories, and project-level APIs.
- Correlate deployment, build, and IAM events Alert on unexpected function updates followed by unusual build execution, then check whether IAM policy changes or sensitive resource access followed the same sequence.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- A step-by-step explanation of how Cloud Functions deployment triggers Cloud Build in Google Cloud.
- The specific resource classes exposed through the default Cloud Build service account, including buckets, source code, and registries.
- Concrete monitoring signals for unusual build activity and access changes following function updates.
- Practical remediation guidance for re-scoping service accounts and deployment workflows.
👉 Read Unosecur's analysis of ConfusedFunction and GCP privilege escalation →
Cloud function deployments and the identity gap teams are missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 3:40 am
Cloud build identities have become first-class privilege holders, not background infrastructure. ConfusedFunction shows that a deployment workflow can activate an identity with a much larger effective blast radius than the initiating user. The governance mistake is treating build automation as operational plumbing instead of an access-bearing identity subject to the same review, scoping, and monitoring expectations as any other privileged account. Practitioners should stop asking only who can deploy and start asking what identity the platform will silently introduce when deployment begins.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: Which frameworks apply to cloud automation identity governance?
A: NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 are directly relevant because they both emphasise access control, logging, and identity governance. For cloud environments, use them to map which automation identities exist, what they can reach, and how their actions are monitored.
👉 Read our full editorial: ConfusedFunction exposes privilege escalation through cloud build identity
