公司中最活躍的企業基礎設施之一是開發人員工作站。該筆記型電腦是憑證被建立、測試、快取、複製並在各種服務、機器人、建置工具以及如今的本地 AI 代理之間重複使用的地方。2026 年 3 月，威脅行為者 TeamPCP 證明了開發人員電腦的價值，他們對廣受歡迎、每日下載量達數百萬次的 AI 開發函式庫 LiteLLM 發動供應鏈攻擊，將開發端點轉變為系統化的憑證蒐集作業。該惡意軟體僅需存取磁碟上以明文形式存在的機密資料即可運作。

LiteLLM 攻擊：開發端點遭入侵的案例研究

該攻擊在執行上相當直接，但影響範圍極具破壞性。TeamPCP 入侵了 PyPI 上 LiteLLM 套件的 1.82.7 與 1.82.8 版本，植入資訊竊取型惡意軟體，當開發人員安裝或更新該套件時即會啟動。此惡意軟體系統性地從開發人員電腦中蒐集 SSH 金鑰、AWS、Azure 與 GCP 的雲端憑證、Docker 設定以及其他敏感資料。

PyPI 在偵測後數小時內即移除惡意套件，但受影響的時間窗口仍相當顯著。GitGuardian 的分析發現，有 1,705 個 PyPI 套件被設定為自動拉取受感染的 LiteLLM 版本作為相依套件。像 dspy（每月 500 萬次下載）、opik（300 萬）與 crawl4ai（140 萬）等熱門套件，在安裝時都可能觸發惡意軟體執行。這種連鎖效應意味著，即使未直接使用 LiteLLM 的組織，也可能因傳遞性相依關係而遭到入侵。

為何開發人員電腦是極具吸引力的攻擊目標

此類攻擊模式並非新穎，只是變得更加明顯。Shai-Hulud 行動曾大規模展現類似手法。GitGuardian 在分析該事件中 6,943 台受感染的開發人員電腦時，發現 33,185 個唯一機密，其中至少 3,760 個仍然有效。更引人注目的是，每個仍有效的機密平均出現在同一台電腦的約八個不同位置，且 59% 的受感染系統為 CI/CD 執行節點，而非個人筆記型電腦。

對手如今透過受感染的相依套件、惡意外掛或被汙染的更新滲透至工具鏈。一旦進入，他們便以安全團隊掃描漏洞的系統化方式蒐集本地環境資料，但其目標是儲存在 .env 檔案、Shell 設定檔、終端機歷史紀錄、IDE 設定、快取權杖、建置產物以及 AI 代理記憶體儲存中的憑證。

明文機密無所不在

LiteLLM 惡意軟體之所以成功，是因為開發人員電腦中集中存放了大量以明文形式存在的憑證。機密資訊散落於原始碼樹、本地設定檔、除錯輸出、複製的終端機指令、環境變數與臨時腳本中。原本僅供本地使用的 .env 檔案逐漸成為程式碼庫的永久組成部分。便利性轉變為殘留物，而殘留物最終成為攻擊機會。

開發人員運行代理程式、本地 MCP 伺服器、CLI 工具、IDE 擴充功能、建置管線與檢索工作流程，皆需使用憑證。這些憑證分散於惡意軟體熟知的路徑，例如：~/.aws/credentials、~/.config/gh/config.yml、專案 .env 檔案、Shell 歷史紀錄以及代理設定目錄。

大規模保護開發端點

在每個累積憑證的開發端點上建立持續性防護至關重要，GitGuardian 透過將機密安全防護從程式碼庫延伸至開發人員電腦本身來實現此目標。LiteLLM 攻擊展示了當憑證以明文形式分散於開發端點時可能發生的情況。以下是一些可以降低這種風險的方法。

了解您的暴露風險

從可視性開始。將工作站視為機密掃描的主要環境，而非事後考量。使用 ggshield 掃描本地程式碼庫中遺留於程式碼或 Git 歷史中的憑證，並掃描 Git 之外的檔案系統路徑，例如專案工作區、dotfiles、建置輸出以及本地 AI 工具產生日誌、快取與「記憶」儲存的代理資料夾。

ggshield 檢測路徑中特定文件中的秘密訊息

不要假設環境變數是安全的，僅因其未儲存在檔案中。Shell 設定檔、IDE 設定與產生的產物通常會將環境變數永久保存於磁碟。應以與掃描程式碼庫相同的方式掃描這些位置。添加 ggshield 的 pre-commit 鉤子，以防止在清理舊漏洞的同時，在提交中創建新的漏洞。這會將秘密偵測變成一種預設的防護措施，在錯誤演變成安全事件之前將其捕獲。

ggshield pre-commit 指令捕捉到秘密

將機密移入保險庫

僅偵測而無修復只是徒增雜訊。當憑證外洩時，修復通常需要多個團隊協作：安全團隊識別暴露、基礎架構團隊負責服務、原始開發者可能已離職，而產品團隊則擔心影響生產環境。若缺乏明確的責任歸屬與工作流程自動化，修復往往被延後。

解決方案是將機密視為具備明確擁有者、生命週期政策與自動化修復流程的受管身分。將憑證移至集中式保險庫基礎架構，使安全團隊能夠強制執行輪替排程、存取政策與使用監控，並將事件管理整合至既有的工單系統中。

GitGuardian 分析顯示了受監控金鑰的狀態

將 AI 代理視為憑證風險

代理型工具可讀取檔案、執行指令並傳輸資料。以 OpenClaw 類型代理為例，其「記憶」實際上是儲存在磁碟上（如 SOUL.md、MEMORY.md）的檔案，且位於可預測的位置。切勿將憑證貼入代理對話中，亦勿為日後使用而向代理傳授機密，並應定期掃描代理記憶檔案作為敏感資料儲存區。

消除整類機密

降低機密擴散的最快方式是消除對整類共享機密的需求。在人員端，採用 WebAuthn（通行金鑰）取代密碼；在工作負載端，遷移至 OIDC 聯盟驗證，使管線不再依賴儲存的雲端金鑰與服務帳戶機密。

使用短時效憑證

若尚無法完全消除機密，應使其具備短時效並可自動替換。使用 SPIFFE 發行可自動輪替的加密身分文件（SVID），以取代靜態 API 金鑰。優先處理長期有效的雲端金鑰、部署權杖與開發人員為便利而本地保存的服務憑證。

使用蜜罐權杖作為早期預警系統

蜜罐權杖可提供過渡性防護。將誘餌憑證放置於攻擊者常鎖定的位置，例如開發人員主目錄、常見設定路徑及代理記憶儲存。當這些權杖被蒐集並驗證時，將立即觸發警報，將偵測時間從「數週後發現損害」縮短為「攻擊發生時即時察覺」。

開發人員端點如今已成為關鍵基礎設施的一部分，位於權限、信任與執行的交會點。LiteLLM 事件證明，攻擊者對此的理解往往超越多數安全計畫。將開發人員電腦以與生產系統相同的治理紀律進行管理的組織，將更有能力在下一次供應鏈攻擊中存續。

資料來源：https://thehackernews.com/2026/04/how-litellm-turned-developer-machines.html