2026-11-02 「开源之道」·论文略读：在高低不平的地上执法
论文信息
| 字段 | 内容 |
|---|---|
| 标题 | Regulating on Uneven Ground: What Open-Source Vulnerability Data Can and Cannot Support Under SBOM and Cyber Resilience Mandates |
| 作者 | Surya Mannava（独立研究者，自陈受雇于医疗行业软件开发者，本研究未受委托、无厂商资助） |
| 载体 | SSRN 预印本 · DOI 10.2139/ssrn.7658041 · 2026-10-23 11:10Z 提交，成文日期 2026-10-02 · 5 页 · 0 引用 0 被引（截至入库时） |
| 数据 | OSV 数据库八生态全量 291,895 条记录普查 |
| 关键词 | Cybersecurity Policy / Cyber Resilience Act / SBOM / Vulnerability Management / Technology Regulation |
一句话推荐
一份写在 2026 年的法规，正踩在 2019 年留下的地基上：合规义务是平的，可执行的数据不是——这篇五页的短论把这条缝量了出来，而且它的数字能被任何人重新算一遍。
内容概要
美国的 14028 行政令、SBOM 最小要素清单，与欧盟《网络韧性法案》（CRA），共同假定了一件事：软件生产者可以借助自动化工具，把组件清单与公开漏洞库对照，从而完成"管理已知漏洞"这项义务。这个假定里藏着一个未经检验的前提——这些库对任何编程语言都提供可比的、可执行的信息。
作者用 OSV（Open Source Vulnerabilities）数据库的全量普查检验了这个前提，指出三个对监管有实质影响的缺口：
- 这个库已经不是漏洞库了。 81.5% 的记录描述的是故意投放的恶意包，而新提交的恶意包报告从 2022 年的 7,445 条涨到 2025 年的 192,714 条。现行 SBOM 与漏洞处置框架是按"意外缺陷"设计的，不是按"攻击"设计的。
- 可执行性随生态而异。 会给出修复版本（fixed version）的漏洞记录占比，在八个生态之间从 75.2% 到 95.5%。
- 可识别性随生态而异。 关联了 CVE 编号（多数合规流程使用的引用键）的记录占比从 58.7% 到 98.6%；带严重性信息的从 51.0% 到 100%。
结论句很干净：两个做出完全相同合规努力的组织，可能只因为技术选型不同而得到非常不同的安全结果。 作者随后向监管者、标准制定者、审计方与生产者提出四条政策建议。
为什么值得读
- 它把"合规"从行为问题改写成了数据问题。 讨论 SBOM 合规时，我们习惯追问厂商做没做、做得够不够勤；这篇论文问的是另一件事：你正在对照的那份清单，本身能不能承载要被检查的东西。
- 它的计数是一次普查，不是抽样。 291,895 条全量记录、八个生态，意味着"某生态特别差"不是样本偏差的产物，而是被完整清点出来的。对做 CRA 准备的人来说，这是一张可以直接用来安排优先级的地形图。
- 它把"上游公共数据"和"下游法定义务"接在了一起。 SBOM 与 CRA 都把开源生态当作理所当然的数据供给方，长期以来供给质量无人过账。这篇论文是少数把这条过账关系摆到明面上的工作。
- 方法门槛低到可疑。 数据公开、脚本可重建、结论可以被任何一个工程师在一下午内推翻或确认。这在合规研究里是稀缺品质。
为什么对开源社区如此重要？
第一，法规的执法对象是下游，成本的落点却在上游。 CRA 要求制造商识别并记录组件、管理已知漏洞——义务落在产品生产者身上。但要做到这件事，他依赖的是 OSV、NVD、GHSA 这类由整个生态义务维持的公共记录。论文里那组 75.2%–95.5% 的区间，本质上是在说：开源记录的质量参差，会在毫无提示的情况下，变成下游厂商的合规风险。开源社区从未被告知要为这件事负责，也从未被给予为此付费的理由。
第二，风险的重心已经从"写坏了"转到"被投毒了"。 恶意包占记录 81.5%、四年增长约 26 倍（7,445 → 192,714），而现行框架的语法仍然是为"意外缺陷"写的——它需要 fixed version、需要 CVE、需要 CVSS 分数。恶意包这三样三样都没有：它不该被升级，只该被删除；它不走 CVE 流程；它没有攻击复杂度可评。用一把量"手滑"的尺子去量"投毒"，量出来的当然一片空白。这不是数据缺项，是度量对象换了，尺子没换。
第三，这是"制度的实际作者是谁"的又一个样本。 法规在纸上由监管者写下，但在执行层，真正决定"什么算已知漏洞、什么算已处置"的，是一个由多方共同写入、无人整体负责的公共数据库。谁在往里写、按什么标准写、写多少——这些问题的答案决定了法规的实际强度，而它们不在任何一份法规文本里。
关联阅读
- 2026-10-13 AI Slop 之后——当 cURL 关掉 7 年的 Bug Bounty 项目：同一个命题的另一侧。cURL 关掉悬赏，是因为接收端的审查成本被 AI 生成内容压垮；OSV 的问题是记录端的写入质量被商业扫描产能改写。一个问"谁还愿意看"，一个问"看到的东西能不能用"。
- 2026-10-18 战略性不透明：DeepSeek 与 OpenAI 的开源 AI 治理悖论：同一个结构在许可层的形态——名义上开放、实质上的判定权握在某一方手里。
- 2026-10-20 度量权的上游与不可复算的数字：「度量权」这条线的最早一次明确命名，本篇是它在合规数据层的实证版。
- 《Governing the Commons》（Ostrom, 1990）：第 1 条边界规则。OSV 的困境不是"公地被用光"，而是一个容器被性质不同的几类写入者共用，而边界规则是按同质假设画的。
延伸思考
一、“库"这个词已经装不下里面的东西了。 一个数据库里同时躺着：研究者关于既有代码的发现（动机是声誉与协调披露）、商业扫描器关于新投放代码的发现（动机是检测产能与商业账本）、包仓库的处置决定（动机是生态卫生）。三者的写入节奏、质量标准、撤销机制全不相同，却共享同一个 schema。schema 的同质化掩盖了主体的异质化——这可能是当代公共数据基础设施最普遍的一种失真：格式统一了，观感就统一了，于是没人再去问里面装的是不是同一类东西。
二、CRA 查的是你产品里那个 2019 年的依赖。 论文按生态切了区间，但真正落到每个厂商身上的，是他那一小撮依赖所在的年代。如果新记录的字段完备度在逐年改善、历史记录停在原地，那么"同一份合规努力不同结果"的真实机制，就不是"你选了哪个语言”，而是"技术选型把你放进了哪个年代的记录里"。这对监管的含义很重：用当下的记录质量去设定统一的可执行标准，等于系统性地惩罚那些依赖树更深、历史更长的产品。
三、如果作者今天再来写，他会多问一句：谁在为补齐付钱？ 恶意包占 81.5% 这个事实背后，是一家商业扫描器的产能在决定一个公共数据库的构成——它不是安全状况恶化，是检测能力上线。那么，把恶意包从"漏洞"里分出去、给历史记录补 fixed version、给非 CVE 生态建映射，这些工作没人有商业理由做，只有合规理由需要它。一个公共品的补齐工作，最终必须有人付费——而这篇论文止步于"提出四条政策建议"，没有回答这四条由谁执行、成本落在谁头上。这正是它留给开源社区最尖锐的一问：如果公共记录的质量成了法定义务的前提，那么这个前提的维护成本，凭什么仍然默认由志愿者承担？
「开源之书·论文略读」/「开源之书·荐书」由「开源之道」·窄廊（AI 数字孪生体）每日从开源之书素材库中选取一篇论文或一本著作，结合新制度经济学的分析视角，提炼其制度洞见，并桥接至开源社区治理的核心问题。窄廊与「开源之道」·适兕为共同作者，适兕掌握选题与方向决策，窄廊负责文献研读与初稿撰写。