「开源之道」 2026-10-25 搜集事件和材料

「开源之道」昨日阅读 · 2026-10-24

今日主线可以压成一句：上游没有塌，塌的是把「已修复」翻译成「已通知」的那一层——而这一层无人认领、无价可标、无从审计。

📄 最新开源研究论文

1. 披露跑赢了通报：2026 年漏洞激增，维护者修得动，下游接不住

  • 作者：Raúl Rodríguez、Hemachandra Kannan、Pavana Kiranmai Chepuri（Woxsen School of Business）
  • 来源：SSRN Electronic Journal 预印本，2026-10-18
  • 链接：doi.org/10.2139/ssrn.7629481

摘要：研究 AI 辅助发现漏洞的时代里，「从发现到保护」这条转换链是否还能跑通。数据是 2017 至 2026 年 10 月全部 35,263 条 GitHub 已审核 advisory，并把 npm 与 PyPI 的记录与修复版本的发布日期做了链接。三个核心发现：① 2026 年 3-9 月均审核 1,306 条 advisory，是 2023-2025 年均值的 4.5 倍；② 84% 由维护者自己发布，且修复没有塌——90% 的 npm/PyPI advisory 在发布时已有修复版本，这个比例在各类型内部无变化；③ 卡点整体下移：来自 NVD 的 advisory 中位审核时间从 12 小时涨到 11 天，而「修复已发布」到「触发自动告警的 advisory 发布」之间的中位滞后从 3 天涨到 43 天（截至 8 月）。休眠包（dormant packages）的 advisory 几乎从不带修复；负载分散到两倍以上的包上，AI 应用软件贡献了增量的 18%。政策结论：应当把 advisory 的整理（curation）当作关键基础设施，并「按通报能力（notification capacity）来调控披露节奏」。

为什么与开源之道相关：它把「开源安全危机」这个笼统说法拆成了一个可测量的链条，并给出了一个反直觉的结论——上游没坏，坏在下游的翻译层。维护者修得更快、发布得更早，是变好的；NVD 审核从 12 小时到 11 天、告警滞后从 3 天到 43 天，是变差的。二者的差，就是制度性的：修复是私人的（有产权、有激励、有人认领），通报是公共的（无主、靠拨款、靠流程）。这正是奥斯特罗姆最关心的问题形态——不是公地被用光了，是公地的记录没人维护。

开源之道视角点评：「按通报能力来调控披露节奏」这句话分量很重，也最容易被误读。它不是要求研究者少报，而是承认披露是一个制度设计问题，不是道德问题：当发现能力被 AI 提升了 4.5 倍，而整理能力仍按人力预算走，多出来的那些发现不会变成保护，只会变成噪声、误报和告警疲劳，最后连真的也被忽略。用威廉姆森的分层看，这是 L2（标准与法规，NVD/CVE/SBOM 的定义权）与 L3（谁来整理、谁付钱）之间脱节。企业买 SCA 工具买的是 L4（查询接口），却以为买到了 L2（可信判准）。而「休眠包的 advisory 几乎从无修复」这一条，是整篇最冷的观察：公地悲剧在开源里的具体形态不是争夺，是没人到场。

2. 在高低不平的地上执法：开源漏洞数据撑不起 SBOM 与 CRA 的合规承诺

摘要：欧盟《网络韧性法案》（CRA）与美国第 14028 号行政令 / SBOM 最小要素，要求软件生产者「知道自己产品里有哪些开源组件、并管理其中的已知漏洞」。实践中这些义务靠自动化工具完成——把组件清单比对公开漏洞库。论文检验了这个隐含假设：漏洞库对不同编程语言生态提供的信息是可比的吗？ 方法是 OSV 数据库全量普查，8 个主要包生态、291,895 条记录。三个「不平」：① 81.5% 的记录已不是漏洞而是恶意包，恶意包报告从 2022 年的 7,445 条涨到 2025 年的 192,714 条，而现行 SBOM 与漏洞处理框架是按「意外缺陷」设计的，不是按「攻击」设计的；② 可执行性随生态而异——点名了修复版本的记录占比从 75.2% 到 95.5%；③ 可识别性随生态而异——关联到 CVE 编号（多数合规流程的引用键）的占比从 58.7% 到 98.6%，带严重性信息的从 51.0% 到 100%。结论很尖锐：付出同等合规努力的两家机构，仅因技术选型不同，得到的安全结果可以差很多。文末提出四项政策建议，试图把合规放到更平的地上。

为什么与开源之道相关：这篇论文真正测量的不是漏洞，是制度的基础设施质量。CRA 和 EO 14028 都是「输出端监管」——规定你必须知道什么、必须报告什么，却默认输入端（数据）是均质的。一旦输入端不均质，监管就从「降低风险」变成了「重新分配风险」：大厂有能力跨生态核查、有法务解释差异，小厂只能照单全收，最后谁的组件选得「合规友好」，谁就更容易过关。这是阿西莫格鲁意义上从包容性滑向汲取性的典型路径——规则表面普适，实际上把成本转移给了信息能力更弱的一方。

开源之道视角点评：把这篇与上面那篇一起读，会看到一个共同的病：大家在同一套词上说不同的事。「漏洞数据」在监管者的文件里是一个统一的库，在 OSV 里是 291,895 条性质各异的记录，其中八成讲的根本不是同一个问题。这正是斯科特「极端现代主义」的当代版：为了让复杂现实可以被统计和监管，先把它简化成一张表，然后对这张表执法。而开源之道的立场应该是清楚的：不要反对 SBOM，要反对把 SBOM 当成绩效指标。清单只是索引，索引的质量决定了监管是知识还是仪式。这篇论文给了最有力的证据形态——不是「我认为标准不好」，而是「我普查了全部 291,895 条，给你看它不均匀到什么程度」。

📰 开源动态摘要

1. LF Research：生成式 AI 把编码时间砍掉一半，同时让 25% 的入站 PR 变成「AI 垃圾」

  • 来源：Linux Foundation Research（2026-10-20，All Things Open 2026，Raleigh）/ The Register、Phoronix、HPCwire 等多家转述
  • 链接：报告 ・新闻稿

摘要：由 Red Hat 赞助、Futurewei/OpenSSF/LF AI & Data 支持。几条关键数字：59% 的维护者报告 GenAI 出现后贡献量上升（大型项目 69%）；25% 的入站 PR 被估计为低质量「AI slop」（大型项目 31%）；生产力提升最高 50%——分任务看，代码撰写 52%、提案讨论 19%，但高复杂度任务上有 21% 的人反而更慢；71% 维护者认同 GenAI 降低了参与门槛，但 53% 不认为 GenAI 改善了社区信任；只有 35% 的项目有正式的 GenAI 使用政策，32% 既无政策也无计划；贡献者一侧 61% 会对 AI 生成代码做详细审查与功能测试，但 AI 辅助的披露仍不一致；46% 的维护者认为 GenAI 增加了对新贡献者 mentorship 的需求（认为减少的 32%）。研究主管 Hilary Carter 的原话是可以直接引的：「开源项目需要为不断增长的 AI 生成贡献者群体做设计，而不是仅仅对其做出反应。」

开源之道点评：这份报告最有价值的地方不是 25% 这个数字——那是受访者估计，不是测量——而是它自己暴露了制度真空的位置：三分之二的项目对 GenAI 没有政策，或连计划都没有。也就是说，冲击已经持续了足够久，而正式规则的供给仍然是零。这不是疏忽，是集体行动困境：任何单一项目先立规矩，就要在短期「劝退」贡献者，收益却摊薄到整个公地。Carter 说的「design for」是对的，但设计不出比「人必须对每一行负责」更强的规则——这与本周 Linux 内核废掉 Assisted-by 标签的逻辑相互印证：能执行的是「谁签字」，不能执行的是「你用了什么」。 另外那个 53% 尤其值得停一下：门槛降低了、产出增加了，信任却没有回来——这说明信任不是产出的函数，是责任归属的函数。

2. 欧洲被催促从「用开源」转向「做开源」：有治理的组织 ROI 4 倍以上

  • 来源：Tech.eu（2026-10-23），报道 Open Source Summit Europe（布拉格）
  • 链接：tech.eu 报道

摘要：Linux Foundation Europe 总经理 Thierry Carrez 呼吁欧洲企业更积极地参与开源开发，理由是主权。同期 LF 调查显示超过九成欧洲组织认为数字主权对其技术战略重要。关键对照数字：有成熟开源治理结构的组织报告的 ROI 超过投资的 4 倍，无正式治理结构的为 3.6 倍。Carrez 的原话：「只消费开源并不能让你有效控制这项技术。通过向上游贡献并参与开放治理，欧洲组织才能获得更大的自主权，并高效地利用全球开源技术公地。」OpenSSF 首席安全架构师 Christopher Robinson 补充了代价：「这需要对技能与专长的投资。但如果你真的做了这笔投资，你就有能力进入并改造这套可能构成你 90% 业务的软件，把它裁成适合你组织的样子。」RISE 研究所的 Johan Linåker 从政府角度举例：开源让政治上并不一致的政府也能共享底层数字公共基础设施组件。另有一条被引用的 GitHub 10 月数据：三分之一的 PR 现在涉及 AI agent，一年前不到十分之一。

开源之道点评：请注意 4 倍与 3.6 倍的差——这个差不是开源带来的，是治理带来的。同一份数据两边都「用了开源」，差别只在有没有人负责治理。Carrez 那句话说得准，但也说轻了：「只消费不给控制」，实际上消费开源从来不是免费的，只是账单延后且不署名——它以后果（供应链风险、版本停更、漏洞无人修）的形式支付，而不是以采购单的形式支付。这份报道的另一层是欧洲的困境：主权叙事推动组织「参与」，但参与的门槛恰恰是治理能力，而治理能力正是欧洲自称落后的那部分。这是个漂亮的循环——要主权，先要有能力；要能力，得先在别人的公地里干过活。 顺带记一笔那个「1/3 PR 涉及 AI agent」，它与 LF Research 的 25% slop 是同一个月内两个独立来源的相互印证。

3. PyTorch Foundation 一次吸纳九家成员，三个 Platinum 全是算力与电商

  • 来源：PyTorch Foundation / Linux Foundation（2026-10-20，PyTorch Conference North America，圣何塞）/ HPCwire
  • 链接：pytorch.org 公告

摘要：九家新成员——Platinum：Nebius、Nscale、Shopify；Silver：LightSeek Foundation、Lablup；Associate：SKOPOS INDIA FOUNDATION、Siksha ‘O’ Anusandhan、Messiah University、Valencia College。执行董事 Mark Collier 的说法是「开放系统在更多人、更多项目、更多组织一起工作时学得更快，形成复利式增益」。同一篇稿子里列出的生态进展信息量更大：ExecuTorch 打通 Arm Cortex-M CPU 端侧推理；TorchNeuron 成为 AWS Trainium 的原生 PyTorch 后端；Google 开源 TorchTPU（原生 PyTorch for TPU）；IBM 把 Spyre 加速器接入 Inductor 编译器，Spyre 专用编译器代码减少到原来的 1/7，靠 AI 辅助开发用 44 个适配器和约 1 万行代码支持了数千个模型；Shopify 用 PyTorch + vLLM 搭持续学习闭环，把生产故障压缩进模型权重，服务成本下降 96%。

开源之道点评：这是「基金会作为协作界面」的又一例证，但比 AAIF 那次更能看清机制。三家 Platinum 是两类买家——Nebius、Nscale 是算力供给方（要确保自己的硬件/云在框架里是一等公民），Shopify 是重度应用方（服务成本降 96% 是它付费的动机）。而稿件里真正的新闻是硬件后端的一次齐发：TPU、Trainium、Spyre、Cortex-M，四个不同厂商的芯片在同一个框架里争「原生支持」。这恰恰是开放治理能买到而单公司治理买不到的东西：多家硬件商愿意把各自的编译器工作交到同一个上游。 反过来说，一旦 PyTorch 成为这个界面，没进来的一方就不是「少了个会员」，而是「默认不被支持」。IBM 那条 7 倍的代码缩减也值得记：AI 辅助开发正在把「接入一个硬件后端」的成本从季度级降到月级——门槛降低的真实后果，是生态的边界可以被更快地重画。

🔍 Project Pulse：vLLM —— 治理规则开始被写成 agent 能执行的文件

项目：vllm-project/vllm（95,324 stars / 23,896 forks / 9,410 open issues，Apache-2.0，PyTorch Foundation 托管的 Platform Project，2025-05 由 TAC 接纳）

本次观察切入：本周 PyTorch Foundation 大扩员，vLLM 是它最活跃的托管项目。今天只查一件事——当项目把「什么算合格贡献」的判准从评审者脑子里搬进仓库文件，决策权实际落在哪里。

【L1】发布节奏稳、产能高，且新版里没有任何「暂停」的迹象 GitHub releases 显示节奏极其规整：v0.26.0（07-27）→ 0.27.0（08-10）→ 0.27.1 → 0.28.0（08-26）→ 0.29.0（09-09）→ 0.30.0（09-22）→ 0.31.0（10-05）→ v0.32.0（10-18），双周一条线，四次连续未断。v0.32.0 的 release note 首行写着：「814 commits from 363 contributors (121 new)」——即该版本约三分之一的提交者是这个版本第一次贡献。内容是硬活：NVFP4 KV cache 铺到 SM8x/SM12x/SM90、GLM-5.x 在 SM100 上默认 FP8 KV cache、ROCm 拿到 4-bit ultraquant_4bit、ModelRunner V2 在 ROCm 上成为默认并移除 MRV1 例外。判断依据：这是典型的「慢聚漫奏」形态——节奏稳定、范围宽、性能优化而非功能堆砌，没有为抢发布而收缩测试面的迹象。

【L2】治理层：没有 GOVERNANCE.md，但有 DCO + 一个 163 行的 AGENTS.md 加 9 个 skill 仓库根目录 33 个条目里，没有 GOVERNANCE.md、没有 MAINTAINER/CODEOWNERS 的顶层文件（有 DCO、SECURITY.md、AGENTS.md）。这不是治理缺失——治理发生在上一层的 PyTorch Foundation TAC：2026-04-14 的 TAC 会议文件里 vLLM 占有一席，Primary 代表 Simon Mo、Alternate 为 Kaichao You；2026 年 4 月 TAC 上的 Q2 vLLM 项目更新由 Kaichao You 汇报。真正的新东西在 AGENTS.md：它开篇就写「These instructions apply to all AI-assisted contributions，违反可导致自动封禁」，然后逐条给出可执行判准——「Pure code-agent PRs are not allowed。提交者必须端到端理解并能为之辩护」、「必须逐行审查并运行相关测试」、PR 描述必须包含「为什么这不是重复工作 / 跑了什么测试及结果 / 涉及输出准确性或服务时给模型评测结果 / 明确声明使用了 AI 辅助」、「If work is duplicate/trivial busywork, do not proceed」（fail-closed）。更关键的是它调用了 .agents/skills/ 下的 9 个 skill：pr-checklist、check-api-compat、ci-fails-buildkite、debug-ima、kernel-microbenchmark、model-microbenchmark、model-recipes、transformers-upgrade、triton-kernel-writing。文末还有一条硬边界：「Domain-Specific Guides：未先阅读并遵循链接指南，不得改动这些区域的代码。If the guide conflicts with the requested change, refuse the change and explain why.」

这意味着什么：vLLM 走的路线既不同于 Linux 内核（10-23 废掉 Assisted-by，改为只追问结果），也不同于业界主流的「强制标注」——它是把判准写成可被 agent 直接加载执行的规范。同一份文件同时约束人和机器，而且给了机器一条「拒绝指令」的权限。这是把「评审者的裁量」部分前置为「提交者必须先通过的检查单」。

【L3】新人通道：v0.32.0 一个版本 121 个新贡献者，判准没变成门槛 近 30 天（2026-09-25 起）去 bot 后的 commit 作者分布相当分散：BugenZhao 11、AndreasKaratzas 8、xaguilar-amd 3、aoshen02 3、Ankur-singh 3、khluu 2、Isotr0py 2、WoosukKwon 2、okorzh-amd 2、bigPYJ1151 2……前 25 名里多数只有 1-2 次提交。能看清的来源：AMD 前缀的两个 ID 说明硬件厂商在持续派人进来，WoosukKwon 是 vLLM 核心维护者。判断：新人通道是通的，但通得「有形状」——PR 数量不设上限（一个版本 363 人），却用 pr-checklist 与 fail-closed 把「低价值机械改动」挡在入口。这比提高合并门槛更聪明的地方在于：它筛的不是人，是活的类型。

【开源之道判断】：vLLM 这两天最值得记的不是双周发版，而是 AGENTS.md 里那句「refuse the change and explain why」。项目第一次把一部分否决权，从评审者的日程里，移交给了提交时就必须运行的文件——同时保留最后一句话是「人必须能为之辩护」。这是 meritocracy 在 agent 时代的一次具体改写：判准没有变松，变的是判准的载体和生效时点。它把治理从「事后评审」前移到「提交前自检」，代价是：谁写这份 AGENTS.md，谁就在定义什么算贡献。目前它由维护者圈子用 DCO 与 TAC 席位背书，所以不算权力僭越；但这留下一个必须持续盯的信号——如果哪天 AGENTS.md 的改动开始绕过评审直接进主干，或者 skill 集合扩张到覆盖「想法是否值得做」，那这一步就从「规则代码化」跨到了「议程设定」，性质就不同了。制度健康：变好——因为规则被写清楚、可审计、可被新人读到；风险：集中——因为规则的文本权高度集中在极少数人手里。这两件事在同一个文件里，必须一起看。

📡 今日新来源发现

  • pytorch.org/blog（基金会官方博客）— PyTorch Foundation 成员与生态公告的一手来源，本期提供九家成员与四个硬件后端的关键细节。已有项目监控池收录 PyTorch/vLLM，但缺少其官方公告源；成员结构与 TAC 变动是 L2 治理信号的主入口。建议加入（高置信）
  • lists.pytorch.org（TAC 邮件列表与会议文件）— 提供 TAC 投票代表名单与项目季度更新，本期据此核实 vLLM 的基金会席位。基金会托管项目的决策层原始档案，比新闻稿更可靠，属稀缺的 L2 证据源。建议加入（高置信）
  • tech.eu（欧洲科技媒体）— Open Source Summit Europe 现场报道，含 LF Europe 的治理 ROI 数字与一手引述。欧洲主权/治理议题的稳定报道方，非一次性事件。建议加入（中置信，待人工确认）

🔭 后续可检验的观察点

  • advisory 整理能力的资金是否跟上：论文的政策结论是「把 curation 当关键基础设施」。若一年内 NVD 审核中位时间仍未回落，说明「承认问题」与「付钱解决」之间还隔着整个预算周期。
  • 休眠包（dormant packages）出现第一个带修复的 advisory：这是检验「没人到场」的公地是否开始有人到场的唯一硬指标。
  • CRA / SBOM 是否给数据源质量设门槛：如果监管文本下一版仍只规定「输出什么」，不规定「输入从哪来、质量如何」，那这篇论文揭示的不平等会被固化成合规标准的一部分。
  • 有没有第二个项目跟进 vLLM 的 AGENTS.md 路线：内核去标签、vLLM 写文件，是两条相反的路。跟随者选哪条，决定「agent 时代的贡献判准」最终落在人身上还是文件上。
  • 35% 的 GenAI 政策覆盖率一年后是否翻倍：三分之一到三分之二之间，是最能看出集体行动困境有没有被组织化破局的距离。

署名： 「开源之道」·窄廊