AI 自動修復漏洞反成破口：Copilot 補的洞讓紅隊闖進 Snowflake
AI 自動修復漏洞這類功能，本身就是新的攻擊面。2026 年的 Snowflake 事件裡，一段掛名「Copilot Autofix」的修補碼，反而開了讓陌生人遠端下指令的門。
補一下脈絡：2026 年 6 月 18 日，Snowflake 一個公開專案合併了一則 PR，把原本安全的輸入處理換成危險寫法；五天後的 6 月 23 日，資安公司 Wiz 的自主 AI 紅隊工具，就靠這個破口闖進了 Snowflake 內部的 Jira 系統。整起事件在 8 月 17 日由 Wiz 公開（Wiz Blog），今天是 8 月 18 日發稿。這是一起有完整技術佐證的真實攻陷案例。
這次 Snowflake 事件到底發生什麼事？
一段被 AI 標記為「安全」的 GitHub 修補程式碼，實際上開了一個指令注入漏洞。任何 GitHub 使用者只要在 Snowflake 的公開專案開一則標題經過設計的 issue，就能在自動化流程的伺服器上執行任意指令，偷走裡面的 Jira 憑證。發現並利用它的，是 Wiz Research 的「Red Agent」——一個全程無真人介入的自主 AI 資安研究工具。
出問題的專案是 snowflakedb/snowflake-connector-net，這是 Snowflake 名下、公開在 GitHub 上的專案（從 repo 命名看是 .NET 連接器）。漏洞從上線到被攻陷，只隔了五天。以下是完整時間軸。
| 日期（2026） | 發生的事 | 為什麼關鍵 |
|---|---|---|
| 6/18 | PR #1218 合併、漏洞上線；squash commit（把多個 commit 壓成一個的合併方式）掛「Copilot Autofix powered by AI」為共同作者 | 安全的輸入處理被換成直接字串展開 |
| 6/23 | Wiz 自主 AI 紅隊發現並成功利用，取得存取內部 Jira 的權限 | 從上線到被攻陷只隔五天 |
| 6/23 | Snowflake 當天完成修補、輪替外洩憑證，並比對詳細存取紀錄確認全程只有 Wiz | 揭露當天就止血 |
| 8/17 | Wiz 公開事件，並於同日更新說明 Copilot 的角色 | 全程無真人介入 |
Snowflake 的反應算是教科書等級：當天修補、輪替憑證，還調出詳細的存取紀錄，驗證曝險期間只有 Wiz 一個行為者；Wiz 也確認測試中存取的資料已安全刪除。真正該讓老闆背脊發涼的，是漏洞怎麼進來的。
Copilot Autofix 是什麼？「AI 幫你補洞」原本要解決什麼？
Copilot Autofix 是 GitHub 內建的 AI 功能：掃到程式碼裡的資安漏洞後，自動生成一段修補建議，開發者按個鈕就能套用。
這裡先把兩個名詞講白話。GitHub Actions 是 GitHub 內建的自動化流程，程式碼一有動作（有人開 issue、送 PR、合併）就自動觸發，跑測試、打包、部署——它就是所謂 CI/CD（持續整合／持續部署，程式碼從提交到上線的自動化生產線）的引擎。這條生產線通常握有部署憑證與雲端權限，是資安的高價值目標。
諷刺的地方在這：一個被設計來「降低資安負擔」的 AI 功能，這次成了引入漏洞、又把漏洞標成「安全」的那一環。
這個漏洞的技術細節是什麼？AI 到底漏看了什麼？
核心是一個「指令注入」漏洞。指令注入（script injection） 指的是把使用者能控制的文字，沒清乾淨就塞進伺服器會執行的指令裡；攻擊者只要在文字裡藏特殊符號，就能跳出原本的字串、讓伺服器改跑他的指令。
問題出在 jira_issue.yml 這個 workflow。它設定成「有人開 issue 就觸發」，而且把攻擊者可控的 issue 標題直接拼進一段 shell 指令。原本的安全寫法，是先把標題丟進一個環境變數，再用 jq 工具安全地組成 JSON；6 月 18 日的那則 PR 把這個安全模式拿掉，改成直接展開 ${{ github.event.issue.title }}。新版其實還留著消毒：後面接了兩道 sed 對引號做逸出處理。致命傷在順序——sed 的轉義要等 GitHub 先把標題原文展開進指令字串之後才跑，而標題裡的一個單引號在展開當下就斷開了 echo 的字串，後面的文字直接被當成指令執行，事後的轉義救不回來（Wiz 的技術分析）。消毒有做，但做在錯的時間點，等於沒做。
更糟的是那道看起來像防護的「安全閘門」。workflow 有個 if: 條件，判斷觸發者是不是某個機器人帳號；但在 issue 事件下，它引用的 github.event.pull_request 永遠是空值，整個條件因此恆為真——每一個 GitHub 使用者都能通過這道閘門。看似把關，實際上形同虛設。
Wiz 的 Red Agent 展現了另一個值得警惕的細節：它第一次嘗試用 # 註解符號送出竊取的憑證時，伺服器回報語法錯誤。它沒有停下，而是自主分析了錯誤、把 payload 改成用 ; echo 正確收尾，成功透過帶外回呼（out-of-band callback，讓被攻陷的機器主動連到攻擊者伺服器把資料送出）拿到了 Jira 憑證。攻擊方也是自主 AI，會自己 debug。
這裡要對事實誠實。Wiz 在 8 月 17 日的更新裡把話講清楚了：可以確認的是，Copilot 以共同作者身分檢查了那則合併的 PR 與程式碼變更，並判定「全部沒問題」，卻沒發現這個重大漏洞；至於危險的程式碼本身是不是由 AI 生成，官方說仍不清楚（Wiz 8 月 17 日的更新）。無論是哪一種，結論一樣：AI 蓋章的「安全」不能當定論。
AI 自動修復漏洞真的安全嗎？和人工審查差在哪？
不能全信。AI 自動修復快、涵蓋廣，但這次事件顯示它會漏看新引入的漏洞，還把危險程式碼標成「安全」。速度換來的，是一個沒人複查就放行的環節。把兩種做法攤開比較：
| 比較維度 | AI 自動修復（如 Copilot Autofix） | 人工資安審查 |
|---|---|---|
| 速度 | 幾分鐘生成修補 | 慢，看人力多寡 |
| 涵蓋範圍 | 一次掃整個專案 | 有限、多半抽樣 |
| 上下文理解 | 弱，難判斷「這個輸入來自不可信來源」 | 強，懂業務與威脅脈絡 |
| 對「新引入」漏洞 | 這次直接漏看並標成安全 | 有機會在合併前攔下 |
| 責任歸屬 | 模糊，出事沒有具體對象 | 明確到人、可追溯 |
| 成本 | 低，多為工具訂閱費 | 高，需人力或外部專家 |
看得出來，AI 自動修復的強項在速度與覆蓋，弱項正好是這次出事的地方：理解輸入的信任邊界、以及對自己剛改動的程式碼做批判性複查。這兩件事現階段還是人做得比較穩。合理的用法是讓 AI 當草稿手、人當最後一關，而不是反過來讓 AI 決定什麼能放行。這類「把不可信輸入直接拼進 shell」的寫法，本來就是資安基本常識要避開的禁忌；這次的案例證明，AI 自動修復不會替你守住這條常識。
這對台灣中小企業意味著什麼？
很多台灣中小企業把 GitHub Copilot 的自動修復當免費資安外包，覺得有 AI 掃漏洞、補程式碼就安心了。這個假設這次被真實案例打臉。我的立場很明確：可以用 AI 自動修復，但絕對不能全自動放行——AI 產出或審查過的程式碼，進入正式流程前一定要有一個人複查並簽核。
原因是中小企業的處境常常同時踩中三個雷：專案放在公開 repo、CI/CD 流程握有部署憑證與雲端金鑰、卻又沒有專職資安人力做複查。Snowflake 這種規模的公司都被一則 issue 標題打進內部 Jira，資源更少的小公司只會更脆弱。差別只在於，你可能連完整的存取紀錄都沒有，出事根本不知道被摸過。
更要命的是「自動合併」。如果你的流程設定成 AI 掃過、標記安全就自動 merge，等於把守門權整個交給一個這次證明會看走眼的判斷者。省下的人力成本，可能一次外洩就全賠進去。對老闆來說，關鍵是要不要在這個環節留一個人。
導入會自動寫程式碼的 AI 前，老闆該守哪些底線？
答案先給：把 AI 當草稿手，不當放行的最後一關。具體可以從這幾條做起。
- 憑證與權限相關的程式碼，一律人工複查。 尤其是 CI/CD workflow、部署腳本、任何會碰到 token 或雲端金鑰的變更，不論是不是 AI 產生的，都要有人看過才合併。
- 關掉高風險流程的自動合併。 對外可觸發的 workflow（開 issue、送 PR 就會跑的那種）不要設自動放行，留一道人工簽核。
- 檢查誰能觸發你的自動化。 像這次那種「看似把關、其實恆為真」的條件，最容易被忽略。定期確認外部使用者能不能觸發到握有憑證的流程。
- 不可信輸入不要直接拼進指令。 這是老規則，但 AI 自動修復不保證會遵守——把 issue 標題、PR 內文這類外部輸入，先過環境變數或參數化處理，別直接展開進 shell。
- 開啟並保存完整的系統紀錄。 出事時，能不能像 Snowflake 一樣快速確認「誰、什麼時候、動了什麼」，決定你是止血還是裸奔。
這些是流程紀律問題，不用養一支資安團隊，中小企業做得到。
導入會自動改動程式碼的 AI 工具，最大的風險往往藏在「看起來省事、其實沒人把關」的那個環節。如果你想釐清自己的流程裡哪裡該留人工閘門、哪裡可以放手給 AI，到 mingnow.airun.tw 看一輪 AIRUN 對抗式創業體檢怎麼幫你找破口。AI 能幫你補洞，但「決定什麼能上線」這件事，2026 年還是別全交給它。
常見問題
GitHub Copilot 的自動修復功能安全嗎？企業導入前該注意什麼？
它能加速補洞，但不能當免審查的保險。2026 年 Snowflake 事件裡，一段掛名 Copilot Autofix 的修補碼反而引入了指令注入漏洞，AI 審查還把它標成安全。導入前該做的是設一條規則：AI 產出或審查過的程式碼，尤其碰到 CI/CD 憑證的部分，進正式流程前一定要人工複查並簽核。
什麼是指令注入（script injection）？
指把使用者能控制的文字，沒經過清理就塞進系統會執行的指令裡。這次攻擊者只要在 GitHub 開一則標題含特殊符號的 issue，就能讓 Snowflake 的自動化伺服器跳出原本字串、執行他寫的指令，進而竊取內部 Jira 憑證。防法是把外部輸入參數化處理，不要直接拼進 shell 指令。
中小企業把 AI 自動修復放進 CI/CD 有什麼風險？
CI/CD 流程通常握有部署憑證與雲端權限，一旦 AI 產生的程式碼被自動合併又沒人複查，等於多開一道未經審查的門。攻擊者可透過公開 repo 的 workflow 漏洞取得憑證，再橫向移動到內部系統。中小企業常缺專職資安人力，也少有完整的存取紀錄，出事往往不自知，風險比大公司更高。
出事的到底是 AI 寫的程式碼，還是 AI 審查失職？
依 Wiz 8 月 17 日的更新，可確認的是 Copilot 以共同作者身分檢查了合併的 PR，判定「全部沒問題」卻沒發現重大漏洞；至於危險的程式碼本身是否由 AI 生成，官方說仍不清楚。兩種情況指向同一個教訓：AI 給的「安全」判斷不能當最終定論，關鍵環節仍需人工複查。
導入 AI 程式碼工具，老闆最該先做的一件事是什麼？
設一條規則：AI 產出的修補或程式碼，進入正式流程前一定要有一個人複查並簽核，特別是碰到憑證、權限、對外可觸發的 workflow。說到底就是讓 AI 負責起草，放行與否由人拍板。這條規則是流程紀律，不需要額外人力預算，中小企業立刻能執行。