Cloudflare 通过实施基础设施即代码和自动化策略执行，消除了数百个生产账户中的手动配置错误，每天处理大约 30 个合并请求，并在部署前而不是事件发生后捕捉安全违规。
公司的 Customer Zero 团队面临一个关键问题：单一配置错误可能在几秒钟内传播到 Cloudflare 的全球边缘，可能会导致员工被锁定或生产服务瘫痪。在这种规模下，对数百个账户进行手动仪表板管理为人为错误创造了太多机会。
该解决方案的核心是将所有基础设施配置视为代码，进行强制性的同行评审和自动化安全检查。现在，每个生产变更都要经过一个验证管道，该管道在部署前执行大约 50 个安全策略。团队仍然使用仪表板进行分析和可观测性，但关键的生产变更需要提交与用户、工单和自动化合规性检查相关联的代码。
根据 Cloudflare 团队的 Chase Catelli、Ryan Pesek 和 Derek Pitts 的说法，这种左移方法将安全验证转移到开发的早期阶段，在补救成本最低时捕捉问题。该模型防止事件发生，而不是对事件作出响应，同时通过让团队相信他们的变更是合规的，从而实际上提高了工程速度。
实施以Terraform和Cloudflare Terraform Provider为中心，集成到一个自定义的持续集成和部署管道中，该管道在Atlantis上运行并与GitLab集成。所有生产账户配置都存储在一个集中的单体存储库中，各个团队作为指定的代码所有者拥有和部署他们的特定部分。
Cloudflare 的基础设施即代码数据流图
一个名为 tfstate-butler 的自定义 Go 程序充当 Terraform 的 HTTP 后端，充当安全状态文件代理。该设计通过确保每个状态文件的唯一加密密钥来优先考虑安全性，从而限制了任何妥协的潜在爆炸半径。
策略执行使用Open Policy Agent框架和Rego语言来验证安全要求。策略在每个合并请求上自动运行，并以两种模式运行：允许部署并带有评论的警告，或者完全阻止变更的拒绝。异常处理需要基于 Jira 的正式批准，然后是一个拉取请求来记录偏差。
迁移揭示了扩展基础设施扩展即代码（Infrastructure as Code）的关键教训。最初，由于团队之间的 Terraform 熟练程度不同，进入门槛很高，阻碍了最初的采用。cf-terraforming 命令行实用程序，它自动从 Cloudflare API 生成 Terraform 代码，通过消除手动资源导入，显著加速了上手速度。
当团队在事件期间进行紧急仪表板变更时，配置漂移就会出现，从而使 Terraform 状态与部署配置不同步。Cloudflare 实施了自动漂移检测，该检测连续比较状态文件与部署配置，并在检测到差异时自动创建具有服务级别协议的补救工单。
Cloudflare Terraform Provider 落后于 API 能力，因为 Cloudflare 的快速产品创新速度超过了 Terraform 的支持。v5 提供者版本通过从 OpenAPI 规范自动生成代码，解决了这个问题，保持了产品 API 和基础设施代码能力之间的持续对齐。
左移模型展示了组织如何在保持严格的安全治理的同时扩展基础设施即代码。通过将验证从反应性审计转移到主动自动化检查，Cloudflare 既提高了安全性，又提高了工程速度。
许多公司正在采用左移方法。谷歌云指出，在生产中定位安全问题可能导致重大的财务处罚，例如高达全球收入 4%的 GDPR 罚款。通过自动化 CI/CD 安全检查进行早期检测可以大大降低补救成本，减少对架构更改的需求。OpsMx指出了实施障碍、自动化差距、复杂工具和组织孤岛等挑战，同时强调使用 NIST 和 OWASP 等框架的自动化策略执行可以帮助团队识别和优先考虑风险，而不会给开发人员带来负担。根据Splunk的研究，73%的公司认为缺乏自动化是他们在左移实践中的主要挑战，但 AI 驱动的工具正在通过智能自动化迅速改进安全测试，采用率在短短一年内从 64%体升到 78%。
左移运动已经超越了简单地将安全检查提前。组织现在正在追求通过自动化扫描（SAST、SCA、DAST、秘密管理）、策略即代码执行和 AI 驱动的漏洞优先级排序进行持续的安全验证，在现有的工作流程中为开发人员提供即时、可操作的反馈。
原文链接：
https://www.infoq.com/news/2026/01/cloudflare-security-shift-left/
