加载失败
这篇公开信要求 NHS England（英格兰国民医疗服务体系主管机构）不要因为所谓的 AI 安全威胁而把公开的代码仓库关掉。评论里提到的 Mythos 被当作一种 AI security scanner/攻击工具的威胁来源，但有人指出英国国家网络安全中心 NCSC（英国国家网络安全中心）和 AI Safety Institute（英国 AI 安全研究机构）并没有建议这种全面封闭的做法。争论的核心是：NHS 作为公共机构，长期依赖 GitHub 上的公开代码、网页和协作审计，闭源可能既挡不住真正的攻击，也会削弱透明度和公共问责。讨论进一步延伸到开源安全、AppSec（应用安全）响应速度，以及医院这类高风险机构该如何在开放协作和保密防护之间取舍。
评论者认为，因所谓 AI security scanners 就把 NHS 的源码全部关掉，是典型的过度反应。即使真的存在风险，代码也早已被抓取过，事后封存只能做姿态，挡不住已经拿到副本的攻击者。更现实的是，闭源并不能阻止对二进制和网站的分析，反而会牺牲 NHS 大量依赖 GitHub 链接带来的透明度。有人还把这看作公共部门在“怕被追责”的心理下，把公域利益让位给最小化责任的选择。
另一种看法承认，完全开放并不总是最优解，尤其是医院这类高风险环境。有人指出，如果代码在关闭后继续演进，外部攻击者和 LLM 只能看到旧版本，而机构可以在内部用 LLM 先做漏洞发现与修补，从而领先一步。评论里还引用 Copy.fail 的披露争议，认为 LLM 辅助发现漏洞后直接公开，可能把社区推入混乱和恐慌。这个观点主张的不是全面闭源，而是根据威胁模型在开放与保密之间找平衡。
不少评论把问题扩展到整个 OSS 生态：CISO、CTO 和维护者开始暂停贡献或使用开源组件，直到 AppSec 团队能在一天内完成验证和修复。过去 8–10 天的响应窗口在 AI 时代被认为太慢，这被描述成典型的“公地悲剧”——项目依赖社区善意，但维护安全的成本却没有被支付。有人因此建议走 open core、正式赞助或更严格的许可证，让项目方能商业化并为贡献者付费。也有人担心组织会把核心依赖都 fork 到内网，结果只是把更多代码和漏洞管理负担留给自己。
还有评论很务实地指出，就算 NHS England 同意保留开源，也会先花很久写指南，再花更久让现有技术团队落实。这里隐含的前提是，英国公共部门的采购、合规和变更流程都很慢，几乎任何政策都要经过层层审批。于是开放源码这件事虽然听起来简单，真正落地可能会被官僚流程拖成长期工程。
一条旁支评论把注意力从源码开放转向 NHS 数字服务的预算分配，顺手推荐了反对 accessibility overlays 的请愿。其核心是，这类覆盖层往往花钱却损害残障用户体验，钱本应用在改进底层服务，而不是做表面合规。这个分支把讨论从“该不该开源”扩大到“NHS 数字化到底把资源花在哪儿才算正确”。
OSS: open source software，开源软件；指源码公开、可自由审查和复用的软件生态。
LLM: large language model，大语言模型；这里主要指可用于代码分析、漏洞发现和辅助审计的 AI 模型。
AppSec: application security，应用安全；负责发现、验证和修补软件漏洞的安全实践或团队。