开源不是安全边界

2026年5月14日，英国Government Digital Service发布了面向公共部门的AI、开放代码与漏洞风险指南。该指南问对了问题：AI可能降低漏洞发现成本，但代码仓库的私密性仍然不会因此变成安全边界。¹

9天前的一篇公开报道提到，NHS England计划将数百个GitHub代码仓库设为私有，原因是内部担心AI漏洞工具可以大规模检查公开代码。²这种担忧可以理解，但拟议控制措施并不成立。隐藏代码等于把“发现”当作威胁；严肃的安全工作会把“未修复的弱点”当作威胁。

当团队减少真实暴露面时，开源安全才会改善：代码中没有密钥、例外规则清晰、代码仓库有人负责、披露路径可用、补丁发布迅速，并且有公开证据证明修复已经到达用户。代码仓库私有化可以支撑某个具体例外，但无法取代这套运转体系。

要点速览

GDS认为，公共部门团队应默认保持代码开放，审慎评估例外，并聚焦那些真正改变实际风险的因素。¹这个答案优于一场围绕代码仓库私有化的恐慌，因为公开代码可能已经存在于分支、镜像、缓存、包产物、容器镜像、截图、生成的客户端和既往克隆中。更重要的是，公开代码允许更多人检查、复用、报告问题并改进它。¹³

面对AI漏洞发现，正确回应不是“把一切都设为私有”。正确做法是：移除密钥，分类敏感代码，发布明确例外，运行依赖项和密钥扫描，维护漏洞披露路径，快速打补丁，并保留证据证明开放代码有明确负责人。¹⁴⁵

核心结论

• 对工程负责人而言：私有化可以在少数场景下降低暴露，但无法替代所有权、清单、补丁和披露机制。
• 对公共部门团队而言：只要配套明确的例外规则，默认开放依然有效。例外应覆盖密钥、欺诈控制、敏感架构和未发布政策。
• 对安全团队而言：AI提高了响应能力的价值。没有分诊路径的私有代码仓库仍然会失守。
• 对代理团队而言：代码可见性只是攻击面之一。工具权限、状态边界、出站控制和发布关口，比代码仓库看起来是否私有更重要。
• 对维护者而言：少制造神秘感。良好的文档、清晰的安全联系人和小而有主的服务，比一堵私有代码仓库之墙更能降低风险。

恐慌把可见性误认为漏洞

AI漏洞扫描器改变了检查工作的成本结构。过去，一个人需要时间、技能和耐心，才能搜索整个代码库。一个能力足够的模型可以更快检查更多代码，串联多个文件中的线索，并产出更多候选发现。这种变化会给本就代码脆弱、责任模糊、补丁路径缓慢的团队带来更大压力。

但代码仓库可见性并不等于漏洞。公开代码可能暴露一个bug，私有代码也可能包含同一个bug。攻击者往往可以从二进制文件、API流量、客户端包、软件包内容、容器层、日志、文档、依赖元数据或旧克隆中推断行为。GDS也提出了同样务实的观点：把一个曾经公开的代码仓库改为私有，并不一定能阻止有能力的对手访问，因为热门项目通常已有分支或镜像，即使是低调的代码仓库，也可能早已到达研究人员或攻击者手中。¹

这个提醒很重要，因为“关掉它”看起来像是在行动。但这种行动可能减少公共问责，却把技术弱点留在原处。团队可能失去外部审查、共享修复和复用机会，却很难阻止那些已经复制代码的人。

开源还会形成审计轨迹。公开历史显示谁改了什么、修复何时落地、维护者如何回应报告，以及项目是否仍在被积极维护。私有代码会向同行团队、供应商、研究人员和其他可能复用或改进工作的公共机构隐藏这些信号。

默认开放并不天真

GDS并没有主张每一行代码都应该出现在公共互联网上。较早的GOV.UK开源指南已经列出了保持代码闭源的正当理由，包括密钥、凭据、欺诈检测算法和未发布政策。³Technology Code of Practice也把开放性与安全和隐私义务放在一起，而不是让它们相互对立。⁴

更强的规则是默认开放，并设置具体例外。这种政策结构会迫使团队说清风险，而不是把“安全”当成包罗万象的分类。密钥不应该存在于代码仓库中。欺诈信号可能需要限制可见性。未发布政策服务可能需要限时保留。一个只是让人觉得尴尬的代码库，并不符合例外条件。

英国公共部门手册也指向同一方向。它描述了一项预期：在适当情况下，政府软件和代码应默认开源、以开放方式开发，并使用获批许可证发布。⁵DWP的开源代码发布政策遵循同样模式：鼓励以开放许可证发布，同时通过定义明确的控制措施保护敏感源代码。⁶

这种区分能够保护质量。公开写代码的团队往往会编写更好的README、更清楚的安装说明、更明晰的问题历史和更明确的数据边界，因为外部人员可能会阅读这些工作。GOV.UK指南指出，发布代码可以改善文档、可维护性、数据清晰度和安全反馈。³当团队面对AI压力而把一切掩埋起来时，这些收益就会消失。

真正的控制手段是修复速度

AI改变的是时钟。发现更快了。报告数量上升了。误报也会增加。我在当您的代理发现漏洞时中讨论过同样的能力压力：没有验证和修复，发现本身意义有限。团队需要分诊、责任人路由、补丁、披露和发布证据。代码仓库私有化无法提供其中任何一项。

CISA的Vulnerability Disclosure Policy平台正是为此存在。该平台为联邦民事机构提供渠道，用于接收、分诊并路由公共安全研究人员报告的漏洞。⁷CISA的协调漏洞披露计划也覆盖关键基础设施中的漏洞，包括开源软件和AI系统，并强调在公开披露前协调缓解措施。⁸

NCSC通过漏洞报告和披露指南，为英国组织提供了同样的运作框架，其中包括工具包和面向政府部门的现成报告路径。⁹共同主线很简单：承认外部人员会发现bug，然后让报告和修复机制真正运转起来。

这个框架会把AI漏洞发现从“隐藏代码的理由”转变为“改进响应闭环的理由”。如果模型能在您的公开代码中找到bug，团队应该问5个问题：

无论代码开放还是关闭，这些答案都会降低风险。隐藏代码仓库只会改变今天谁能看见源代码。它不会创造负责人、补丁或披露路径。

更好的决策规则

团队需要一条决策规则，把尴尬、暴露和真正的敏感性区分开来。

这条规则还可以避免一种常见失败：因为团队无法分类任何东西，所以把一切都关闭。代码仓库清单应回答服务做什么、接触哪些数据、由谁负责、运行哪些密钥扫描器、哪些依赖项重要，以及报告如何到达维护者。如果团队缺少这些答案，说明团队存在运作缺口。改变代码仓库可见性也许能把缺口从公众视野中藏起来，但缺口仍然存在。

代理让边界问题更大

AI编程代理让同一教训更加鲜明。代码仓库边界并不能阻止代理在允许权限内做出不安全决策。我在代理沙箱安全只是一种建议中写过这种模式：危险动作往往发生在权限集合之内，而不是之外。同样的组合问题也驱动了软件供应链攻击，即单个看似合理的部分组合成了一条有害路径。

不可见代理问题同样适用于开源政策。团队无法治理自己看不见的东西：工具路径、生成产物、缓存、发布状态、披露队列和所有权交接都很重要。

开源政策应该向代理安全学习。有用的边界存在于动作层和响应层：

• 在工具接触不可信输入之前先完成分类；
• 从代码、历史记录、日志、软件包和生成资产中移除密钥；
• 按信任级别隔离构建缓存和发布产物；
• 限制自动化工作流的出站网络路径；
• 在发布、部署或宣布修复完成前要求证据；
• 为外部研究人员提供安全且有文档说明的报告路径。

这些控制并不依赖源代码保密。它们依赖团队知道敏感材料位于哪里，以及哪些动作可能造成伤害。如果代码仓库包含真实密钥，在暴露之后把它设为私有是在解决错误问题。应当轮换密钥，尽可能从历史记录中移除它，使旧产物失效，并记录事件路径。发布边界之所以重要，是因为外部输出需要比本地分析更强的关口。

这就是GDS指南显得正确的原因。该指南没有否认AI会改变漏洞发现。它拒绝了肤浅结论。AI让弱系统更容易被检查，因此答案应当让系统更容易被负责、审计、报告和修复。

我今天会怎么做

面对AI驱动的代码仓库恐慌，团队应在改变默认策略前，先进行一次48小时开放代码审查：

1. 盘点公开代码仓库，并把每个仓库映射到负责人。
2. 对当前代码树和git历史运行密钥扫描。
3. 检查每个代码仓库是否有安全联系人或披露政策。
4. 识别欺诈、滥用、实时架构和未发布政策方面的例外。
5. 确认依赖项更新、补丁发布和回滚路径。
6. 只关闭或延迟那些符合具名例外的具体代码仓库。
7. 发布决策规则，避免未来团队重复恐慌。

这个计划为负责人提供了真实可控的操作面。它也会创造证据。未来审查者可以看到为什么某个代码仓库保持开放，为什么另一个转为私有，以及哪些工作降低了实际风险。

FAQ

AI会让公开代码更危险吗？

AI可以让公开代码更容易被检查，因此团队应预期收到更多漏洞报告，也会遇到更多自动化探测。危险来自未修复漏洞、暴露的密钥和薄弱的响应闭环。公开可见性可能增加发现概率，但私有化不会移除底层bug。¹

团队是否应该在某些情况下把代码仓库设为私有？

是的。团队应限制那些包含或暴露密钥、欺诈控制、敏感实时架构、未发布政策或其他具体伤害的代码。团队还应记录例外，并在理由失效时重新审视。³⁶

为什么不在审查完成前先全部关闭？

一刀切关闭会用真实的公共收益换取不确定的保护。GDS警告说，曾经公开的代码可能已经存在于镜像、分支或克隆副本中。¹短期、定向的审查优于一种无限期默认策略，因为后者只会隐藏所有权问题。

团队说一个公开代码仓库“足够安全”之前，它至少应包含什么？

至少应具备：没有密钥、明确负责人、许可证、清晰的安装说明、依赖项更新实践、安全联系人或漏洞披露路径，以及能够快速发布修复的发布流程。

这与AI编程代理有什么关系？

代理扩大了同一个边界问题。风险很少只存在于一个可见文件中。它存在于权限、生成产物、缓存、出站请求、构建状态和发布权限中。良好的代理安全和良好的开源政策，都需要在这些边界上提供证据。

参考资料