英国政府报告：开放源代码与开放式 AI 的网络安全治理仍存在明显空白
英国政府委托的文献研究指出，现有网络安全治理框架难以覆盖开放源代码软件与开放式 AI 在训练数据、模型权重、微调流程和推理工具链带来的新风险；报告建议推进可操作定义、AI BoM 与平台合作，但并未提出即时强制监管。研究基于学术与灰色文献综述，并对 Hugging Face 与 GitHub 样本进行抽样分析，发现安全文档与可验证来源在样本中普遍缺失。
英国政府委托的文献研究指出，现有网络安全治理框架难以覆盖开放源代码软件与开放式 AI 在训练数据、模型权重、微调流程和推理工具链带来的新风险；报告建议推进可操作定义、AI BoM 与平台合作，但并未提出即时强制监管。研究基于学术与灰色文献综述，并对 Hugging Face 与 GitHub 样本进行抽样分析，发现安全文档与可验证来源在样本中普遍缺失。
英国政府委托开展的一项文献研究指出，围绕开放源代码软件与开放式人工智能的网络安全治理，现有框架存在明显断层。报告认为，传统软件供应链安全所使用的工具，尚不足以覆盖训练数据、模型权重、微调流程和推理工具链带来的新风险；但报告同时强调，这是一份研究与治理建议，并非新法规，也没有立即生效的强制合规要求。
这份题为《开放源代码软件与 AI 网络安全文献研究》的报告于 2026 年 9 月 7 日在英国政府网站发布。研究由英国政府相关部门委托完成，覆盖开放源代码软件（OSS）与开放源代码 AI（OSAI）的定义、风险、治理框架和供应链问题。
报告的核心判断是：AI 系统的“开放”仍缺乏统一定义，而定义不清会直接导致安全责任边界模糊。
研究显示：有关开放式 AI 上游治理的证据仍然稀少
研究团队按照系统性文献综述方法，在 8 个数据库中筛选了 14,561 条学术记录，最后确定 43 项高度相关研究；灰色文献部分则从国家网络安全机构、标准组织、国际机构、行业协会及生态参与者处收集了 172 条记录。研究还对 Hugging Face 模型和 GitHub 上的 AI 项目进行了平台层面的抽样分析。
报告说，学术研究对于入侵检测、对抗鲁棒性等“下游”问题积累了较多成果，但对于模型发布前的上游环节——模型如何训练、使用了哪些数据、权重如何分发，以及应当配套哪些文档——研究相对不足。
在报告考察的约 1 万个 Hugging Face 下载量最高的模型中，只有 15 个带有与安全相关的文档，不到 0.2%。在约 2,000 个 AI 相关 GitHub 仓库中，约 131 个包含实质性的安全内容，比例约为 6%。
这些数字是报告研究样本的结果，并不构成对整个 Hugging Face 或 GitHub 生态的全面普查。它们更准确地说明，在研究团队抽取的样本中，安全文档与可供使用者核验的安全信息并不常见。
“开源”不一定意味着训练过程透明
报告援引 2024 年发布的《开放源代码 AI 定义 1.0》（OSAID）称，真正开放的 AI 系统不应只公开模型权重，还应提供与训练数据、源代码和模型参数有关的信息。换言之，开放性应覆盖完整的 AI 工件链，而不是停留在“可以下载权重”这一层面。
报告将当前关于开放式 AI 的定义大致分为三种路径：以代码可访问性为中心的软件视角，以模型参数公开为中心的开放权重视角，以及把数据、训练流程和工具链都纳入考察范围的供应链视角。
研究称，Llama 2、Grok、Phi-2 和 Mixtral 等被广泛称为“开源”的系统，并不完全符合 OSAID 的要求，因为它们在训练数据、代码或使用权利等方面存在不同程度的限制。报告列举的较完整开放案例包括 Pythia、OLMo、Amber、CrystalCoder 和 T5，并指出，这些系统的共同点更多在于研究机构或非营利组织公开了完整来源，而不在于模型规模。
这一差异也被报告称为“开放洗白”问题：一个系统可能在市场传播中被称为开源，但外部使用者无法完整了解其数据来源、训练过程或修改权利。在不同监管框架对“开源”给予不同待遇的情况下，定义不清可能进一步影响责任划分和合规判断。
近期发布的 K2 Horizon 全开放模型 也显示，判断一个模型是否“全开放”，不能只看发布声明，还需要逐项核对权重、训练代码、数据或数据构建方法、中间检查点和许可证是否真正可获得。
传统软件供应链工具难以覆盖模型风险
对于传统 OSS，报告认为依赖混淆、恶意软件包注入和维护者停止维护等供应链风险已有较成熟的应对工具，包括软件物料清单（SBOM）、依赖扫描、安全开发流程和漏洞披露机制。
但 AI 系统增加了新的风险类别，包括数据集投毒、模型权重篡改、不安全微调，以及缺少来源记录。这些问题无法通过传统代码审查完全识别。一个模型即使源代码可见，也可能因为训练数据被污染、微调过程不可追踪，或下载的权重与发布者声明不一致而产生安全问题。
报告因此建议在 SBOM 的基础上推进 AI Bill of Materials，即 AI BoM。它应记录训练数据来源、模型谱系、微调历史和已知漏洞，并帮助使用者区分三类不同对象：完整开放的 AI 系统、只开放权重的模型，以及只开放部分配置的系统。
这一思路的现实背景，是 AI 系统越来越多地通过模型仓库、统一模型网关和工具接口进入生产环境。AIFlux此前报道的 LiteLLM 身份验证漏洞被列入 CISA 已知被利用漏洞目录 说明，安全边界不仅存在于模型本身，也存在于模型网关、MCP 工具和外部服务之间的认证链路中。
报告建议先建立标准，而不是立即扩大强制监管
报告提出四项优先建议：首先，为 OSS 和 OSAI 建立可操作的工作定义；其次，推动来源记录和文档标准，扩展 SBOM 并发展 AI BoM；第三，与 Hugging Face、GitHub 等主要分发平台合作，改善文档、贡献者验证和模型完整性检查；第四，参与 ISO/IEC JTC 1/SC 42 及 ETSI 等国际标准组织的相关工作。
不过，报告对新兴风险的表述相当谨慎。它认为 Agentic AI 等长期运行、能够调用工具的系统值得持续监测，但目前的证据还不足以支持具体的强制治理干预。报告也没有宣布任何立即生效的新义务。
这一区分很重要。研究报告提出的是风险识别、标准建设和后续政策讨论的基础，不等于英国政府已经要求所有模型开发者或使用者提交 AI BoM，也不等于所有被称为开放式 AI 的系统都已被认定为不安全。
报告也延续了英国此前针对 AI 网络安全的政策路径。英国政府在 2025 年发布的 AI 网络安全实践守则 采用自愿性守则方式，重点关注安全设计、数据投毒、提示注入和生命周期管理等问题；此次新研究则把关注点进一步推向开放模型的来源、发布和供应链。
真正的难题在于“可验证的开放”
从研究结论看，开放式 AI 面临的主要问题并不是是否应当开放，而是开放到什么程度，以及外部使用者能否验证这种开放。
公开权重可以让开发者在本地运行模型，但不一定能回答训练数据来自哪里；公开代码可以帮助研究人员检查实现，但不一定能证明发布的权重没有被替换；公开训练方法可以提高透明度，但如果缺少中间检查点、许可证说明或完整的来源链条，第三方仍可能无法复现实验结果。
因此，AI BoM 的价值可能不只在于记录一份“组件清单”，还在于把模型从训练、微调、发布到部署的变化过程连接起来。对监管行业和关键基础设施使用者而言，这种记录将影响他们是否能够评估一个模型的来源、已知弱点和适用范围。
目前可以确认的是，英国政府已经发布这份文献研究，并将开放式 AI 的定义、文档和供应链安全列为需要补足的治理领域。尚不能确认的是，报告中的建议何时会转化为新的标准、采购要求或监管措施，也不能据此推断英国将立即对开放模型实施强制合规。
后续值得关注的，是英国政府是否会就 OSAID、AI BoM 或平台责任展开正式咨询，以及 Hugging Face、GitHub 和模型开发者是否会主动提高安全文档和来源记录的覆盖率。
来源：
不错过任何一条 AI 大事
订阅 AIFlux 早报，每天 3 分钟看懂产业动态。
