这一区别非常关键。GitHub 会在 Shell 执行命令前，先展开该表达式。如果恶意 Issue 标题包含单引号，就可能结束原本的字符串，并追加攻击者自定义的 Shell 命令。后续再用 sed 清理内容，并不能撤销此前已经发生的 Shell 解析。

issues: opened 这一触发条件也没有让标题变得可信。任何能够在公开仓库创建 Issue 的用户，都可以控制标题；仅限制工作流响应某类 Issue 事件，并不能阻止不可信数据被插入 Shell 命令。

提交记录将“Copilot Autofix powered by AI”列为共同作者，其 AI 辅助审查也没有标记出这个问题。不过，现有证据并不能证明 Copilot 是直接生成了这段不安全代码，还是参与了由人工编写的变更并未发现注入风险。因此，更准确的说法是：Copilot 与这次变更有关联，但未能识别出其中的命令注入问题，而不能断言该模型已被证实是漏洞代码的作者。

Red Agent 如何发现并验证漏洞

Wiz 的 Red Agent 会扫描 Snowflake 的公开 GitHub 组织，寻找高风险的 CI/CD 配置模式。它识别出这条 Jira 工作流将不可信的 Issue 数据放入了 Shell 的 run: 代码块，并推断出：只要创建一个经过构造的公开 Issue，就可能在 GitHub 托管的 Actions 运行器上执行任意命令。

6 月 23 日，也就是漏洞变更合并 5 天后，Red Agent 通过 Snowflake 的 HackerOne 漏洞披露计划创建了一个特制 Issue。该 Issue 标题跳出了原有的 Shell 字符串，并让工作流将 Jira 凭据发送到用于本次授权概念验证的带外回调地址。

这不是一次未经授权的入侵，而是经批准的安全测试。不过，测试所揭示的安全事实仍然成立：一个公开 Issue 的标题可以触达处理内部凭据的工作流步骤，并将普通的 Issue 创建行为升级为命令执行。

漏洞暴露了什么访问权限

被利用的工作流可以读取 Snowflake 内部 Jira 的相关配置，包括 Jira 地址、用户邮箱和 API 令牌。Wiz 取回的令牌与 qa@snowflake.net 账户关联，并使用该令牌登录内部 Jira 门户，以评估潜在影响范围。

相关报道显示，该访问涉及工程、安全合规和漏洞赏金等 Jira 项目的读取权限。但现有证据没有完整说明令牌的全部权限，也没有列出所有可能访问的记录。因此，最稳妥的结论是：该令牌足以访问包含敏感内部内容的 Jira，而不是可以据此断言攻击者获得了对 Snowflake 系统的无限制访问。

受影响的资产是公开仓库中的 CI/CD 自动化，而不是连接器的运行时代码。由于缺陷存在于 GitHub Actions 工作流中，没有已发布的 Snowflake Connector for .NET 版本被报告为受影响。

Snowflake 如何回应

Wiz 于 6 月 23 日报告了该问题。Snowflake 在当天修复了工作流，并于次日轮换暴露的 Jira 凭据。

随后，Snowflake 审查了审计日志，认定在暴露窗口内只有 Wiz 进行了相关操作。Wiz 也表示，已经安全删除其访问的概念验证数据。

目前没有报告未经授权的第三方访问，也没有报告分配 CVE 编号或存在受影响的连接器发行版。这些信息界定了已确认的影响范围，但并不意味着原先的工作流设计是安全的：处理内部凭据的工作流，不应让公开 Issue 标题直接成为 Shell 命令的一部分。

对 CI/CD 安全的启示

这起事件的教训并不局限于 Snowflake 或 Copilot。只要 GitHub 表达式中的 Issue 标题、拉取请求标题、分支名称或评论内容会进入 Shell 命令，就必须把它们视为潜在的恶意输入。

更安全的工作流设计包括：

• 通过环境变量传递不可信值，而不是直接把它们插入 run: 脚本。
• 使用 jq 等结构化工具构造 JSON，避免手工拼接 Shell 字符串。
• 在进入 Shell 的边界处进行严格引用、校验和转义。
• 尽量不要让处理攻击者可控内容的步骤同时接触凭据。
• 对 AI 生成或辅助修改的安全代码进行与人工代码同等严格的独立审查。

这起事件也展现了一个正在形成的安全现实：一个 AI 辅助编码系统可能漏掉危险的 CI/CD 变更，而另一个自主攻击智能体则能在数天内发现并验证它。自动化既能加快修复，也能加快利用；但它无法替代独立的安全审查。

这一区别非常关键。GitHub 会在 Shell 执行命令前，先展开该表达式。如果恶意 Issue 标题包含单引号，就可能结束原本的字符串，并追加攻击者自定义的 Shell 命令。后续再用 sed 清理内容，并不能撤销此前已经发生的 Shell 解析。

issues: opened 这一触发条件也没有让标题变得可信。任何能够在公开仓库创建 Issue 的用户，都可以控制标题；仅限制工作流响应某类 Issue 事件，并不能阻止不可信数据被插入 Shell 命令。

提交记录将“Copilot Autofix powered by AI”列为共同作者，其 AI 辅助审查也没有标记出这个问题。不过，现有证据并不能证明 Copilot 是直接生成了这段不安全代码，还是参与了由人工编写的变更并未发现注入风险。因此，更准确的说法是：Copilot 与这次变更有关联，但未能识别出其中的命令注入问题，而不能断言该模型已被证实是漏洞代码的作者。

Red Agent 如何发现并验证漏洞

Wiz 的 Red Agent 会扫描 Snowflake 的公开 GitHub 组织，寻找高风险的 CI/CD 配置模式。它识别出这条 Jira 工作流将不可信的 Issue 数据放入了 Shell 的 run: 代码块，并推断出：只要创建一个经过构造的公开 Issue，就可能在 GitHub 托管的 Actions 运行器上执行任意命令。

6 月 23 日，也就是漏洞变更合并 5 天后，Red Agent 通过 Snowflake 的 HackerOne 漏洞披露计划创建了一个特制 Issue。该 Issue 标题跳出了原有的 Shell 字符串，并让工作流将 Jira 凭据发送到用于本次授权概念验证的带外回调地址。

这不是一次未经授权的入侵，而是经批准的安全测试。不过，测试所揭示的安全事实仍然成立：一个公开 Issue 的标题可以触达处理内部凭据的工作流步骤，并将普通的 Issue 创建行为升级为命令执行。

漏洞暴露了什么访问权限

被利用的工作流可以读取 Snowflake 内部 Jira 的相关配置，包括 Jira 地址、用户邮箱和 API 令牌。Wiz 取回的令牌与 qa@snowflake.net 账户关联，并使用该令牌登录内部 Jira 门户，以评估潜在影响范围。

相关报道显示，该访问涉及工程、安全合规和漏洞赏金等 Jira 项目的读取权限。但现有证据没有完整说明令牌的全部权限，也没有列出所有可能访问的记录。因此，最稳妥的结论是：该令牌足以访问包含敏感内部内容的 Jira，而不是可以据此断言攻击者获得了对 Snowflake 系统的无限制访问。

受影响的资产是公开仓库中的 CI/CD 自动化，而不是连接器的运行时代码。由于缺陷存在于 GitHub Actions 工作流中，没有已发布的 Snowflake Connector for .NET 版本被报告为受影响。

Snowflake 如何回应

Wiz 于 6 月 23 日报告了该问题。Snowflake 在当天修复了工作流，并于次日轮换暴露的 Jira 凭据。

随后，Snowflake 审查了审计日志，认定在暴露窗口内只有 Wiz 进行了相关操作。Wiz 也表示，已经安全删除其访问的概念验证数据。

目前没有报告未经授权的第三方访问，也没有报告分配 CVE 编号或存在受影响的连接器发行版。这些信息界定了已确认的影响范围，但并不意味着原先的工作流设计是安全的：处理内部凭据的工作流，不应让公开 Issue 标题直接成为 Shell 命令的一部分。

对 CI/CD 安全的启示

这起事件的教训并不局限于 Snowflake 或 Copilot。只要 GitHub 表达式中的 Issue 标题、拉取请求标题、分支名称或评论内容会进入 Shell 命令，就必须把它们视为潜在的恶意输入。

更安全的工作流设计包括：

• 通过环境变量传递不可信值，而不是直接把它们插入 run: 脚本。
• 使用 jq 等结构化工具构造 JSON，避免手工拼接 Shell 字符串。
• 在进入 Shell 的边界处进行严格引用、校验和转义。
• 尽量不要让处理攻击者可控内容的步骤同时接触凭据。
• 对 AI 生成或辅助修改的安全代码进行与人工代码同等严格的独立审查。

这起事件也展现了一个正在形成的安全现实：一个 AI 辅助编码系统可能漏掉危险的 CI/CD 变更，而另一个自主攻击智能体则能在数天内发现并验证它。自动化既能加快修复，也能加快利用；但它无法替代独立的安全审查。