【Wiz 研究報告】辨識 AI Secrets 漏洞模式，優化 DevSecOps 防護策略
- Estrella Wei
- 6月19日
- 讀畢需時 8 分鐘
已更新：9月22日
作者：Shay Berkovich、Rami McCarthy ｜ 編譯：AIShield 編輯部 ｜ 發稿日期：2025 年 6 月 19 日
AI 輔助開發如何影響祕密（Secrets）外洩？一起了解新型態模式與新興趨勢。
AI 讓開發變快，風險也跟著擴散
許多開發者和技術人員為了趕著擁抱 AI、搶著嘗試，常常便宜行事。這從近期好幾起資安事件就能看出端倪，像是：
平台資源濫用： 攻擊者挾持雲端基礎設施，拿來跑他們自己的大型語言模型（LLM）應用程式。
廠商提供不安全的第三方模型執行： 例如 Probllama。
代管服務的模型外洩漏洞： Replicate、HuggingFace 和 SAP-AI 都曾發生過類似的漏洞。
而這些倉促行事造成的另一項副作用，就是 AI 相關機密外洩到公開程式碼儲存庫。程式碼儲存庫洩漏機密早就不是新聞，但令人訝異的是，經過多年研究、無數次資安事件、上百萬美元的抓漏獎金，以及大眾對資安風險的普遍認知後，想在公開儲存庫找到有效的機密還是輕而易舉。
重點懶人包
這篇部落格文章呈現了我們為期一個月、掃描公開程式碼儲存庫中有效機密的成果。分析完資料集後，我們驚訝地發現，AI 相關的機密佔了絕大多數（找到的前五名機密中，有四項都跟 AI 有關）。這促使我們進一步深入調查，歸納出三種 AI 機密外洩的獨特使用情境：
Python Notebook 的 .ipynb 檔案成為洩密重災區。
機密藏在 mcp.json、.env 和 AI 代理程式設定檔裡。Vibe coders 不熟悉機密管理最佳實務，他們的 AI 程式助理也一樣。
新興 AI 廠商的新機密類型無所不在，但機密掃描產業似乎跟不上。
我們發現了超過 30 家公司和新創公司的有效機密，其中不乏財星百大企業。希望這篇文章能為 AI 和資料科學社群敲響警鐘，呼籲大家趕緊改善開發習慣。
背景與方法
機密外洩到公開儲存庫早已是常見的攻擊途徑。Uber（2016）、加拿大豐業銀行（2019）、賓士（2024），以及最近的 xAI 機密外洩事件都只是其中幾個著名案例。事實上，被竊取或外洩的機密是許多知名供應鏈攻擊（例如 Codecov 事件）的主要攻擊媒介。GitHub 身為最受歡迎的程式碼代管平台（我們的《程式碼資安報告》指出 GitHub 佔了 81% 的儲存庫市佔率），自然也成了惡意攻擊者和資安研究人員共同關注的焦點。
Wiz Code 內建了機密掃描器，能為客戶提供保護。Wiz Research 則透過持續調查公開儲存庫和機密外洩的新興模式來支援產品。這次，我們不像《程式碼資安報告》那樣，而是把重點放在公開環境，撒下天羅地網。而且我們不像其他機密研究那樣，我們特別關心「經過驗證的機密」。這樣一來，就能自動過濾掉誤判和測試模式，進而得到更高品質的訊號。
簡而言之，我們掃描了上千個儲存庫，找到了數百個經過驗證的機密，其中許多至今仍然有效。這篇部落格文章的重點在於造成這些外洩事件的宏觀趨勢。雖然我們不會分享選擇掃描目標的完整方法，但只要專注於開發活動，就能比大多數機密研究中那種單純鎖定儲存庫受歡迎程度的方法，顯著提升效果。
整體趨勢
在機密出現的頻率方面，我們發現不同類型的機密之間存在很大差異：
前五名中最常見的三種，以及前十名中有一半的有效機密都與 AI 有關。這個結果很值得注意，因為我們並沒有刻意鎖定 AI 相關的儲存庫。然而，AI 機密卻佔了已識別外洩機密這麼大的比例。這個發現促使我們更深入研究 AI 相關的機密外洩。
此外，我們想了解機密的「地點」參數，以回答這個問題：哪些檔案類型包含最多機密？（因此，值得掃描器和資安政策特別關注）。結果發現，有一種檔案類型特別突出，那就是：Notebook ipynb 檔案。
Notebook 中出現機密並不是什麼新發現。自 2020 年以來，已經有幾篇不錯的相關出版物（例如這裡），但這個主題並沒有引起廣泛關注。這很可惜，因為 Notebook 作為洩漏機密的來源，其領先其他檔案類型的程度是顯而易見的。
另一個有趣的問題是檔案類型和機密類型之間的關聯性。您會預期在這類檔案中看到哪種機密？這樣的判斷也有助於調整機密掃描器和掃描政策。這些關係很有趣：
檔案類型 | 最常見機密 | 次常見機密 | 第三常見機密 |
ipynb | HuggingFace | AzureOpenAI | WeightsAndBiases |
python | HuggingFace | ||
.env | HuggingFace | ||
yaml | WeightsAndBiases | ||
json | AzureOpenAI | ||
md | Postgres | ||
sh | WeightsAndBiases | ||
ts | AlgoliaAdminKey | ||
js | AlgoliaAdminKey |
只有排名第六的 md 檔案，最常見的外洩機密才是傳統的 Postgres 憑證。
AI 開發加速機密外洩的趨勢
由於 AI 機密佔了絕大多數的發現，我們自然想更深入了解導致機密外洩的使用情境。
Python Notebooks
如前所述，ipynb 檔案是目前最容易洩漏機密的檔案類型。這是因為它們獨特的結合了程式碼、程式碼輸出和描述性元素。根據 JupyterLab docs，Notebook 是一個「可共享的文件，結合了電腦程式碼、自然語言描述、資料、豐富的可視化（如 3D 模型、圖表、圖形和圖像）以及互動式控制」。因此，對於如何處理這些檔案產生了自然而然的混淆——是當作日誌、程式碼還是文字。由於 .gitignore 檔案表達能力不足，無法區分不同用例——要嘛允許檢查 ipynb 檔案，要嘛不允許，無論該檔案是否包含執行輸出，都加劇了這個問題。
我們可以從中學到幾種不同的洩漏模式。最明顯的是直接在原始碼中使用機密；這可以是 Python 片段中嵌入的機密，也可以是註解：
另一種常見的使用模式是在執行輸出中傾倒機密。顯然， print() 函數可以做到這一點，然而，由於 Notebook 的互動性質，單純輸入變數也會將其列印出來。在下面的範例中，即使開發人員已經使用正確的方法從環境中載入 API 金鑰 （load_dotenv(); os.environ["AZURE_OPENAI_API_KEY"] = os.environ.get("API_KEY")），後續列印載入的設定檔動作卻讓程式碼變得不安全：
此外，還有更微妙的無意間洩露機密的方式——透過使用偵錯和診斷功能。在以下範例中，show() 和 list() 函數的輸出，除了其他內容外，還包含了 API 金鑰：
最後，由於 Notebook 中大量失敗的輸出，也常常會觀察到與本機開發設定、檔案系統佈局和網路相關的敏感細節，就像這些錯誤訊息一樣：
除了機密之外，Python Notebook 中的程式碼執行結果通常應視為敏感資訊。如果其內容與開發人員的組織相關聯，可能會為惡意攻擊者提供情資。
「隨手寫」進 mcp.json 的機密
AI 輔助程式碼生成以偏愛硬寫機密而聞名。這與模型上下文協議（Model Context Protocol, MCP）伺服器的興起形成了危險的組合。MCP 是一項快速發展的技術，在發布後幾個月內就啟動了數千個伺服器。
不幸的是，許多 MCP 伺服器偏好透過 mcp.json 設定檔中硬寫憑證來進行配置。舉個例子，一個非官方的 Perplexity MCP 伺服器使用說明就是如此。
Taskmaster AI 是另一個廣受歡迎的伺服器（超過 1.1 萬個星），也提出了這種不安全的建議——影響了 OpenAI 和 Anthropic 等 AI 供應商的客戶機密：
不幸的是，這種模式很普遍，甚至連官方的 Github MCP 伺服器都受到影響。一旦這些機密被硬寫到 mcp.json 中，就很容易理解它們是如何公開洩漏的。
當前機密掃描工具的不足與 AI 資安盲點
透過簡單的 GitHub 搜尋仍能輕易找到機密，這令人擔憂。AI 正在加速程式碼的撰寫過程，而機密洩漏的增加似乎是其副作用。
GitHub 的機密掃描功能具有變革性——對支援平台的自動修復已大幅減少重大事件。但掃描依賴於相關平台與 GitHub 掃描器的整合，導致覆蓋範圍有限。此外，大多數整合不會自動撤銷機密，以避免中斷客戶操作。取捨之下，我們看到了許多本應由 GitHub 掃描器檢測並發出警報的機密，卻沒有得到修復，或者至少沒有及時修復。
檢視流行的機密掃描工具時，我們發現儘管它們支援數百種機密類型，但它們仍無法跟上創新速度。基於模式匹配的方法將永遠落後於新機密，並且不適用於所有類型的機密。
這就是為什麼 Wiz Research 採用多樣化的機密檢測方法，例如我們最近在 BSidesSF 關於「使用小型 LLM 增強網路安全中的機密檢測」的演講。
以中國的 AI 巨頭為例：這些平台廣受歡迎，但卻被西方中心的平台和工具所忽視。GitHub 與這些平台共享龐大的用戶群。結果呢？與西方平台相比，中國 AI 平台的憑證洩漏量驚人，而西方平台的洩漏則會自動檢測並報告。
然而，甚至更常見的 AI 服務也經常被機密掃描器遺漏。
我們根據在程式碼中驗證過的機密搜索結果，整理了一份被一個或多個流行機密掃描工具遺漏的 AI 機密清單：
常見 | 不太常見 | 亞洲地區常被忽略的 AI 平台 |
Perplexity、Weights & Biases、Groq、NVIDIA API | LangChain、Cohere、Gemini、Fireworks AI 等 | Zhipu AI, Moonshot AI, Baichuan Intelligence, 01.AI, StepFun, MiniMax |
小撇步：作為 WizCode 和 WizCloud 的一部分，我們的機密掃描模組現在可以偵測到絕大多數上述機密類型。此外，我們正在努力將其餘機密類型納入基於 AI 的分類中。
對公司的影響
我們發現的機密中，大約有三分之一屬於個人專案，其餘則平均分佈在公司、公司員工、新創公司、開源專案和研究/大學專案之間：
這表示大約 40% 被發現的機密可能對公司產生實際影響。我們找到了超過 30 家公司和新創公司的有效機密，其中包含多家財星百大企業。舉個例子：我們向微軟資安響應中心（MSRC）回報的一項機密被評定為「嚴重」等級，可能導致敏感的人力資源資料外洩。
另一個特別有趣的發現是：56% 影響公司的機密，是在公司員工的個人儲存庫中發現的，而不是在公司組織本身的儲存庫中。這凸顯了因周邊資訊導致的發現的危險，但這將是另一篇部落格文章的故事了。
由於我們沒有進行系統性研究，因此無法說明受影響公司的總體百分比。我們能說的是，我們檢查的組織中約有 20% 發現了外洩的機密。這表明這些初步發現只是冰山一角。
重點與揭露
總而言之，我們的研究凸顯了幾個重要訊息，所有這些訊息都因 AI 採用和演進的瘋狂速度而更顯突出：AI 供應商不斷增加，隨之而來的是新的機密類型和新的機密使用情境。另一方面，AI 程式碼的進步帶來了「AI 自動化」的開發環境設定方式。這種設定方式往往容易洩漏機密。
好消息是，大部分的緩解措施仍然相同——提交前（pre-commit）的機密掃描掛鉤、定期掃描、CI/CD 管道整合和 Git 歷史掃描。當然，前提是現有的機密掃描器能跟上不足之處。將新的機密類型和使用模式整合到現有的保護和偵測流程中，必須伴隨著對使用情境的仔細審查。例如，您的組織如何使用 ipynb 檔案？有沒有政策禁止帶有執行輸出的 Notebook 檢查入庫？您的機密掃描器是否掃描不可渲染/大型 ipynb 檔案？
此專案結束後，我們的研究團隊已向客戶、合作夥伴和第三方公司揭露了最突出的發現。最困難的部分是向沒有專門資安團隊的小型新創公司報告這些看似生產級別的機密洩漏。壓倒性多數透過 LinkedIn / X / 電子郵件首次聯繫創辦人或 GitHub 組織成員的嘗試都石沉大海，因此我們不詳細披露這些發現。希望我們能在即將舉行的會議中進一步討論並擴展偵測方法。
想知道你的組織是否暴露於類似風險？
立即預約我們的技術顧問：contact@aishield.com.tw，獲得專屬診斷建議。
本文翻譯自 Wiz 原文：“ Leaking Secrets in the Age of AI ”
發佈日期：2025 年 6 月 17 日
原文和圖片出處：Wiz 部落格文章
