公开暴露的 Serverless 函数（比如 Cloud Run）常常为了业务需要不设认证，这直接成了攻击者的前门。Mandiant 在安全评估中反复看到这类服务存在 LFI 和命令注入 漏洞——攻击者传个文件路径就能把源码全拉走，或者直接执行 curl 命令去掏 metadata 服务器的 bearer token。更致命的是，如果 Cloud Run 用的是默认 Compute Engine 服务账号且权限过大（比如 Editor），拿到 token 就等于整个 GCP 项目沦陷，所有资源都能被读/写/删。这不是理论风险，而是真实攻击链里的高频入口。

文章给出了非常具体的攻击演示和加固手段。对 LFI，可以用 Cloud Armor 预置的 lfi-v33-stable WAF 规则拦住路径遍历请求（例如 ../../../etc/passwd），返回 403；对 RCE，用 rce-v33-stable 规则同样能阻断。但 WAF 只是最后一道防线，更核心的解法是用自定义服务账号并遵循最小权限原则——只给 Cloud Run 函数必要的角色（比如只读某个存储桶的 Storage Object Viewer），同时把公网流量先打到 Layer 7 负载均衡，再用 Cloud Armor 做 WAF 和速率限制。此外，使用 VPC Service Controls 限制横向移动，以及集成 Security Command Center 的 Cloud Run 威胁检测（能感知反向 shell 和凭据窃取行为），形成纵深防御。

我觉得这篇文章最有价值的地方在于，它没有只讲理论，而是把攻击代码、curl 命令、WAF 规则写法都贴出来了，安全团队直接就能照着测和加固。而且它专门提到了 vibe-coding（AI 生成代码）的安全问题——很多人用 AI 快速生成 serverless 函数并部署，但代码里可能天然带着漏洞。文章建议把 AI 实验隔离在独立沙盒项目里，并用人工在环的审批流程，这恰恰是当前很多公司忽视的点。未来 serverless + AI 会越来越普遍，安全左移（开发阶段就扫描）加运行时多层防护，缺一不可。