OpenClaw 通过 OpenAI 的 Patch the Planet 倡议完成安全审计

# OpenClaw通过OpenAI“补丁星球”计划完成安全审计 来源：https://openclaw.ai/blog/openclaw-trail-of-bits-engagement-recap OpenClaw的安全保障是一项持续性工作，其中重要环节就是对过程中发现的问题及修复方案保持透明。 近期，OpenClaw通过OpenAI的[“补丁星球”计划](https://openai.com/index/patch-the-planet/)，与[Trail of Bits](https://www.trailofbits.com/)共同完成了一次全面的安全审计，帮助我们更清晰地认识到OpenClaw安全边界中需要强化的环节。现将审计结果公布如下。 **概要：** - Trail of Bits共提交了27份私有仓库安全建议和3个独立的加固型拉取请求。 - 在安全建议报告中，24份描述了具有危害等级划分的漏洞。其中23份被列为已确认漏洞（部分因在稳定版发布前已完成修复而未予公开），剩余1份涉及在提交报告前已修复的漏洞。 - 这24份报告的危害等级评定为：0个严重、2个高危、16个中危、6个低危。其余3项归类为纵深防御发现，因未跨越明确记录的信任边界，故未进行危害等级评定。 - 所有可操作问题均已修复，3个独立加固型拉取请求均已合并。 ## 协作流程 “补丁星球”计划结合了人工智能辅助的安全研究与人工审核。Trail of Bits采用Codex辅助的工作流程来查找问题并开发修复方案，随后进行人工验证，最终将结果提交给我们。 我们根据OpenClaw的信任模型和发布历史对每份报告进行审查。随后对通过审核的问题进行修复与测试，并通过私有GitHub安全建议渠道协调漏洞披露。 审查范围涵盖核心权限体系以及OpenClaw在各功能模块中处理用户数据的方式。尽管受影响的功能各异，但反复出现的安全挑战类型具有共性。 ## 权限应贯穿请求生命周期 最常见的问题是在操作步骤间丢失权限。某个请求可能以有限权限进入OpenClaw，但在启动其他后续工作时，这些权限限制却未能延续。 有时正确的解决方案是沿用原始权限；而有时后续工作本身就不需要相关访问权限——例如文件名生成器无需使用工具。 在OpenClaw体系中，后续工作绝不应仅因丢失原始请求上下文而获得额外权限。 ## 统一标识命名 OpenClaw有时会为同一实体保留多个命名以保持旧版配置兼容性。当安全检查识别一个名称，而系统后续却使用另一个名称时，就会出现问题。 这种情况既影响用户身份识别，也影响功能模块名称。解决方案是在应用安全策略前，明确系统实际将使用的标识。 ## 校验实际使用对象 多份报告指出，OpenClaw的校验操作与实际使用对象之间存在差异。 例如某个存档检查仅在部分内容上进行校验，但实际会提取全部内容。另一案例中，文件路径在OpenClaw批准后发生了变更。这些检查本身看似合理，但未覆盖最终操作。 解决方案是将审批绑定到将要使用的具体文件、身份或操作。若后续发生任何变更，OpenClaw需要重新进行检查。 ## 智能体工作过程中权限可能变更 部分功能仅在启动时检查权限，但在后续运行中并未持续验证。在配置中禁用某个功能时，可能无法及时中断已运行或已缓存的工作。 我们将权限检查点移至更接近实际使用的时刻。对于耗时较长的操作，OpenClaw可能还需要在返回结果前再次进行权限校验。 某项发现揭示了该问题：智能体可能在请求启动后长时间持续工作，因此仅启动时检查权限并不足够。若内存访问权限在运行开始时启用，而操作员中途禁用，该运行实例仍会持续读取内存直至结束。 修复方案是使工具在每次执行操作时都检查当前权限设置。该问题仅影响已获得授权的运行实例，但它表明权限变更也必须触达正在进行中的工作。 ## 安全协作的启示 只要OpenClaw在处理某个请求，权限和身份信息就必须贯穿其整个生命周期。安全检查必须精确应用于将要使用的具体资源，禁用访问权限必须能中断已运行中的工作。测试需要验证真实的安全边界，而不仅仅是测试偶然出现漏洞的辅助模块。 所有问题已在`main`分支修复，并随2026.8.1和2026.7.33长期支持稳定版发布。 感谢Samuel Judson、Lucas Bourtoule、Trail of Bits团队全体成员，以及OpenAI创建“补丁星球”计划。🦞