Skip to main content
Open on GitHub

安全策略

LangChain 拥有一个庞大的生态系统,可与各种外部资源集成,例如本地和远程文件系统、API 和数据库。这些集成使开发者能够创建多功能应用程序,将大型语言模型(LLM)的强大功能与访问、交互和操作外部资源的能力相结合。

最佳实践

在构建此类应用程序时,开发者应牢记遵循良好的安全实践:

  • 限制权限: 仅将权限范围限定在应用程序所需范围内。授予过宽或过多的权限可能会引入严重的安全漏洞。为避免此类漏洞,请根据应用程序的具体情况,考虑使用只读凭据、禁止访问敏感资源、使用沙箱技术(例如在容器内运行)、指定代理配置以控制外部请求等措施。
  • 预测潜在的滥用行为: 正如人类可能会犯错一样,大型语言模型(LLMs)也会犯错。始终假设任何系统访问权限或凭据都可能被以权限允许的任何方式使用。例如,如果一组数据库凭据允许删除数据,那么最安全的做法是假设任何能够使用这些凭据的LLM实际上可能会删除数据。
  • 纵深防御: 没有一种安全技术是完美的。微调和良好的链式设计可以降低大型语言模型(LLM)出错的概率,但无法完全消除这种风险。最好结合多种分层的安全方法,而不是依赖单一防护层来确保安全。例如:同时使用只读权限和沙箱机制,以确保大型语言模型只能访问明确授权的数据。

不这样做可能带来的风险包括但不限于:

  • 数据损坏或丢失。
  • 未经授权访问机密信息。
  • 关键资源的性能或可用性受损。

示例场景及缓解策略:

  • 用户可能会要求拥有文件系统访问权限的代理删除不应删除的文件,或读取包含敏感信息的文件内容。为缓解此风险,应将代理限制在特定目录内使用,并仅允许其读取或写入安全的文件。进一步地,可通过在容器中运行代理来实现更严格的沙箱隔离。
  • 用户可能要求拥有外部API写入权限的代理向该API写入恶意数据,或删除该API中的数据。为降低风险,应给予代理只读API密钥,或将代理限制为仅使用那些已具备防范此类滥用能力的端点。
  • 用户可能要求拥有数据库访问权限的代理删除表或修改模式。为降低风险,请将凭证权限限制在代理所需的表范围内,并考虑发放只读凭证。

如果你正在构建需要访问外部资源(如文件系统、API 或数据库)的应用程序,请考虑与你公司的安全团队沟通,以确定如何最佳地设计和保护你的应用程序。

报告OSS漏洞

LangChain 与 huntr by Protect AI 合作,为我们的开源项目提供赏金计划。

请通过以下链接报告与 LangChain 开源项目相关的安全漏洞:

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

在报告漏洞之前,请先查阅:

  1. 以下为在范围内的目标和不在范围内的目标。
  2. langchain-ai/langchain 仓库的结构。
  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 联系我们。