COPU 会议纪要｜2026.10.27

10月27日，陆主席主持召开COPU例会。

 一、态势：漏洞“洪水”进入结构性过载

AI驱动发现正在改变漏洞披露与跟踪的基本面。2020至2025年NVD收录CVE增长263%，2025年达48,185个；2026年第一季度提交量同比再增约三分之一。跟踪基础设施的“处理带宽”先于“发现带宽”见底：NVD富化覆盖率2025年一度降至28%，低于2024年的46.2%。核心矛盾已不是“AI能否发现漏洞”，而是发现之后的验证、富化、披露、修补同时成为瓶颈。Anthropic在Project Glasswing更新中明确：软件安全进展“不再受限于发现速度，而受限于生态系统多快能验证、披露和修补它们”。

二、CVE/NVD治理：从“数量增长”转向“风险质量”

NIST/NVD转向风险分诊。2026年4月15日，NIST放弃对每条CVE全面富化，仅优先处理CISA KEV目录漏洞、联邦政府使用软件及关键软件相关CVE，其余标注“Not Scheduled”。预计仅覆盖15%至20%的CVE，80%至85%的新条目将成为未经富化的“空壳记录”。NVD正从“全量权威评分源”变为“高风险子集优先队列”，覆盖缺口需由其他信号源填补。

CISA推进“质量时代”。2025年9月CISA宣布CVE项目从强调覆盖数量的“增长时代”切换至强调富化标准与信号保真度的“质量时代”，2026年9月进一步发布质量时代框架白皮书。其实质是承认：发现量推高后，CVE体系的核心价值不在于收录更多编号，而在于提供可信、可比、可用于决策的质量信号。

三、开源披露窗口：从90天惯例向30天、14天收缩

AI改变了“负责任披露”的时间逻辑。共识正在形成：能被AI发现的漏洞很可能已等同于公开信息，过长保密期的边际安全收益不足以抵消并行发现和提前泄露风险。GNOME将默认披露期限从90天缩短至30天（2026年8月1日后报告），CPANSec将默认禁运期从28天缩减至14天，Linux内核对疑似AI生成报告采用立即披露。保密窗口的主要功能正从“保护防御者”转向“管理维护者修补节奏”，而非真正的信息屏障。 

四、前沿实验室案例：发现能力已跨过“辅助工具”阶段

Anthropic / Claude：攻击面削减与Project Glasswing。Claude对25个开源项目、超500万行代码分析发现近500个安全问题，包括潜伏21年的漏洞和认证前可达敏感路径。Anthropic据此提出：逐一找漏洞不可持续，防御者应转向攻击面削减，一次性降低未知漏洞整体风险。Project Glasswing约50家防御方合作伙伴六周内识别超10,000个关键或高危漏洞；对1,000多个开源项目扫描产生23,019个候选发现，复核1,900个中真阳性率90.8%，已披露1,596个，覆盖281个项目。wolfSSL单库产出10个CVE，含可致证书伪造的CVE-2026-5194（CVSS 9.3），部分漏洞需推理密码学规范而非崩溃/模糊测试信号才能识别。

OpenAI：从零日发现到自主利用链。2025年5月o3模型在无模糊测试、无运行时插桩、无人工指向下，静态分析约12,000行代码，自主发现Linux内核ksmbd SMB服务器远程可利用零日CVE-2025-37899。2026年9月OpenAI宣布Astra达到Preparedness Framework“Critical”网络安全阈值：ExploitBench得分100%，在与训练数据无重叠的V8漏洞基准上发现并串联两个未知零日，构建可工作利用链，并展示非特权用户到root提权链及浏览器沙箱逃逸链。对开源治理而言，“发现即利用”窗口正在收窄，补丁延迟代价上升。

由陆主席谈漏洞洪水和开放权重两个概念。

漏洞洪水和开放权重
陆首群 2026.10.27

漏洞洪水

传统操作系统和数据库（不管是开源或闭源）在进行AI改造（如加入AI模块），或发展为AIOS时，以及作为全新的安全分析工具被广泛应用于开源或闭源的操作系统时（甚至冲击到Linux操作系统或内核时，欧拉操作系统等），由AI驱动击破OS系统发生大量漏洞（其数量与速度呈爆发式增长），称为漏洞洪水。由AI驱动引发的漏洞洪水故障的报导，可参阅《COPU会议纪要（2026.10.13）》安泱的报告，并举银河麒麟服务器 OS（开源CVE根治工作，每月升级1次，有点滞后）及红帽RHEL 9.8（其内核每周升级1-2次）的治理情况。由如上袁怿氛围编程（Vibe Coding）驱动的漏洞洪水故障，在本纪要上发表，如何治理漏洞洪水引起了国内外广泛重视。

漏洞洪水将冲击Linux内核及操作系统、安卓系统、iOS、阿里云龙蜥（Anolis OS）、华为欧拉（openEuler）、麒麟OS等，并很可能波及鸿蒙系统。相关各方须及时、持续出台根治此类恶性故障的措施。

开放权重

开放权重是在（大）模型情况下表示开源的概念，本次会议将发表陈越整理的《国内主流开放权重模型商用许可对比》的文章（表格），在传统情况下，开源一般是表现代码的。

国内主流开放权重模型许可与商业模式对比分析

陈越 2026.10.27

总结了一份关于中国七家主流大模型开放权重（Open Weights）商用许可协议对比表。展示了各家模型在商业化使用、第三方托管/MaaS（模型即服务）、商业门槛、超额后的处理方式以及其他重要合规要求上的差异。

一、 国内主流开放权重模型许可与商业模式对比

表格从七个维度对比了七款模型：Kimi K3、Qwen3.8-Max （通义千问）、DeepSeek V4 Pro、MiniMax M3、Hy4 preview （混元）、GLM-5.3 （智谱）、Step 3.7 Flash （阶跃星辰）。 

二、 商业模式特点补充分析

表中，我们提炼出中国大模型厂商在“开放权重”策略上的三种不同商业模式逻辑：

1. “无保留开源”生态派 （DeepSeek, 腾讯混元, 阶跃星辰）

代表模型： DeepSeek V4 Pro （MIT）, Hy4 preview （Apache 2.0）, Step 3.7 Flash （Apache 2.0）。

商业模式特点：

• 以生态换市场： 它们采用国际标准的宽松开源协议（MIT/Apache 2.0），没有任何商业营收门槛。这种模式的核心目的是最大化模型的普及率和开发者生态。

• 盈利后置： 它们不靠模型权重的授权费赚钱，而是通过提供官方的API服务、企业级私有化部署、云端算力消耗、或者基于该模型构建的上层应用来变现。

• 技术与品牌曝光： 像DeepSeek这样完全无门槛的开放，能迅速占领开发者心智，可能成为事实上的行业标准，从而在后续的B端/G端采购中占据绝对优势。 

2. “防巨头薅羊毛”的保护性开放派 （Kimi, Qwen, MiniMax）

代表模型： Kimi K3, Qwen3.8-Max, MiniMax M3。

商业模式特点：

• 对大型云厂商/MaaS平台有商业要求： 这三家的协议都有一个共同点——针对“第三方托管/MaaS”设置了一定的营收门槛（2000万至5000万美元）。这是为了防止阿里云、腾讯云、AWS、Azure、Google Cloud等大型云厂商直接免费拿它们的开源权重模型去卖API，从而侵蚀它们自己的官方API收入。超过规定的门槛就要原模型厂商进行授权或商业合作。

• “模型版税”：这部分国内开放权重模型正在探索一种全新的商业模式。通过与海内外企业和托管服务商签署分成协议，协助这些厂商部署自己的模型推理服务。典型案例：月之暗面已与美国十几家中型推理服务商签订分成协议（最高分成30%），并正在与AWS、Azure和Google Cloud谈判类似模式。阿里同样在考虑对大型Qwen商业用户采用收入分成机制，而新的Qwen许可证已经开始对大型MaaS和AI Work Assistant业务设置单独商业授权门槛。这意味着未来模型公司的收费对象可能不止AWS或者Together这样的云平台，也可能包括大量建立在开放模型之上的Coding工具、办公Agent和其他AI应用。最终我们可能看到这样的商业模式：模型开发商负责开发训练模型、维护模型品牌和与推理平台进行技术适配，推理平台负责购买算力、部署模型和寻找客户，最后再按照协议与模型厂商分享商业收入。关键在于对于模型厂商来说，这是一种轻资产运营。

• 兼顾生态活跃度与商业回报： 对于初创公司、中小企业、个人开发者，只要营收没达到门槛，完全可以免费商用。这保证了生态的繁荣。当用户业务达到一定规模、具备付费能力后，通过单独商业授权、合作分成的方式实现变现。

• 强制品牌展示： 要求显著展示模型名称（如 "Built with MiniMax M3"），利用下游开发者的成功来反哺自身的品牌知名度。

3. “安全合规优先”的审慎派 （智谱 GLM）

代表模型： GLM-5.3。

商业模式特点：

• 极高的营收门槛 （100亿美元）： 这个门槛实际上意味着99.9%的企业都碰不到。这说明智谱目前对商业化的限制非常宽松。

• 核心诉求是“安全”而非“钱”： 它的超额条件不是“交钱”，而是“通过Z.AI安全审查”。这反映了智谱作为具有清华背景、深耕政企市场的厂商，其首要考量是内容安全、数据合规和意识形态风险。他们不希望自己的模型被用于不可控的、可能引发重大社会风险的超大规模商业场景中。

三、 开放权重使用的许可协议限制总结

综合来看，这些“开放权重”协议（注意：除了MIT和Apache 2.0，其他多为厂商自定义的“源码可用/Source Available”协议，并非严格意义上的OSI认证开源）主要存在以下几类限制：

1. 商业规模限制 （Revenue/MAU Thresholds）

这是中国厂商自定义协议中最常见的限制。例如：Kimi K3的许可协议前半部分采用MIT协议内容，后半部分采用自定义条款，在一定条件下规范商业合作。

• 营收限制： Kimi （2000万美元）, Qwen （5000万美元）, MiniMax （2000万美元）, GLM （100亿美元）。一旦触及，必须重新获取授权。

• 用户量限制： Kimi和Qwen都提到了“1亿MAU（月活）”的限制。即使你不赚钱，但如果你的产品用户量极大，也会触发额外的合规或授权要求。

2. 使用场景限制 （Use Case Restrictions）

• 特定领域触发： Qwen特别指出了“AI Work Assistant（包括AI编程与办公生产力产品）”也算在5000万美元的门槛内。这意味着如果你用Qwen做一个类似Cursor或Copilot的产品，可能就会触发商业授权。

• MaaS/托管限制： 几乎所有自定义协议都对“将模型作为服务提供给第三方”（MaaS）高度敏感，因为这直接与模型原厂的API业务竞争。

3. 署名与品牌展示义务 （Attribution Requirements）

• 强制露出： MiniMax要求“任何商用均须显著展示”；Kimi和Qwen要求在达到一定规模后“显著展示模型名称”。

• 标准开源要求： MIT和Apache 2.0虽然不强制商业露出，但要求在代码副本、分发物中保留原始的版权声明和许可证文本（NOTICE文件）。

4. 程序性合规要求 （Procedural Compliance）

• 事前通知： MiniMax要求即使没达到门槛，也必须“发送一次性商用通知”。这是一种收集用户数据、建立联系的手段。

• 安全审查： GLM要求超大型企业在使用前必须通过安全审查。

• 另签协议： Kimi、Qwen、MiniMax在触发门槛后，都要求“另签协议”或“获得书面授权”，这意味着后续的使用条件（可能是付费、可能是排他性条款）将由双方重新谈判决定，充满了不确定性。

5. 豁免条款 （Exemptions）

• 内部使用豁免： Kimi明确指出“内部使用”可豁免相关条款。这意味着如果你只是在公司内部用Kimi K3做个客服机器人，不对外售卖API，通常不受2000万美元门槛的限制。

• 官方生态豁免： Kimi提到“通过官方产品或认证推理伙伴使用”可豁免。这是厂商在引导开发者使用其官方云服务或指定的合作伙伴云服务。

四、建议

对于开发者或企业而言，在选择这些开放权重模型时：

1. 如果是个人项目、初创公司或内部工具： 这七家基本都可以放心免费使用。 

2. 如果要做To B的MaaS平台或SaaS产品： 建议首选 DeepSeek、混元（Hy4）、阶跃（Step） 的 Apache/MIT 协议模型，避免未来业务做大后面临高昂的授权谈判成本。

3. 如果使用 Kimi/Qwen/MiniMax： 必须密切关注自身的营收和MAU数据，并在产品UI中做好模型署名的准备，同时留意官方的“商用通知”流程。

本次会议对中国开源软件推进联盟（COPU）理事会换届改造筹备工作进行了讨论和部署。

中国开源软件推进联盟（COPU）理事会改选筹备组

组长：刘澎

副组长：谭中意、宋可为、陈伟、孟迎霞、安泱

成员：张侃、袁怿、鞠东颖、何苗、陈越

第一期初步分工：

谭中意、陈伟负责核定本单位对副主席推荐

宋可为、孟迎霞、袁怿负责核定本单位对常务理事推荐

安泱、张侃、陈越、鞠东颖、何苗负责核定理事单位

所有参会人员：陆首群、孟迎霞、安泱、张侃、袁怿、陈越、何苗、陈伟（线上）、鞠东颖（线上）、陈道清（线上）、靳虹博（线上）、韩宪平（线上）、胡宇（线上）