英国公共部门的人工智能、开放代码与漏洞风险

英国政府数字服务局与科学、创新和技术部于2026年5月14日联合发布了一份重要指南，旨在指导公共部门如何在人工智能（AI）加速漏洞发现的时代安全地开放源代码。该指南针对技术领导者们日益关注的问题：AI辅助的漏洞分析是否意味着公共部门应停止默认公开源代码？经过用户研究，指南明确指出，利用风险的主要驱动因素是系统中存在的弱点，包括未修补的漏洞、不安全的实现以及不安全的配置或部署，以及无法快速修复这些问题的能力。公开源代码本身并不会创造这些弱点，但它可能会适度降低攻击者的不确定性，并加快分析速度，尤其是在维护薄弱和修复缓慢的情况下。因此，该指南强化了安全运营公开访问服务所需的最低操作能力。

指南的核心建议包括：首先，确保系统达到公开访问的最低标准，包括明确的所有权、安全设计实践、自动化运维以及可靠的修复能力。其次，保持默认开放的态度，因为将所有代码设为私有会增加交付和政策成本，并减少重用和审查。第三，使例外情况明确并可审查，对于需要关闭的代码，要求提供简短的威胁模型，说明攻击者、公开代码带来的风险以及实际的伤害路径。第四，加强修复能力，假设发现到利用的时间窗口缩短，通过设置补丁服务等级协议、自动化依赖和漏洞管理，确保团队能快速响应报告。

指南回顾了政府现有的开源建议，强调用公共资金开发的代码应默认公开和可重用，仅有有限且合理的例外。这一原则体现在服务标准、技术实践守则、安全设计政策等多个标准中。指南假设团队不将源代码可见性作为主要的安全控制手段，而是遵循标准实践，如绝不将秘密（如凭证、API密钥、令牌和私钥）提交到任何仓库，并确保公共仓库不包含会显著增加可利用性的安全敏感实现细节，如内部主机名、IP范围、管理端点和安全控制阈值。即使有了这些控制，如果公开代码会创建特定、可信的伤害路径，团队可以作为合理的例外保持代码关闭，但这不应成为新的基线。

AI驱动的漏洞检测正在快速发展。英国AI安全研究所报告称，前沿模型在受控评估中展现出显著更强的网络能力，例如2025年12月的《前沿AI趋势报告》和2026年4月的《我们对Claude Mythos Preview网络能力的评估》。这意味着部门面临从发现到利用的时间窗口缩短。AI改变了分析的速度和规模，压缩了弱点存在到被利用的时间，使得修复能力比以往任何时候都重要。访问源代码可以给攻击者带来优势，减少不确定性并实现更快、更有针对性的审查，而且这种优势可能随着AI辅助而增长。然而，在实践中，这种优势相对于底层弱点的存在以及修补和缓解的速度通常是递增的。因此，领导者的判断不是源代码访问是否重要，而是实际中这种额外优势是否足够大，以至于有理由放弃默认公开的做法。攻击者已经可以在没有源代码的情况下发现弱点，例如通过探测运行服务、模糊测试或分析二进制文件和依赖项，而防御者可以使用相同的工具更快地进行审查和分类。

近期关于组织因AI代码分析而限制对公共仓库访问的公开报道表明，领导者可能在不确定性下迅速采取全面关闭措施。本指南提供了一个替代方案：保持默认公开，但将公开作为一个有意的决定，并辅以最低维护和修复标准。在实践中，生产风险主要受安全设计架构和实现、部署、配置、依赖项卫生和访问控制的影响，而不是受通过公开源代码可见的应用逻辑影响。许多严重漏洞是代码中的逻辑缺陷，但攻击者通常可以通过其他手段发现和利用它们。关键在于，源代码可见性通常改变的是发现时间和攻击者的不确定性，而不是是否存在弱点或缓解速度的主导决定因素。团队应专注于纵深防御方法，优先考虑安全设计交付、将秘密与代码分离、强大的环境控制、监控和快速修复。这些控制措施无论代码是公开还是私有都同样有效。

指南还列出了额外的考虑因素：私有仓库可能创造虚假的安全感，鼓励安全通过模糊实现的思想，并降低修复根本弱点的紧迫性；公开后关闭代码可能无法消除暴露，因为流行的仓库经常被镜像或分叉，即使低知名度的仓库也可能已被研究人员或攻击者索引或克隆；关闭可能成为一扇单向门，私有仓库减少重用和外部审查，随着时间的推移团队分化，使得再次公开代码更加困难；同样的工具可用于防御，开放性强化了这一纪律，而避免审查并不能消除缺陷，反而可能使弱点持续存在；开放性可以更早地暴露问题，公共代码允许更广泛的审查者发现问题，而关闭代码则将发现集中在交付团队和运营监控中；先例很重要，广泛的“AI”作为关闭的理由很容易被复制，一旦常态化，会破坏跨政府在重用和标准方面的一致性。

最后，指南提出了公开访问系统的最低标准：必须有指定的所有者和维护计划；安全联系人和报告渠道；没有秘密或敏感操作细节，并强制控制以防止提交秘密；安全设计基线，有证据表明系统遵循安全设计原则；自动化运维，包括依赖更新工具、漏洞和秘密扫描以及主干保护；补丁期望，有商定的关键和高危漏洞处理时间表；对未维护代码的安全姿态，如标记为存档并退役或明确所有者。将代码私有化并不能弥补缺乏所有权、补丁能力或运营保障的问题，因此无法安全维护的系统应进行修复或退役。如果团队无法达到最低标准，领导者应解决底层运营差距，例如通过共享服务配备能力，或退役不再需要的系统。只有系统达到最低运营标准后，领导者才能使用现有的例外规则，即公开其他方面维护良好的代码会创建特定、可信的伤害路径。本指南旨在避免“默认私有”的漂移，这种漂移掩盖了资源不足的维护。将代码从公开转为私有作为投资安全设计交付、所有权和修复的替代方案是一个警告信号，因为它减少了共享和审查，可能减缓跨政府和供应商的协调改进，并且无法消除运行服务中的根本弱点。各部门应将私有化视为针对特定、可信伤害路径的例外控制，而不是能力不足的补偿控制。