Copilot 未攔下的 Jira 入侵鏈
Snowflake 公開專案的一次 workflow 修改，把原本透過環境變數與 jq 處理 Issue 標題的安全寫法，換成直接插入 shell 指令。任何人只要建立特製標題的 Issue，就可能在 GitHub Actions runner 執行任意命令。Wiz 的 Red Agent 自動找到弱點、調整失敗的攻擊字串，最後取得可讀取 Snowflake 內部 Jira 專案的憑證。要注意的是，PR 的 squash commit 將「Copilot Autofix powered by AI」列為共同作者，Copilot 也曾判定變更沒問題；但 Wiz 後來澄清，無法確定有漏洞的程式碼本身是否由 AI 產生。
現實應用
這案例最值得 CI/CD、DevSecOps 與開源專案維護者參考。只要 GitHub Actions 會處理 Issue、PR、branch 名稱或 commit message，就應把它們視為不可信輸入。攻擊者甚至不必有 repository 寫入權限，只要能觸發公開事件就可能進入 runner。另一方面，Red Agent 展示了自動化紅隊工具的實際能力：不只掃描規則，還能依錯誤訊息修正 payload、驗證憑證權限並估算影響範圍。
期望評估
低標來看，我認為團隊至少該把直接出現在 run: 區塊內的 ${{ github.event.* }} 納入阻擋規則，並縮短 CI 憑證壽命與權限。高標來看，我猜自主安全代理會逐漸成為持續性紅隊，在程式合併後數小時內主動驗證攻擊路徑；但它仍需要授權範圍、稽核紀錄與人工揭露流程，不能把「能成功利用」直接等同「可任意測試」。
商業策略分析
受影響的不只是 Snowflake 或 GitHub。凡是大量導入 AI coding agent、又讓 CI 串接 Jira、雲端或部署金鑰的公司，都面臨相同風險。我認為商業重點不在證明 AI 寫程式不可靠，而是 AI review 與 AI generation 可能共享盲點，不能互相當作獨立安全關卡。值得跟進的方向是 policy-as-code、短效憑證、事件輸入汙點分析，以及能保留「為何採用安全寫法」脈絡的審查機制。
實作細節
問題於 2026 年 6 月 18 日上線，Wiz 五天後回報；Snowflake 當天恢復 env: 搭配 jq --arg 的處理方式，隔日輪替 Jira token。稽核結果顯示曝光期間只有 Wiz 的測試活動。維護者可檢查 workflow 是否把外部輸入直接展開到 shell，並避免用事後 sed 跳脫取代結構化參數傳遞。