AI程式助手工作階段劫持怎麼防？從套件到權杖逐層檢查

AI 程式助手工作階段遭劫持，可能把開發者信任的建議轉成惡意套件安裝。Mandiant 揭露，一家未具名 SaaS 業者遭入侵後，Shai-Hulud 蠕蟲擴散至約百個內部程式碼儲存庫，並竊取機密與產品原始碼。團隊檢查 AI 開發流程時，應同時盤點工作階段、端點、套件來源、GitHub OAuth 存取權杖（授權後代表使用者存取服務的憑證）和自動化權限。

一、Mandiant 個案如何從工作階段擴散到儲存庫？

公開報告描述的鏈條包含遭劫持的開發者工作階段、遭污染的 PyPI（Python 套件索引）套件、GitHub OAuth 權杖遭竊，以及蠕蟲擴散到約百個內部儲存庫。

Mandiant 指出，攻擊者先入侵一家 SaaS 業者，再劫持開發者工作站上正在使用的 AI 程式助手工作階段。助手推薦安裝外部套件，而該套件已被攻擊者污染；開發者接受建議後，攻擊者利用工作階段安裝資訊竊取程式，取得 GitHub OAuth 權杖。

權杖讓攻擊者得以部署 Shai-Hulud 蠕蟲，自動蒐集儲存庫中的機密並外傳產品專有原始碼。攻擊者接著污染企業官方命名空間下的套件，另一名員工拉取受污染版本後，出現第二次感染。這段後續顯示，檢查範圍要包括內部套件發布權限與下游安裝流程。

從防守角度看，這條鏈上的每一次權限交接都值得分開檢查。助手工作階段負責承接開發者的操作，套件管理器負責取得程式碼，作業系統與瀏覽器可能保存登入狀態，程式碼平台則依權杖決定能讀寫哪些儲存庫。若調查只聚焦套件本身，可能漏掉遭同一工作階段接觸的憑證與後續發布權限。

約百個儲存庫是報告中的約數，不能據此推算其他組織的受影響規模。團隊可把此事件當作一次流程演練：假設某個開發工作階段失守，逐一確認它能觸及的專案、套件發布管道、建置祕密及部署目標，再找出哪些紀錄能還原操作。演練結果應由開發、平台工程與資安人員共同確認，避免清單只反映單一部門的視角。

二、哪些是 AI 程式助手工作階段劫持的已知事實，哪些仍待團隊盤點？

已知受害者是一家未具名 SaaS 業者，攻擊涉及遭劫持的 AI 助手工作階段、PyPI 套件、GitHub 權杖及約百個內部儲存庫；公開報告沒有說明工作階段最初如何遭入侵。

因此，這起事件不能直接歸因於某個 AI 產品漏洞、特定憑證外洩途徑或開發者操作失誤，也不能推論所有 AI 程式助手都存在相同問題。能確認的是，已登入的工作階段可接觸開發環境中的工具與權限，遭濫用時會讓正常工作流程成為攻擊鏈的一環。

Mandiant 的個案屬於單一公開案例，適合用來檢查整合邊界。團隊可依自身架構確認助手可讀取哪些專案、能執行哪些命令、套件從哪裡下載，以及登入工作階段附近存放了哪些憑證。這些是其他團隊應另行確認的盤點問題，不代表 Mandiant 已在受害環境確認每一種權限暴露。

盤點時可把已知事件事實與內部假設分成兩欄。前者記錄報告明載的套件、權杖及儲存庫活動；後者列出自家助手是否能讀取終端機輸出、環境變數、工作目錄或祕密管理服務。每個假設都要附上驗證方式，例如查閱擴充套件權限、測試執行環境隔離，或向平台管理者確認權限設定，避免把可能性寫成事件結論。

公開資料沒有指出工作階段最初遭入侵的途徑，因此也無法由這份個案判斷哪一種單一控制最先失效。團隊更適合檢視控制之間是否形成可追蹤的防線：登入是否有多因素驗證、工作階段是否能快速撤銷、套件是否經過審核，以及異常讀取或發布是否留下紀錄。每項控制的責任人與可用紀錄都應明確，否則發現異常時很難知道由誰查核。

三、AI 開發流程要盤點哪些信任邊界？

優先盤點工作階段與工作站、開發者權杖、第三方相依套件，以及儲存庫和 CI/CD（持續整合／持續交付）自動化的權限範圍。

工作階段與工作站

確認 AI 助手、IDE（整合開發環境）擴充套件、CLI（命令列介面）工具及外掛能讀取哪些檔案與環境變數。API（應用程式介面）金鑰、長效 OAuth 權杖和雲端憑證若可被擴充套件直接讀取，工作站遭入侵時，影響可能超出單一程式碼專案。把高敏感憑證移到受控的祕密管理服務，並限制不同工具的讀取權限，可縮小暴露範圍。

實際盤點可從工具清冊開始，記下助手的執行位置、啟用的擴充套件、可存取的工作目錄，以及是否能呼叫終端機或外部網路。接著確認作業系統的祕密儲存、瀏覽器登入狀態和環境變數是否會被同一使用者程序讀取。這些設定會因 IDE、作業系統與企業管理方式不同而異，盤點結果應描述實際設定，不宜假設所有產品都提供相同的隔離選項。

可觀測紀錄也要一併列出，例如端點防護的程序活動、助手或擴充套件的操作紀錄、登入與網路閘道紀錄。由端點管理者確認紀錄保留方式，開發團隊則標記常見的正常操作，才能在調查時辨認異常。若工具本身不提供足夠紀錄，可以評估透過受管終端機、代理伺服器或端點監控補足，但是否可行取決於組織的工具鏈與隱私政策。

權杖與儲存庫

盤點個人權杖、應用程式權杖和自動化憑證的有效期限、可寫入的儲存庫及可執行的操作。讓一個開發工作階段持有跨組織、跨專案的寫入權限，會擴大遭濫用後的影響面。依任務切分權限，並定期撤銷不再使用的憑證，可降低單一權杖失守時的波及程度。這是依組織工具鏈設定的控制目標，具體實作須看所用 IDE、程式碼託管平台及身分系統；平台角色、企業 SSO（單一登入）政策與作業系統祕密儲存各自管理不同層面的存取。

管理者可建立權杖與應用程式身分清冊，記錄擁有人、核發目的、到期日、可操作範圍及撤銷方式。程式碼平台上的儲存庫角色決定成員能否讀取、推送或管理設定；身分系統則可能控制登入條件與多因素驗證；端點祕密儲存負責限制本機程序能否取用憑證。這些控制彼此相關，卻不能互相替代。若日常工作只需讀取程式碼，就不應因方便而讓同一身分具備套件發布或部署權限。

檢查紀錄時，應知道哪個系統能回答哪個問題：身分系統提供登入與權限異動，託管平台記錄權杖或應用程式的儲存庫操作，端點紀錄則協助追查本機程序。由平台管理者與資安人員共同確認保留期限及告警窗口，並測試撤銷憑證後哪些自動化工作會中斷。短效憑證可縮小可用時間，但仍須有負責人監看異常使用並按程序撤銷。

套件與自動化

檢查套件名稱、版本、來源、雜湊值、安裝腳本及內部命名空間是否有一致的審核流程。CI/CD 工作流程也要確認觸發條件、可取得的祕密與部署權限；建置工作若共用長期憑證或持續執行的工作站，惡意依賴項可能觸及其他工作。

套件盤點不只看清單，也要確認實際解析結果。鎖定檔可固定版本，但仍須核對套件來源、維護者變更與安裝時執行的腳本；雜湊比對能確認下載內容是否與核准版本一致，無法單獨證明原始套件安全。內部套件庫可協助統一來源和保留審核紀錄，但若任何開發者都能發布正式命名空間，內部來源仍可能成為擴散渠道。

自動化流程應逐一標出觸發者、執行身分、可讀取的祕密、產物存放位置及部署目的地。由平台工程維護工作流程範本，專案負責人確認必要權限，資安人員檢視例外與稽核紀錄。對外部貢獻、合併請求和標籤觸發的建置，可採不同的祕密暴露規則；不同平台提供的隔離能力並不一致，應以實際執行環境驗證。

建置紀錄要能連回程式碼提交、套件版本與執行身分，方便確認可疑產物由哪個工作流程產生。若建置節點會重複使用，需檢視工作間清理與快取是否可能留下前一工作殘留；若採短暫建置環境，也要確認日誌和產物仍能供稽核。隔離能限制部分橫向存取，卻不能取代權限縮減、來源驗證與監控。

四、先驗證套件，再收斂憑證與網路權限

先讓套件安裝經過核准清單、雜湊或其他來源驗證，再限制工作階段可取得的憑證，並把套件流量導向受控來源。

Mandiant 個案報告建議在 IDE 與命令列流程加入驗證機制，檢查 AI 推薦的第三方套件是否符合核准清單與密碼學雜湊條件。團隊也可把外部套件先導入內部儲存庫，經審核或隔離觀察後再供開發者使用。這些作法增加套件來源的可追溯性，無法保證每種惡意變更都會被攔下。

Mandiant 個案報告列出驗證 AI 推薦的第三方相依套件、使用密碼學雜湊與核准清單，也提到隔離本機憑證、限制開發工作站對外連線及讓套件流量經過安全的內部來源。這些是該個案報告明列的建議。

憑證方面，將長效權杖改為短效、按工作範圍核發的存取方式，並避免讓 IDE 擴充套件直接讀取原始金鑰。儲存庫端則可採用最小權限、分支保護、敏感操作審核及權限異動紀錄。自動化工作使用專用身分，並在任務結束後回收權限，能限制遭竊憑證的可用範圍；仍須配合使用紀錄監測、快速撤銷及事件應變，因為憑證在遭竊至撤銷之間仍可能被利用。

Google Cloud／Mandiant 的供應鏈緩解指引寫道：「組織應採用多層防禦策略，減少暴露並強化面對潛在入侵的韌性。」指引另提出依賴項清冊、短效自動化憑證、內部套件來源及隔離建置等控制，與前述個案報告所列建議分開理解。

NIST 的安全軟體開發框架則把安全環境、軟體保護、漏洞應變納入開發實務，團隊可以依既有流程和風險調整採用方式。短效憑證、內部套件庫或隔離建置仍各有維運成本：前者須管理續期和失效處理，套件庫須維持審核與更新速度，隔離環境則須確保紀錄、快取及產物仍可追溯。選擇控制時應一併指定維護角色與例外審核方式。

五、發現異常時依憑證、套件與儲存庫順序查核

先保存工作站與登入紀錄，再核對近期套件安裝、權杖使用、儲存庫變更和資料外傳跡象，必要時撤銷憑證並啟動事件應變程序。

調查時可從近期新裝或版本異動的套件、套件管理器設定與鎖定檔開始，對照員工或建置工作實際使用的版本。接著檢查 GitHub OAuth 權杖建立與使用紀錄、異常 IP 或非工作時段存取、權限擴張，以及未經審核的分支、工作流程和套件發布變更。

若出現憑證遭讀取或使用異常，需檢查儲存庫祕密、建置產物和對外連線紀錄，也要確認內部套件命名空間是否有陌生版本或發布者，並辨識其他工作站是否拉取過同一套件。這些是查核項目，不構成通用處置順序；緊急隔離端點、保全證據及撤銷憑證的先後，應依組織既有事件應變程序和當下風險決定。

調查紀錄可按資產建立時間線，列出可疑套件首次出現、權杖登入或操作、儲存庫變更、建置產物生成及外連活動。資安應變負責人統整證據與通報，程式碼平台管理者確認權限和變更，專案團隊協助判斷提交及套件是否預期。若憑證仍有遭利用風險，是否立即撤銷及如何補發，應由應變負責人依既定程序決定，同步記錄可能中斷的部署或建置工作。

復原時應檢視同一憑證曾接觸的儲存庫、套件發布權限和建置環境，確認可疑提交、版本與產物已處理，再恢復必要工作。若有內部套件遭發布，除了移除或封存該版本，也要確認下游專案是否已下載及是否存在快取副本。封存證據、界定受影響資產，再按組織應變程序復原與通知，才能把調查結果連回後續修補。

• AI 建議只提供候選套件，安裝前仍要核對套件名稱、來源、版本與雜湊。
• 盤點 AI 助手可接觸的憑證和儲存庫，再依權限範圍及擴散能力安排加固順序。
• 套件驗證、短效權杖、內部套件來源與隔離建置可降低風險，沒有單一措施能消除所有供應鏈威脅。

常見問題

Q1: 這起事件代表所有 AI 程式助手都不安全嗎？

不能這樣推論。Mandiant 公開的是一家未具名 SaaS 業者的單一個案，資料沒有指出特定 AI 產品漏洞，也未說明工作階段最初遭入侵的方式。

Q2: AI 助手推薦的套件可以直接安裝嗎？

建議依團隊套件政策先核對來源、套件名稱、版本及雜湊，必要時透過內部儲存庫審核後再安裝。助手推薦不能取代依賴項驗證。

Q3: 最先應該盤點哪一種權限？

從 AI 助手與 IDE 擴充套件可讀取的憑證開始，再查看這些憑證可存取哪些儲存庫、能否寫入或發布套件，以及是否被 CI/CD 共用。

Q4: 約百個儲存庫是精確受害數量嗎？

不是。Mandiant 的公開描述使用約數，應保留「約百個」的表述，不宜改寫成精確數字。

Q5: 發現可疑套件後，只刪除套件就夠了嗎？

不夠。還要檢查套件安裝期間可接觸的權杖、祕密、儲存庫變更及外連紀錄，並依事件應變程序評估是否需要撤銷憑證和檢查其他端點。