Zod 4.6.7 发布：来源证明、代码安全与防 AI 复刻是三件事

今天的新事件与上个月的事件分开看

GitHub 官方发布记录显示，v4.6.7 于 2026-10-12 16:30:32 UTC 发布，换算为北京时间 10 月 13 日 00:30:32；对应提交短标识为 b500a2e，完整标识见原始发布记录。npm 注册表另记包发布时间为 16:29:37.778 UTC，两者不是同一个时间字段。本文讨论这次发布及维护者的新说明，不把 9 月 21 日的安全事件改写成今天的新攻击，也没有安装或运行可疑代码。

历史提交出现在发布说明，不等于恶意包已分发

GitHub 的 9 月公告称，Zod 的相关恶意仓库变更没有进入 npm 发布流程。维护者于 10 月 12 日 17:17:12 UTC（北京时间 13 日 01:17:12）解释，自动发布说明包含已撤销提交；随后清理历史并发布 4.6.7，同时说明 4.6.6 的 provenance 受到影响。核验时注册表仍为两个版本列出 attestation 链接，但链接存在不代表验证成功；我们没有完成签名与来源关联的密码学验证。不能据此宣称当前 Zod 包含恶意代码，也不能宣称两个版本已通过安全认证。

来源可核验，仍然需要审查代码

npm 官方文档把 provenance 定义为包与源码、构建信息之间可核验的关联，并明确说明它不保证包没有恶意代码。因此至少要分开三个判断：是否拿到了预期的文件；该文件是否关联到预期源码与构建；程序行为是否符合信任与产品要求。前两项通过，不能推出第三项。单独核对摘要、看到签名标识或看到 provenance 链接，也不能互相替代，更不能直接证明一个应用难以被 AI 复刻。

对加固服务的启示：难读不能成为绕过审查的理由

我们的工程建议是给加固建立两套独立验收。交付验收记录输入摘要、明确授权的转换、工具版本、输出摘要与客户本地签名步骤，确认拿到的确实是本次任务结果。防复刻验收则比较同功能的未加固与加固构建，在相同模型、工具、时间和费用预算下，用隐藏行为测试检查重实现完成度。控制流复杂、字符串难读只能作为分析线索，不能替代这两个结果。若加固增加未知安装脚本、额外联网或过宽权限，应单独解释并验证，而不是以安全功能为名默认放行。

让 AI Agent 帮忙构建，但别让它替你授予所有权限

对独立开发者，一个可执行的小流程是先让 Agent 只整理版本、官方变更、文件清单和安装钩子，不让它边总结边自动安装未知历史提交。随后由明确的依赖策略决定哪些步骤可以执行：使用隔离构建环境，不挂载生产密钥和客户内容，把依赖审查、构建与发布权限分开。关闭安装脚本可能破坏正常依赖，因此先在测试副本验证，再为确实必要的脚本逐项批准。最后检查实际产物和自己的回归测试，不把 Agent 的“完成了”当作交付证明。

今天能得出的结论，以及还不能得出的结论

这是公开资料核验与工程分析，不是 Zod 的全面安全审计，也不是 Anti-AIClone 的加固效果报告。我们没有运行第三方攻击、验证客户应用或测出新的安全分数。来源证明帮助追溯“从哪里来”；安全审查关注“执行了什么”；防复刻实验回答“在这些条件下，别人能重做多少”。把三类证据写进不同字段，比合成一句“已加密、所以安全”更有用。离线应用同样可以采用这种交付与评测方法，不需要为了写一份报告增加服务器依赖。

行动清单

• 分别记录仓库事件、GitHub release 与注册表包的真实时间，不把旧事件包装成新攻击。
• 锁定实际交付的版本、摘要与构建关联；attestation 链接存在不记为验证通过。
• 让 Agent 先做只读依赖清单，执行安装钩子前明确授权与隔离范围。
• 分别验收交付完整性、运行行为和固定预算下的复刻完成度。
• 先验证正版功能、离线使用与签名兼容，再讨论加固提升。
• 保留未验证项和失败证据，不拿本文当作产品安全认证或新评分。