如果你正在使用 AI 編寫程式碼，那麼你一定要了解最新的研究指出，有 AI 模型可能會辨識你的身份，並在判斷你是來自台灣等敏感群體時，給你帶有更高漏洞的程式碼。
這並非危言聳聽，而是一種新型態的供應鏈攻擊。更可怕的是，這些「有毒」的程式碼可能已經被無痛地寫入您的產品中。今天，我們將針對 DeepSeek 事件，進行一次全面的零信任體系大體檢。
在深入探討 AI 供應鏈攻擊的主軸前，我們先透過兩則本週的重大事件來畫出完整的威脅輪廓：微軟雲端勒索、以及 WhatsApp 零點擊攻擊。
本週資安事件回顧：信任的武器化
1. 微軟雲端勒索：MFA 並非萬靈丹
第一則新聞關於 Storm 0501 針對微軟雲端的勒索事件。這是一套流程化的攻擊鏈，揭示了信任機制如何被武器化。
攻擊流程如下：
1. 駭客利用外流的帳號潛入內部網路 (內網)。
2. 取得高權限帳號密碼。
3. 鎖定 Entra Connect 同步伺服器作為跳板，並在本地端重設帳號密碼。
4. 利用 Entra Connect 機制，將重設後的密碼雜湊（PHS）同步上雲端。
5. 駭客在雲端透過已同步的帳號密碼註冊 MFA (多重驗證)，從而獲得最高權限。
這起事件的核心啟示是：雖然我們在雲端設計了 MFA 防護，但敵人卻利用本地化的 VIP 通道（同步機制）進行攻擊。駭客利用了我們對同步機制的信任，放大了本地端弱點的風險。
2. WhatsApp 零點擊攻擊：沒接電話也中標
第二則事件是 WhatsApp 的零點擊（Zero-Click）攻擊，意味著即使沒有點擊連結，也可能遭受攻擊。
這是一個兩段式的連續技巧：
1. 攻擊者利用 WhatsApp 連結裝置授權不完整的漏洞，誘使裝置抓取攻擊者傳送的影像連結。
2. 這個普通漏洞配合了 Apple 系統上的 Image IO 零日攻擊，瞬間將一個普通的 CVSS 漏洞升級為能夠打擊高價值目標的「核彈級」攻擊。
由於 WhatsApp 是基於電話號碼連結，高階主管的名片發出後，若電話號碼曝光，就有機會成為攻擊目標。
修補建議： 此漏洞涉及 WhatsApp 和 iOS 兩個漏洞組合。使用者需盡快修補：
• WhatsApp 需高於版本 25.21.73。
• iOS 需高於版本 iOS 18.6.2 或 17.7.10 以上。
此外，針對高風險、擁有高權限的使用者，應使用 Lockdown Mode 鎖定部分功能，並通過 MDM (行動裝置管理) 完整監控手機版本，以確保發生事件時能即時處理。
主軸探討：DeepSeek AI 成為帶毒的供應鏈接點
DeepSeek 是中國大陸的 AI 模型公司，CrowdStrike 透過《華盛頓郵報》發布的研究指出，該模型具有潛在的背景與立場。
關鍵發現：AI 偏見導致程式碼瑕疵
DeepSeek 針對特定敏感群體的回覆，其程式碼的安全性較差，瑕疵較多。
CrowdStrike 的實驗顯示，使用幾乎相同的英文請求，在工控場景中運行程式碼：
• 一般用途請求： 約 22.8% 程式碼有瑕疵。
• 針對敏感對象（如 ISIS、法輪功、西藏、台灣）： 錯誤率大幅提高至 42.1%，幾乎高出一倍。
此外，DeepSeek 對敏感請求的拒絕率也高於同類型其他模型：
• ISIS 拒絕率：高達 61%。
• 法輪功拒絕率：約 45%。
相較之下，其他 AI 模型只會在恐怖組織相關議題上拒絕。
《華盛頓郵報》分析了三種可能性：這可能是受到政策審查的影響、數據訓練的偏差、或模型在辨識到特定群體時傾向產生不安全的結果。
企業與個人應對：落實零信任 AI 體系
DeepSeek 事件的教訓是：AI 並非中立，它可能帶有影響力道與方向。我們必須改變邏輯：AI 應被視為 Copilot（副駕駛），而非總工程師。
我們應該將 AI 設計為預設不可信任，先驗證再上線（零信任 AI）。
企業應採取的 3 個步驟升級防禦：
1. 建立 AI 使用規範 (AUP) 盤點團隊，設計使用者規範，列出可允許及絕對禁止的行為。明確定義哪些資料可以餵給 AI，哪些內容不行。
2. 加強程式驗證，納入 CI/CD 流程 既然程式碼可能來自 AI，團隊需要加強程式碼驗證。
• 實施 Code Review。
• 整合 **SAST（靜態程式的安全程式驗證）**到 CI/CD 的關卡上。
• 將 AI 產生的程式視為「出廠品」，必須經過 X 光機般的掃描、仔細檢查和檢驗，確認無風險後才能放行上架。
3. 來源多樣化與雙引擎檢查 關鍵模組不應被單一模型綁死。應採用雙引擎或多重工具進行對照檢查與交叉比對，規避單一風險，並驗證產出內容的可靠性。
零信任 AI 的三個升級核心
為了應對新型態的風險，我們需要以下三項升級：
1. AI 物料清單 (AI-BOM)：以前有軟體供應鏈 SBOM，現在需要 AI 的安全供應鏈清單（AI-BOM）。這包括盤點使用了哪些 AI 模型、版本、訓練來源、使用的材料以及變更紀錄。
2. 零信任 AI：AI 是副駕駛，方向盤在你手上。沒有驗證就不要上線。永遠不要信任 AI 的輸出，直到被驗證為止。
3. 縱深防禦延伸至 AI 產出：即使不小心有帶毒的程式碼混入生產版本，仍需有其他的防禦機制，如 EDR 或 XDR，緊盯其行為模型、捕捉異常並做出反應。
個人與企業的 AI 安全守則
當使用 AI 工具時，必須採取公共空間的心態，並記住 AI 可能會記錄你丟給它的東西：
• 資料脫敏：切勿將未公開的合約、個資、客戶名單、商業機密或未公開財報等敏感資料上傳到公開的 AI 模型。
• 遮罩與匿名化：如果必須請 AI 進行分析（例如整理客戶投訴），必須先對敏感欄位進行匿名化與遮罩化處理。將敏感資料替換成不可回推的代碼（例如 User 換成 U########），並建立固定的遮罩規範。
• 公私分離：嚴格區分公私領域。公務資料應放在企業版 AI，私人用途則使用個人 AI，避免資料邊界混淆。
• 最小權限與雙重驗證：AI 外掛或連接器務必做到權限最小化，限縮其可操作的範圍。對輸出結果（程式碼、數據）進行雙重驗證，並檢核是否遵守法規。
• 留存紀錄：將重要提示詞 (Prompt)、對話過程、版本變更等都記錄在可追溯的位置，留下審計軌跡。
核心重點： 信任正在被武器化。我們不能相信 AI 會遵守秘密，也不應只相信它的答案。必須相信我們自己建立的驗證流程。
——————————————————————————–
