CodeMender 0.11更新扫描恢复与CI校验：当前仅限获准客户测试评估
2026年9月30日，Google Cloud公布CodeMender 0.11.0更新，重点放在安全扫描过程的可恢复性、配置正确性和沙箱执行。CodeMender由托管智能体与本地客户端组成，可辅助发现、验证和修补代码漏洞。此次更新并不代表全面开放：官方当前说明它仅向少量客户提供公开预览，需要联系销售团队获取访问，且只可用于有限测试与评估，不能用于商业或生产用途。
配图为AI生成的概念插图，表现隔离环境中的代码检查与修复，不是真实产品界面。
先读清预览边界，再谈自动修复
官方允许分析自有或已获授权的源代码，以及采用OSI认可许可证的开源代码，并要求用于合法防御。对于无法纠正严重错误的场景，文档要求不要使用这项预览服务。这些条件比“支持哪些编程语言”更早影响采用决策，不能在介绍功能时省略。
CodeMender的本地客户端不仅显示结果，也会代表智能体执行命令，且可能修改主机文件。默认的本地进程级沙箱提供隔离；关闭或绕过沙箱时，官方要求使用隔离虚拟机或容器保护主机。对于首次评估，准备一次性代码副本、明确可访问目录与网络范围，比把工具直接放到日常工作目录更稳妥。
严重性拼写错误，不再静默影响CI判断
0.11.0调整了cm find对--fail-on严重性值的处理：CRITICAL、HIGH、MEDIUM、LOW或NONE会提前验证，拼错的值不再被静默忽略。这是一项看似细小但直接影响自动化信任的变化。
如果团队打算在试验流水线里比较扫描结果，首先要确认“失败”由什么条件触发。配置拼错时继续运行，可能让一个绿色任务没有表达原本期望的安全门槛。升级后的测试因此不应只有正常值，还应故意提供无效值，确认系统清楚报告配置错误，且不会被外围脚本吞掉。
与此同时，服务位置配置改为使用CM_LOCATION环境变量或config.yaml中的location，默认global，并替代原有--location命令行参数。已有封装脚本需要核对参数来源，避免配置已经迁移而调用方式仍停留在旧版本。
中断可以恢复，但不同操作的边界并不相同
发布记录说明，独立的cm find、cm verify和cm fix会话在收到SIGINT或SIGTERM中断时会保留，可通过cm session resume继续；并行consensus工作器操作仍会取消。介绍时应保留这个差异，不能笼统写成“所有被中断任务都会继续”。
这一变化有助于评估长任务在终端断开、手动停止或资源波动后的行为。测试记录应包含最后完成的步骤、会话标识和恢复后的输出，确认没有遗漏或重复处理关键阶段。恢复执行与证明修复有效仍是两件不同的工作：重新接上会话，不会自动使候选补丁变成可信结论。
同一版本还扩展了HTTP 429限流重试，支持Retry-After、最长60秒配额补充等待窗口及自动流重连，并规范漏洞类型大小写和相对路径，减少重复发现。它们改善的是执行连续性与结果整理，公告没有给出新的漏报率或每种语言的正式评测结果。
沙箱中的分支操作与补丁审核一起验收
0.11.0为architecture会话默认沙箱工作器补充版本控制分支创建和候选分支清理，并加强模板展开对shell元字符及命令注入的防护。对使用者而言，这意味着测试应覆盖代码分支如何建立、补丁留在哪里以及失败后如何收回环境，而非只看终端最后一句“完成”。
官方概览也明确，产品没有发布正式的逐语言评测。团队应选择自己熟悉且已授权的样本，比较漏洞说明、验证证据、补丁内容与回归测试，保留人工审核。工具没有报告问题，只能表明这次运行没有给出发现，不能据此证明代码安全。
关于数据边界，官方表示客户端会发送有针对性的代码片段、漏洞信息、补丁和执行结果等，而非完整克隆仓库；会话数据最多保留7天以支持恢复。评估前仍应确认代码授权与组织规则。此次版本的实际看点，是让试验过程更容易检查和续接，而不是把受限预览包装成可直接接管生产安全的服务。
