跳到主要內容
Open on GitHub

安全政策

LangChain 擁有龐大的生態系統，與各種外部資源（如本地和遠端檔案系統、API 和資料庫）整合。這些整合讓開發人員能夠創建多功能應用程式，將 LLM 的強大功能與存取、互動和操作外部資源的能力結合起來。

最佳實務​

在建構此類應用程式時，開發人員應記住遵循良好的安全實務

  • 限制權限：將權限範圍明確限定在應用程式的需求之內。授予廣泛或過多的權限可能會引入重大的安全漏洞。為了避免此類漏洞，請考慮使用唯讀憑證、禁止存取敏感資源、使用沙箱技術（例如在容器內執行）、指定代理配置以控制外部請求等等，這些都應根據您的應用程式的具體情況而定。
  • 預期潛在的濫用：正如人類可能犯錯一樣，大型語言模型 (LLM) 也可能犯錯。始終假設任何系統存取或憑證都可能以分配給它們的權限所允許的任何方式被使用。例如，如果一對資料庫憑證允許刪除資料，那麼最安全的做法是假設任何能夠使用這些憑證的 LLM 實際上都可能刪除資料。
  • 縱深防禦：沒有任何安全技術是完美的。微調和良好的鏈設計可以降低（但不能消除）大型語言模型 (LLM) 可能犯錯的機率。最好的做法是結合多層安全方法，而不是僅僅依賴單一的安全層來確保安全。例如：同時使用唯讀權限和沙箱，以確保 LLM 只能存取明確用於它們使用的資料。

不這樣做的風險包括但不限於

  • 資料損壞或遺失。
  • 未經授權存取機密資訊。
  • 關鍵資源的效能或可用性受到損害。

包含緩解策略的範例情境

  • 使用者可能會要求具有檔案系統存取權限的代理刪除不應刪除的檔案，或讀取包含敏感資訊的檔案內容。為了緩解這種情況，請將代理限制為僅使用特定目錄，並僅允許其讀取或寫入可以安全讀取或寫入的檔案。考慮透過在容器中執行代理來進一步沙箱化。
  • 使用者可能會要求具有外部 API 寫入權限的代理將惡意資料寫入 API，或從該 API 刪除資料。為了緩解這種情況，請為代理提供唯讀 API 金鑰，或將其限制為僅使用已能抵抗此類濫用的端點。
  • 使用者可能會要求具有資料庫存取權限的代理刪除表格或修改結構描述。為了緩解這種情況，請將憑證範圍限定為代理需要存取的表格，並考慮發出唯讀憑證。

如果您正在建構存取外部資源（如檔案系統、API 或資料庫）的應用程式，請考慮與您公司的安全團隊溝通，以確定如何最佳地設計和保護您的應用程式。

報告 OSS 漏洞​

LangChain 與 Protect AI 的 huntr 合作，為我們的開源專案提供漏洞賞金計畫。

請透過訪問以下連結報告與 LangChain 開源專案相關的安全漏洞

https://huntr.com/bounties/disclose/

在報告漏洞之前，請查看

  1. 以下範圍內目標和範圍外目標。
  2. langchain-ai/langchain monorepo 結構。
  3. 上面的最佳實務，以了解我們認為什麼是安全漏洞，什麼是開發人員責任。

範圍內目標​

以下套件和儲存庫符合漏洞賞金資格

  • langchain-core
  • langchain (請參閱例外情況)
  • langchain-community (請參閱例外情況)
  • langgraph
  • langserve

範圍外目標​

huntr 定義的所有範圍外目標以及

  • langchain-experimental：此儲存庫用於實驗性程式碼，不符合漏洞賞金資格 (請參閱套件警告)，向其提交的漏洞報告將被標記為有趣或浪費時間，並在不附加賞金的情況下發布。
  • 工具：langchain 或 langchain-community 中的工具不符合漏洞賞金資格。這包括以下目錄
    • libs/langchain/langchain/tools
    • libs/community/langchain_community/tools
    • 請查看最佳實務以了解更多詳細資訊，但一般而言，工具會與現實世界互動。開發人員應了解其程式碼的安全隱含意義，並對其工具的安全性負責。
  • 以安全注意事項記錄的程式碼。這將根據具體情況決定，但很可能不符合賞金資格，因為程式碼已經記錄了開發人員應遵循的指南，以使其應用程式安全。
  • 任何與 LangSmith 相關的儲存庫或 API (請參閱報告 LangSmith 漏洞)。

報告 LangSmith 漏洞​

請透過電子郵件向 security@langchain.dev 報告與 LangSmith 相關的安全漏洞。

其他安全疑慮​

對於任何其他安全疑慮，請透過 security@langchain.dev 與我們聯繫。

此頁面是否對您有幫助？