Kerwin AI Information

標籤: AI 開發安全

  • Claude Code 供應鏈危機：AI 開發者太天真了

    Claude Code 供應鏈危機：AI 開發者太天真了

    📌 本文重點

    • AI coding agent 正在成為新攻擊面
    • 供應鏈攻擊已專門鎖定 AI 開發工具
    • AI 工具必須被當成高風險資安系統管理

    這次 Claude Code 事件真正可怕的地方，不是幾個 npm 套件被下毒，而是 AI coding agent 本身正在變成新的「攻擊面」。如果開發生態繼續只談效率、不談安全，下一個被入侵的，不會只是開發機器，而是整個企業的內部資料與用戶隱私。AI 工具與開發流程，必須被當成高風險資安系統，而不是玩具。

    一場「從 Red Hat 憑證到你的 Claude Code」的蠕蟲式攻擊

    先把時間線拉清楚：

    • 攻擊者先取得一名 Red Hat 員工的 GitHub 憑證，直接往 @redhat-cloud-services 旗下 32 個 npm 套件下手，這些套件週下載量約 11.7 萬次。
    • 由於 CI/CD 已與 npm 發布流程自動串接，攻擊者等於「合法地」用 Red Hat 的身份，把惡意程式碼發佈給整個開發者社群——這就是典型的 供應鏈攻擊。
    • 惡意程式碼安裝後，並不只藏在 node_modules，而是主動修改你的開發環境：
    • 植入 Claude Code 啟動設定
    • 修改 VS Code 專案設定
    • 之後 只要你打開 VS Code 或 Claude Code，惡意程式就會自動執行，
    • 靜默收集機器上的所有憑證（token、SSH key、雲端憑證……）
    • 傳回攻擊者伺服器
    • 更糟的是，就算你卸載 npm 套件，惡意碼仍活在 IDE 設定裡，持續運作
    • 若你試圖「先撤 token 再清 malware」，某些版本還會觸發毀滅性 payload：刪除整個 home 目錄並覆寫，降低復原可能性。
    • 幾天後，研究者在 npm 上又發現第二波、更高明的變種，包裝更隱密、具蠕蟲特性，持續透過自動安裝與開發工具擴散。

    💡 關鍵： 一組被盜用的 GitHub 憑證，串起了從 CI/CD 到 IDE、再到 AI 助手設定的整條自動化惡意供應鏈。

    關鍵不是一個 Red Hat 帳號被偷，而是：攻擊鏈一路打穿「憑證 → CI/CD → 套件 → IDE → AI 助手設定」，形成一條完全自動化的惡意供應鏈。

    這條鏈的最後一站，偏偏就是你以為「只是在幫你寫程式」的 Claude Code。

    AI coding agent 追求效率，卻默默放大了供應鏈風險

    這起 Red Hat / Claude Code 事件，和最近 Microsoft 開源套件被植入 credential stealer 的攻擊，實際上指向同一個趨勢：攻擊者已開始專門設計「針對 AI coding agent」的惡意程式。

    在 Microsoft 的案例中：

    • 73 個微軟持有的加簽開源套件被植入進階憑證竊取程式碼。
    • 惡意程式碼會在開發者透過 AI coding agent 開啟這些套件時被觸發——研究者直接點名這是針對 AI agent 的攻擊；AI 會幫你讀檔、跑 script、補依賴，攻擊者只要等 AI「乖乖照做」。
    • 這些套件最初是被 GitHub 自動系統下架，但平台一開始只用「違反服務條款」這種模糊說法，沒有明講「這是惡意攻擊、請假設你已被入侵」，讓不少開發者完全沒有警覺。

    把兩起事件放在一起看，可以看到幾個結構性問題：

    1. AI agent 天然信任依賴與腳本

    AI coding agent 的賣點，是幫你：

    • 自動安裝缺的套件
    • 自動修改設定
    • 自動產生/執行 script

    這看起來是「開發效率神器」，但在攻擊者眼中，這是一台可以遠端操控的自動化執行引擎。惡意套件只要被 AI 讀到、被 agent 視為「為了專案正常運作需要執行的 code」，攻擊就啟動了。

    2. DevSecOps 思維還停留在「人手動操作」時代

    大多數安全流程是為了人設計的：

    • 「請開發者檢查 pull request」
    • 「請手動審視依賴變更」
    • 「請不要執行不明腳本」

    但今天的問題是：AI 會幫你點掉所有這些紅燈。在 Claude Code 事件裡，惡意程式碼躲到 VS Code 與 Claude 設定檔中，只要開啟工作區或啟動 AI 助手，就會自動跑。

    3. 供應鏈攻擊變成「AI 時代的新常態」，不是個案

    • Red Hat / Claude Code：利用 GitHub 憑證 + CI/CD + IDE/AI 設定，形成蠕蟲式擴散。
    • Microsoft 套件：利用 加簽開源套件 + GitHub 生態 + AI coding agent 的自動操作，鎖定開發者憑證。

    它們都不是「某個工程師不小心點錯」這種等級，而是系統性利用 AI 進入開發供應鏈的空窗期。

    💡 關鍵： 供應鏈攻擊已從零星事件，演變成專門針對 AI 開發流程設計的「新常態」風險。

    真正的問題是：AI 工具商與生態平台，把自己當成「效率工具提供者」，沒有把自己當成「新一代 DevSecOps 基礎設施」來設計。

    這不是 Prompt Injection 問題，是「Agent 執行權限」問題

    今天的主角已經不是 prompt injection。攻擊者要的，不是讓模型講錯話，而是讓 agent 替他「按下執行鍵」。

    在 MCP（Model Context Protocol）與各種 Agent 框架被廣泛實驗的同時，安全研究者早就示警：

    • 當 AI 代理有「讀檔、寫檔、跑指令、打 API」等多重能力時，它就變成一個新的 高權限執行環境。
    • 文章《Red Teaming MCP Servers: 24 Attack Payloads and the Blueprint for Agentic Defense-in-Depth》做了 24 種紅隊測試，證明：
    • 單靠輸入過濾完全不夠
    • 必須從 輸入 → 代理決策 → 執行層 → 系統權限 做多層防禦

    再把這跟機器身份與憑證管理放在一起看：

    • 如《Your Secrets Are Probably Leaking》指出：大多數團隊只強化「使用者登入安全」，卻讓 API key、token、CI 變數、雲端憑證到處亂飛，形成 credential sprawl。
    • 在 Claude Code 與 Microsoft 事件中，惡意碼收割的正是這一整片「第二身份平面」：
    • .env 裡的密鑰
    • CI/CD pipeline 的 token
    • Terraform state、K8s manifest 裡的憑證

    當 AI agent 同時掌握「程式碼執行能力」與「存取這些機器身份憑證」，它就成了攻擊者最想控制的跳板。

    現在的主流 AI IDE 插件，多半只談：「我們如何讓你寫程式更快」。
    很少有人認真回答：「這個 agent 在你的機器上，到底能做多可怕的事？誰在監控？誰能審計？誰負責出事時的鑑識？」

    💡 關鍵： AI agent 一旦擁有執行權限與憑證存取能力，就等同於新的「高權限使用者」，安全設計必須對齊這個等級。

    開發者與企業現在就該做的事：把 AI 當成高風險資安系統來管理

    這不是「選不選用 Claude Code 或某個特定工具」的問題，而是你要不要承認：AI coding agent 已經是你 DevOps 流程的一級資產，而不是附加小幫手。

    對不同角色，建議也不同——

    1. AI 工具商（OpenAI / Anthropic / 微軟 等）

    • 預設零信任執行模型：
    • 插件/Agent 若要寫檔、跑命令、裝套件，應有細粒度權限 prompt，而不是一鍵授權整個專案。
    • 對高風險操作提供 可審計的執行日誌，預設加密留存，方便事後鑑識。
    • 把安全能力產品化，而不是當白皮書宣傳：
    • 內建 惡意依賴檢測、憑證泄漏掃描，而不是交給第三方插件救火。
    • 對應 MCP / Agent 生態，提供官方的 安全測試 sandbox（類似 mcp-probe-agent）與紅隊工具。

    2. 生態平台（npm / GitHub / VS Code 市集）

    • 事件揭露要說人話：像這次 GitHub 只說「違反服務條款」是嚴重失職。遭下架的套件，必須清楚標註「已確認惡意，請假設憑證外洩並執行 incident response」。
    • 加強供應鏈風險信號：
    • 對於高權限組織（如 Red Hat、Microsoft）發布的套件變更，提供額外的 異常行為檢測與人工審核。
    • 在 IDE / CLI 層面，當套件被標記惡意時，主動警示並提供修復腳本，而不是只在網頁上放通知。

    3. 企業開發與安全團隊

    • 把 AI 開發工具納入 DevSecOps 範圍，而不是當個人玩具：
    • 使用哪些 AI 插件、可開哪些權限，寫成政策並落地到 IAM / MDM 管理上。
    • 公司內部專案一律使用 企業控管的 AI 開發環境，禁止在個人亂裝的 VS Code 上操作敏感 repo。
    • 整頓「機器身份」與憑證管理：
    • 把 .env、CI variables、Terraform state、K8s yaml 裡的 secrets 全面盤點，導入 專業密鑰管理系統（如 Vault、Secrets Manager 等）。
    • 對應這次事件，預設所有受影響開發機器的 token 與 key 都已外洩，執行 rotate + log 監控。
    • 訓練團隊用「AI 安全威脅模型」思考：
    • 每導入一個新 AI 工具，都問三個問題：
      1. 它可以看到哪些 code / 資料？
      2. 它可以對我的環境做什麼？（讀/寫檔、跑指令、改 CI？）
      3. 一旦被接管，最大爆炸半徑是什麼？

    Claude Code 這次暴露的，不是單一產品的缺陷，而是整個產業對「AI 時代的 DevSecOps」普遍缺位。未來幾年，攻擊者會持續把 AI agent、CI/CD、開源套件、機器憑證串成一條條自動化攻擊鏈——而我們能做的，不是祈禱自己不要被點名，而是現在就把 AI 工具當成高風險系統，納入完整的安全設計、監控與治理。
    否則，AI 幫你省下的開發時間，很可能會全部補課在 incident response 上，而且還不一定補得回來。

    🚀 你現在可以做的事

    • 盤點並審視團隊現用的所有 AI 開發工具與 IDE 插件，標記其可存取的程式碼與憑證範圍
    • 在組織內導入或強化密鑰管理系統，將 .env、CI 變數等敏感資訊集中管控並定期輪替
    • 為團隊安排一場「AI + DevSecOps」安全工作坊，針對 AI agent 權限與供應鏈風險建立共同威脅模型