NHS关仓库之后，GDS把底线说清了：默认开放，不是默认遮住

NHS 最近收回了部分原本开放的代码仓库访问，背景是 Project Glasswing 向其报告了漏洞。

这件事容易被讲歪。它不是已经证实发生了大规模攻击，也不是 NHS 全面退出开源。更准确地说，这是一个公共部门在安全压力下，把一部分代码从开放状态往回收。

随后，英国 Government Digital Service 发布了一份指南，谈公共部门里的 AI、开放代码和漏洞风险。GDS 没有点名 NHS，但那句核心建议很硬：Keep open by default.

默认开放。谨慎关闭。

NHS收缩，GDS定调

GDS 的完整意思是：把所有东西都设为私有，会增加交付和政策成本，也会减少复用与审查。开放应保持为默认姿态，关闭要少用，而且要有意为之。

这不是“开源天然安全”的口号。GDS 没这么幼稚。

它说的是治理顺序：公共部门代码默认接受复用、审查和政策一致性的约束。真要关，可以。但要讲清楚关什么、为什么关、关多久，以及关掉之后新增了什么成本。

Terence Eden 的解读是，这在英国公务员语境里已经算公开升级。他用了一个很英国的说法：被邀请去一场“没有饼干的会议”。

意思不是翻脸，而是气氛很冷。

我更愿意把它看成一次边界提醒：公共部门不能把“为了安全”四个字当万能通行证。尤其当关闭动作本身会削弱审查、复用和透明度时。

关仓库不是安全治理

把代码藏起来，短期很有诱惑力。

漏洞被报告，组织承压，最容易按下的按钮就是 private。按钮一按，外面看不见了，讨论少了，尴尬也少了。

但安静不是安全。

开放代码的收益很现实：其他政府团队能复用，安全研究者能审查，公众能看到公共预算产出了什么，政策团队也更容易确认技术路线没有各走各路。

关闭的成本也很现实：交付成本上升，重复建设增加，透明度下降，善意发现漏洞的路径变窄。更麻烦的是，责任可能一起被关进黑箱。外面看不见，里面也未必更快修。

“讳疾忌医”，病不会因为遮住病历就消失。这个类比不完全一样，代码仓库当然不是病历；但相似的是组织本能：先遮住难看的东西，再把遮住误认为处理。

公共技术治理的分水岭就在这里。

成熟团队会把漏洞当作修复机制的一部分。不成熟团队会把漏洞当作公关事故。

NHS 的处境可以理解。医疗系统承载高敏感数据，任何安全问题都可能变成政治问题。这里的现实约束很硬，不能拿普通互联网项目那套话术直接套。

但越是这种系统，越要分清两件事：保护安全，还是避免难堪。

前者保护公众利益。后者保护组织脸面。它们有时同向，有时并不。

受影响的人，该看什么

这件事最该看的，不是普通用户会不会立刻感到变化。短期内，大多数患者和服务使用者未必有直接体感。

真正受影响的是两类人。

接下来最该观察三个变量。

第一，NHS 是否说明关闭范围和恢复条件。只说“为了安全”不够。范围、期限、替代审查机制，才是治理语言。

第二，GDS 的指南会不会进入实际流程。比如公共部门项目在关闭代码前，是否需要记录理由，是否需要定期复核，是否需要保留安全研究者的报告入口。

第三，漏洞披露会不会被惩罚性对待。如果报告漏洞的后果是仓库关闭、研究者被冷处理，那以后发现问题的人会更少。风险不会消失，只会转入更暗的地方。

我不太买账的，正是这种组织反射：一有外部审查，就先收口；一有公开漏洞，就先控场。

公共部门不是普通公司。它使用公共预算，服务公共需求，也更需要公共信任。开源在这里不是情怀，而是一种治理工具。

当然，开放代码不等于所有东西都裸奔。密钥、个人数据、敏感配置，本来就不该进公开仓库。真正的安全团队也不会靠“全公开”解决一切。

GDS 这次少见地把话说到了点上：默认开放，不代表无条件开放；谨慎关闭，也不代表不能关闭。

关键是论证责任在关闭一方。

如果一个公共系统只能在没人看见时才显得安全，那它的问题就不在可见性，而在治理能力。技术系统从来不是只靠门锁安全。还要靠有人看、有人问、有人能指出锁坏了。