Skip to content

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

最佳实践

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

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

不这样做的风险包括但不限于:

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

示例场景及缓解策略:

  • 用户可能要求一个能访问文件系统的代理删除不应删除的文件,或读取包含敏感信息的文件内容。为缓解此风险,应将代理限制在仅使用特定目录,并且只允许其读取或写入安全的文件。考虑通过在容器中运行代理来进一步进行沙箱隔离。
  • 用户可能要求一个具有外部 API 写入权限的代理向该 API 写入恶意数据,或从该 API 删除数据。为缓解此风险,应授予代理只读 API 密钥,或将其限制为仅使用已对此类误用具有抵抗力的端点。
  • 用户可能要求一个能访问数据库的代理删除表或修改模式。为缓解此风险,应将凭证范围限定在代理需要访问的表,并考虑颁发只读(READ-ONLY)凭证。

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

报告开源软件漏洞

请按照以下流程报告与 LangChain 开源项目相关的安全漏洞:

  1. 在存在漏洞的 GitHub 仓库的 Security 选项卡上提交安全公告
  2. 发送电子邮件security@langchain.dev,通知我们您已提交安全问题以及提交该问题的仓库。

在报告漏洞之前,请查看上面的最佳实践,以了解我们认为什么是安全漏洞,什么是开发者的责任。

漏洞赏金资格

我们欢迎针对所有 LangChain 库的安全漏洞报告。但是,我们可能仅针对以下软件包中的漏洞提供临时漏洞赏金:

  • 由 LangChain 团队拥有和维护的核心库:langchain-corelangchain (v1)、langgraph 以及相关的检查点包(或其 JavaScript 等效包)。
  • 由 LangChain 团队维护的流行集成包(例如 langchain-openailangchain-anthropic 等,或其 JavaScript 等效包)。

漏洞必须存在于库代码本身,而不是示例代码或示例应用程序中。

我们欢迎针对所有其他 LangChain 软件包的报告,并将处理有效的安全问题,但在此范围之外的软件包将不会获得漏洞赏金。这包括 langchain-community,由于其社区驱动的性质,不符合漏洞赏金资格,但我们仍会接受并处理报告。

不在范围内的目标

以下内容不在安全漏洞报告范围内:

  • langchain-experimental:此仓库用于实验性代码,不在安全报告范围内(参见软件包警告)。
  • 示例和示例应用程序:示例代码和演示应用程序不在安全报告范围内。
  • 带有安全通知的代码:这将根据具体情况决定,但很可能不在范围内,因为代码已附有开发者应遵循的指南,以确保其应用程序的安全。
  • LangSmith 相关仓库或 API:请参见下面的报告 LangSmith 漏洞

报告 LangSmith 漏洞

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

其他安全问题

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

LangChain 中文文档