英国GDS公开反对NHS关闭开源仓库：AI时代开放与安全之争

NHS因AI安全漏洞一刀切关闭开源代码仓库

英国国家医疗服务体系（NHS）此前做出了一个备受争议的决定——关闭其开源代码仓库的公开访问权限。NHS是全球最大的单一支付者医疗系统之一，服务超过6500万人口，其数字化转型涉及大量软件系统的开发与维护。NHS的开源代码仓库托管在GitHub等平台上，包含从患者预约系统到数据分析工具等多种项目。开源（Open Source）是一种软件开发模式，指将源代码公开发布，允许任何人查看、使用、修改和分发。公共部门采用开源策略的核心理念是：纳税人资助开发的代码应当对公众透明，同时通过社区协作提高代码质量和安全性。英国政府自2012年起就将"默认开放"作为数字服务的核心原则之一。

事件起因是 Project Glasswing 项目向NHS报告了一系列安全漏洞，指出AI技术可被用于扫描和利用公开代码中的安全缺陷。Project Glasswing是一个专注于AI安全研究的项目，其核心发现在于：现代大语言模型（LLM）如GPT系列、Claude等已经具备了自动化分析代码库、识别常见安全漏洞模式的能力。传统的代码安全扫描依赖于预定义的规则和已知漏洞特征库（如OWASP Top 10中列举的SQL注入、跨站脚本攻击等），而AI工具能够进行更深层次的语义分析，甚至发现人类审查员可能遗漏的逻辑漏洞。这种能力的"民主化"意味着攻击门槛大幅降低——以往需要资深安全专家花费数周才能完成的代码审计工作，现在可能被AI在数小时内完成。

然而，NHS的应对方式被广泛认为是"考虑不周"的。与其针对性地修复漏洞，NHS选择了一刀切地将所有开源仓库转为私有，这在开源社区和英国公共部门内部引发了强烈反响。科技博主Terence Eden持续跟踪报道了这一事件，称其为"NHS向开源宣战"。

GDS发布官方指南：开放代码应是默认立场

2026年5月14日，英国政府数字服务部门（Government Digital Service，简称GDS）发布了一份名为《AI、开放代码与公共部门的漏洞风险》的官方指南，正式介入了这场关于开源安全的争论。

GDS成立于2011年，隶属于英国内阁办公室，是英国数字政府转型的核心推动力量。GDS负责制定跨政府的数字标准和技术指南，其发布的《服务标准》（Service Standard）和《技术行为准则》（Technology Code of Practice）对所有中央政府部门具有约束力。GDS在全球数字政府领域享有极高声誉，其推行的"政府即平台"（Government as a Platform）理念和GOV.UK统一门户网站被多国效仿。GDS发布的指南虽然在法律上不具有强制执行力，但在政策层面具有极强的权威性和导向作用，各部门通常会将其视为事实上的标准来遵循。

GDS的核心建议非常明确：

保持默认开放。 将所有内容转为私有会增加额外的交付和政策成本，并可能减少代码的复用和审查。开放应当保持为默认姿态，关闭仅在必要时谨慎、有针对性地使用。

这一立场与NHS关闭开源仓库的做法形成了鲜明对比。GDS认为，面对AI带来的新型代码安全风险，正确的应对方式不是退回到封闭状态，而是在保持开放的前提下，有针对性地管理风险。

英国公务员体系内罕见的公开分歧

你可能没注意到，GDS在指南中并未直接点名NHS。但熟悉英国公务员文化的Terence Eden认为，这实际上代表了一次重大的内部升级。他用了一个生动的比喻来解释：

在英国公务员体系中，你偶尔会听到"被邀请参加一场没有饼干的会议"这种说法。这意味着一场相当冷淡的讨论，没有正常会议中的礼貌客套。一般来说，即使人们有严重分歧，也很少会撕破脸。而这些内部分歧公开化的情况更是极为罕见。

英国公务员体系（Civil Service）有着数百年的传统，以政治中立、专业性和内部协调著称。在这一体系中，部门间的分歧通常通过内部备忘录、跨部门委员会和私下协商来解决，极少诉诸公开渠道。所谓"没有饼干的会议"是公务员圈子里的一个隐喻：英国职场文化中，正式会议通常会提供茶点和饼干作为基本礼仪，而"没有饼干"暗示这是一场不友好的、带有批评性质的对话。GDS选择通过公开发布官方指南来表达立场，而非通过内部渠道与NHS沟通，这在英国政府的运作惯例中确实是一种异常强烈的信号，几乎等同于公开表示"我们认为你们的做法是错误的"。

换言之，GDS选择以公开发布官方指南的方式来回应NHS的决定，在英国政府内部的语境中，这已经是一种非常强烈的信号——近乎公开批评。

开源代码安全与AI威胁的深层矛盾

这场争论的核心触及了当下技术治理中的一个关键问题：当AI工具能够大规模扫描和利用公开代码中的漏洞时，公共部门应该如何平衡开放透明与安全风险？

Project Glasswing项目揭示了一个不容忽视的现实——大语言模型（LLM）和生成式AI确实可以被用来发现和利用开源代码中的安全缺陷。这是一个真实存在的威胁，NHS对此感到担忧并非毫无道理。

但GDS的立场代表了另一种更成熟的思路，其理论基础是开源安全领域著名的"林纳斯定律"（Linus's Law），由开源倡导者Eric S. Raymond在其经典著作《大教堂与集市》中提出："只要有足够多的眼睛，所有的bug都是浅显的"（Given enough eyeballs, all bugs are shallow）。这一原则认为，代码的公开透明使得全球开发者社区都可以参与审查，从而更快地发现和修复安全漏洞。历史上，Linux内核、OpenSSL等关键开源项目的安全性正是通过这种大规模社区审查来保障的。

当然，这一原则也并非没有争议——2014年的Heartbleed漏洞就是一个警示案例。Heartbleed是OpenSSL加密库中一个存在了两年多的严重漏洞，影响了全球约17%的安全Web服务器，它表明即使是被广泛使用的开源代码，关键漏洞也可能长期未被发现。这凸显了仅靠"多眼审查"是不够的，还需要系统化的安全审计流程。

开源代码的公开性本身就是一种安全机制。更多的审查者意味着更高的安全性，关闭代码仓库不仅不能从根本上解决问题（攻击者可能已经获取了代码副本），反而会失去社区审查带来的安全收益，同时增加维护成本、降低代码复用效率。

对全球公共部门开源安全策略的启示

这一事件为全球公共部门的开源策略提供了重要的参考案例：

1. 恐慌式反应往往适得其反。 面对AI带来的新型安全威胁，一刀切地关闭开放渠道看似果断，实则可能制造更多问题。

2. AI时代的代码安全策略需要更精细化。 与其关闭所有仓库，不如建立更完善的漏洞响应机制、代码审查流程和敏感信息检测工具。目前已有多种成熟的技术工具可供公共部门采用：GitHub的Secret Scanning功能可以自动检测代码仓库中意外提交的API密钥、密码等敏感信息；Dependabot等工具可以自动监控项目依赖库中的已知漏洞并提示更新；SAST（静态应用安全测试）和DAST（动态应用安全测试）工具可以在代码部署前自动进行安全扫描。此外，许多组织还采用"安全左移"（Shift Left Security）策略，将安全检查嵌入到开发流程的早期阶段，而非在代码发布后才进行审查。这些工具和方法论使得"保持开放的同时管理风险"成为切实可行的策略。

3. 开放与安全并非零和博弈。 GDS的指南明确指出，可以在保持默认开放的同时，对确实存在风险的特定组件进行有针对性的限制。

4. 政策制定需要充分的技术理解。 NHS的决定暴露出决策层可能对开源生态的运作方式和安全机制缺乏足够深入的理解。

这场英国政府内部的公开分歧，本质上反映了整个公共部门在AI时代面临的治理挑战。如何在拥抱开放创新的同时有效管理新兴安全风险，将是未来几年各国政府必须回答的核心问题。