AI 修复反成“投毒”：GitHub Copilot 诱发 Snowflake 凭据泄露深度研判

GitHub Copilot 的 AI“自动修复”（Autofix）功能在尝试修复 Snowflake 内部代码的安全漏洞时，意外建议了包含敏感逻辑的代码，导致 Snowflake 的 Jira 凭据在 CI/CD 日志中泄露，攻击者借此可渗透其内部 Jira 实例。

• ▶ AI 补丁的“环境盲区”：AI 修复工具（如 Copilot Autofix）虽然能识别静态代码缺陷，但往往缺乏对运行环境（如 CI/CD 变量、凭据存储）的上下文感知，容易在修复 A 漏洞时引入 B 风险。
• ▶ 自动化偏见（Automation Bias）的代价：开发者倾向于信任 AI 生成的安全补丁，导致人工审核（Human-in-the-loop）环节流于形式，使 CI/CD 日志成为了新的敏感信息泄露重灾区。

八卦洞察

这起事件标志着“AI 辅助安全”正式进入风险深水区。Snowflake 事件并非个例，它揭示了当前 GenAI 在 DevSecOps 链路中的核心矛盾：修复速度与安全深度的脱节。GitHub Copilot 在处理 CodeQL 警报时，其底层逻辑是“通过修改代码消除警报”，而非“通过理解业务逻辑保障安全”。这种“头痛医头”的机械式修复在复杂的生产环境中极具误导性。

从全球视角看，CI/CD 管道已成为 AI 诱发供应链攻击的首选目标。当 AI 代理（AI Agents）被赋予直接提交代码或修改配置的权限时，传统的基于“信任开发者”建立的安全模型将彻底失效。我们正在进入一个“AI 生成漏洞”比“人类编写漏洞”更难追踪的新时代。

行动建议

• 强化日志脱敏（Log Sanitization）：企业必须在 CI/CD 流程中强制执行严格的敏感信息扫描，防止 AI 生成的调试代码或错误补丁将环境变量导出至公开日志。
• 建立 AI 补丁隔离区：严禁 AI 生成的代码直接合并至主分支。应设立专门的“AI 审计沙箱”，要求安全团队针对 AI 建议的逻辑进行二次验证，而非仅依赖静态扫描工具。
• 重新定义最小权限原则：针对集成 AI 工具的 GitHub Action 或服务账号，应实施更严苛的权限隔离，确保即使代码被 AI “带偏”，也无法跨权限访问核心凭据库。