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

最佳实践

在构建此类应用程序时,开发人员应牢记遵循良好的安全实践:
  • 限制权限:将权限范围具体限定到应用程序的需求。授予广泛或过度的权限可能会引入严重的安全漏洞。为避免此类漏洞,请根据您的应用程序情况考虑使用只读凭据、禁止访问敏感资源、使用沙箱技术(例如在容器中运行)、指定代理配置以控制外部请求等。
  • 预期潜在滥用:正如人类会犯错一样,大型语言模型(LLM)也会犯错。始终假设任何系统访问或凭据都可能被用于其分配权限所允许的任何方式。例如,如果一对数据库凭据允许删除数据,最安全的做法是假设任何能够使用这些凭据的 LLM 实际上都可能删除数据。
  • 纵深防御:没有哪种安全技术是完美的。微调和良好的链设计可以减少但不能消除大型语言模型(LLM)犯错的几率。最好结合多种分层安全方法,而不是依赖任何单一防御层来确保安全。例如:同时使用只读权限和沙箱技术,确保 LLM 只能访问明确供其使用的数据。
不这样做带来的风险包括但不限于:
  • 数据损坏或丢失。
  • 未经授权访问机密信息。
  • 关键资源的性能受损或可用性降低。
带有缓解策略的示例场景:
  • 用户可能会要求具有文件系统访问权限的智能体删除不应删除的文件,或读取包含敏感信息的文件内容。为缓解此风险,限制智能体仅使用特定目录,并仅允许其读取或写入安全可读写的文件。考虑通过在容器中运行智能体来进一步实施沙箱隔离。
  • 用户可能会要求具有外部 API 写权限的智能体向 API 写入恶意数据,或从该 API 删除数据。为缓解此风险,给予智能体只读 API 密钥,或限制其仅使用已能抵御此类滥用的端点。
  • 用户可能会要求具有数据库访问权限的智能体删除表或修改架构。为缓解此风险,将凭据范围限定为智能体需要访问的表,并考虑颁发只读凭据。
如果您正在构建访问外部资源(如文件系统、API 或数据库)的应用程序,请与公司的安全团队沟通,以确定如何最好地设计和保护您的应用程序。

报告开源软件漏洞

请使用以下流程报告与 LangChain 开源项目相关的安全漏洞:
  1. 提交安全公告:在存在漏洞的 GitHub 仓库的“安全”选项卡上提交。
  2. 发送电子邮件security@langchain.dev,通知我们您已提交安全问题以及提交的仓库名称。
在报告漏洞之前,请查看上面的 最佳实践,以了解我们如何界定安全漏洞与开发人员的责任。

漏洞赏金资格

我们欢迎所有 LangChain 库的安全漏洞报告。但是,我们可能仅针对以下包中的漏洞提供临时漏洞赏金:
  • LangChain 团队拥有和维护的核心库:langchain-core, langchain (v1), langgraph,以及相关检查点包(或其 JavaScript 等效物)
  • LangChain 团队维护的流行集成(例如,langchain-openai, langchain-anthropic 等,或其 JavaScript 等效物)
漏洞必须存在于库代码本身中,而非示例代码或示例应用程序中。 我们欢迎所有其他 LangChain 包的报告,并将处理有效的安全关切,但不在本范围内的包不会颁发漏洞赏金。这包括 langchain-community,由于其社区驱动的性质,不符合漏洞赏金资格,但我们仍会接受并处理相关报告。

范围外目标

以下内容不属于安全漏洞报告的范围:
  • langchain-experimental:此仓库用于实验性代码,不在安全报告范围内(参见 包警告)。
  • 示例和示例应用程序:示例代码和演示应用程序不在安全报告范围内。
  • 带有安全通知的代码:这将个案决定,但很可能不在范围内,因为代码已经记录了开发者应遵循的指导方针,以确保其应用程序安全。
  • LangSmith 相关仓库或 API:请参阅下面的 报告 LangSmith 漏洞

报告 LangSmith 漏洞

请通过电子邮件向 security@langchain.dev 报告与 LangSmith 相关的安全漏洞。

其他安全关切

对于任何其他安全关切,请通过 security@langchain.dev 联系我们。