Skip to main content
LangChain 拥有庞大的集成生态系统,包括各种外部资源,如本地和远程文件系统、API 和数据库。这些集成允许开发人员创建多功能的应用程序,结合 LLM 的强大功能与访问、交互和操作外部资源的能力。

最佳实践

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

报告 OSS 漏洞

请使用以下流程报告与 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 漏洞

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

其他安全问题

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