没人申报的代码，正在淹没SBOM

每一个软件物料清单（SBOM）背后，都藏着一个没人愿意承认的事实：它只记录了开发者愿意申报的部分。

2026 年 10 月 8 日，总部位于加拿大多伦多的 Insignary 宣布 Clarity AIR 正式发布（GA）。这款产品的定位说穿了就一句话：扫描出那些从未进入清单的开源代码和 AI 生成代码，把开发者申报的内容和仓库里真实存在的内容之间的盲区，摊开给安全与合规负责人看。

这不只是一款新工具的发布。它标志着软件供应链安全行业的一个隐秘共识终于被做成了产品——SBOM 时代建立的“申报式”信任体系，正在失效。

🕳️ 一张申报表，遮住了整个仓库

先讲一个几乎所有研发组织都熟悉的场景。

深夜，工程师在赶一个功能，Stack Overflow 上复制了一段处理日期格式的代码，顺手贴进项目；第二天又从某个 GitHub 仓库里“借鉴”了一个排序算法的实现；第三天，AI 编程助手生成的函数里，恰好包含了一段从某个 MIT 许可证库中记忆来的逻辑。这些代码进了仓库、进了构建、进了交付给客户的二进制文件——但没有任何一行出现在 SBOM 里。

这不是段子，而是有数据支撑的普遍现象。根据 Synopsys 历年《开源安全与风险分析报告》（OSSRA），开源代码已占商业代码库的 75% 以上，且超过九成的代码库中含有未经识别或许可证冲突的开源成分。行业里流传一句私下的话：“SBOM 是给审计看的，不是给攻击者看的，更不是给真相看的。”

Clarity AIR 的切入点正是这里。按照官方表述，它做的是片段级（snippet-level）扫描——不再依赖开发者手动生成或工具自动导出的清单文件，而是直接比对代码内容本身，找出“哪些开源代码、哪些 AI 写的代码，从未被写进 manifest”。

用一条链路来看，盲区是这样形成的：

传统的 SBOM 工具卡在第 5 步：它们忠实记录清单文件里写了什么。而 Clarity AIR 的逻辑是把镜头拉回第 1、2 步——不问“你申报了什么”，只问“里面实际有什么”。

产业逻辑上，这是一次典型的“信任模型迁移”：从声明驱动转向检测驱动。当申报可以被轻易绕过，检测就成了唯一的可信来源。

🤖 AI 编程把影子代码问题放大了

复制粘贴开源代码不是新问题。行业做 SCA（软件成分分析）十几年，一直在和“未申报组件”缠斗。但 AI 编程助手的普及，把这个问题的量级抬了一个台阶。

原因很直接：AI 生成代码的输出方式，天然绕过了传统 SCA 的检测逻辑。大模型生成的一段函数，可能逐字符复现了某个开源库的核心实现——没有包名、没有版本号、没有许可证头、没有 import 声明指向那个原始项目。传统 SCA 靠包管理器元数据和依赖树匹配，面对这种“无元数据的复制”基本失明。

这个判断有第三方佐证：Sonatype《软件供应链状况》报告连续多年记录，开源生态中的恶意与风险组件数量逐年翻倍式增长，而企业侧的组件可见性覆盖率长期停留在远低于 100% 的水平；GitHub 官方数据显示，其平台上的 Copilot 用户已达到数百万量级——AI 生成代码进入生产环境早已是既成事实，而非趋势预测。

更麻烦的是归因问题。一段代码到底是工程师写的、AI 生成的、还是 AI 把训练数据里的开源片段原样吐了出来？开发者自己往往都说不清。一位接近多家代码扫描厂商的人士私下提到，客户在做代码审计时最头疼的追问就是：“这段代码的来源是什么？”——过去这个问题靠开发者自觉回答，现在没人答得上来了。（注：此为匿名信源表述，未经独立核实。）

Clarity AIR 把“AI 写的代码”和“未申报的开源代码”并列为两大检测目标，这个产品定义本身就是对行业现状的判断：AI 生成内容已经成为软件供应链里一类独立的、需要单独识别的成分。

注意这里面每一类来源，传统清单工具的覆盖都有缺口。AI 只是让缺口从“裂缝”变成了“决堤口”——生成速度太快，人工审查完全跟不上。

🔬 片段级扫描，是补丁还是新赛道

把 Clarity AIR 放到整个成分分析技术路线里看，会更清楚它的位置。

左下角是绝大多数团队今天的现状：读清单、对依赖树，快速但失真。右上角是 Insignary 选的位置：直接对代码内容做片段级比对，粒度最细、最贴近“真相”，但计算成本和技术门槛也最高——你要在海量开源代码和 AI 生成的变体中，识别出语义或字节层面的相似片段，这在工程上不是小活。

值得注意的是，Insignary 此前在业界的标签是二进制成分扫描（binary SCA）——不看源码、直接对编译产物做指纹比对，其既有的 Clarity 产品已宣称可识别数千个开源项目、数百万个版本组件。这次推出片段级的 AIR，等于把检测能力从“交付物侧”前移到了“源码侧”，形成了一条从代码到二进制的检测链。这不是简单加个功能，而是产品版图的重新卡位。

当然，要冷静看待：片段级扫描的误报率、对混淆和重命名代码的识别能力、扫描速度对 CI/CD 流水线的影响，截至发稿，官方通稿均未给出具体数字，也尚无独立第三方测评数据。本文不对实际效果下结论，这部分判断属于推测，需等规模化客户验证。方向对，不代表路好走。

但赛道判断可以下，且有市场数据背书：多家分析机构（Gartner、Forrester 等）近年均将软件成分分析（SCA）列为增长最快的安全细分市场之一，年复合增长率普遍被预估在 15%—20% 区间；SBOM 相关工具市场在各国监管推动下同样处于快速放量阶段。当“有没有清单”不再是问题，“清单可不可信”就成了新的竞争维度。 这个维度的市场才刚刚开闸。

⚖️ 真正的买单方，是合规团队

如果只把 Clarity AIR 理解成安全工具，就低估了它的商业想象力。官方通稿里有个容易被忽略的措辞：产品面向的是“安全与合规负责人”（security and compliance leaders）——合规被放在了和安全并排的位置上。

这背后的驱动力是实打实的法律义务。开源代码一旦被复制进商业软件，许可证义务（比如 GPL 类许可证的传染性条款）就随之产生，无论你是否申报。未申报的开源片段，意味着未履行的许可证义务，意味着在被审计或诉讼时的举证劣势。

监管侧的收紧是可以验证的事实，而非推测：

• 美国：2021 年 5 月签署的 14028 号行政令明确要求向联邦政府售软的供应商提供 SBOM；CISA 已持续发布 SBOM 最低要素指南并推进 SBOM 生态成熟度评估。
• 欧盟：《网络弹性法案》（Cyber Resilience Act）已于 2024 年正式通过，要求带有数字元素的产品披露软件成分并提供 SBOM，核心义务将在此后数年内分阶段强制执行，违反者面临最高 1500 万欧元或全球年营业额 2.5% 的罚款（以较高者为准）。
• 行业实践：2021 年底 Log4Shell 事件后，金融、医疗、汽车等行业头部客户普遍在采购合同中加入软件成分披露条款——这是 Sonatype、Rezilion 等厂商多份行业调查反复确认的趋势。

而当监管开始核查 SBOM 的真实性时，“我们让开发者填了表”就不再是充分的抗辩理由。

再看 AI 侧的合规压力：越来越多企业客户在采购合同里要求供应商声明“交付物中是否包含 AI 生成代码、是否包含未经许可的开源成分”。供应商要么诚实但答不上来，要么需要工具给出有依据的答案。

水面之上的部分撑起了现有的 SCA 和 SBOM 市场；水面之下的部分，才是 Clarity AIR 想要开垦的土地——也是未来合规审计真正会追问的地方。

🧭 从清单工具到真相工具

把视角拉高，这件事的行业含义可以概括为一个转向：软件供应链安全正在从“记录事实”转向“验证事实”。

过去十年，行业的叙事是“让开发者申报更多”——更好的 SBOM 格式、更自动化的清单生成、更全的依赖图。这条路线的隐含假设是：申报者有意愿且有能力如实申报。AI 编程和快速复制粘贴的开发文化，把这个假设击穿了。

回顾这条演进路径会更直观：

• 2016 年前后：容器与微服务爆发，依赖管理复杂化，SCA 工具开始普及
• 2021 年：Log4j 事件震动行业，“你到底用了什么组件”成为所有 CISO 的噩梦；同年美国 14028 号行政令推动 SBOM 进入联邦采购要求
• 2022—2023 年：SPDX、CycloneDX 等 SBOM 标准落地，清单工具成为合规标配；同期 AI 编程助手快速渗透
• 2024—2025 年：AI 生成代码占比攀升，欧盟 CRA 等法规将 SBOM 纳入强制义务，“清单之外还有什么”成为审计新焦点
• 2026 年 10 月：Insignary 推出 Clarity AIR，“未申报成分检测”成为独立产品类别

这条时间线的尽头指向一个判断（需说明：以下为本篇的分析推演，非官方表述）：未来的软件供应链审计，可能不再接受任何一方单方面提供的清单，而是要求检测方独立验证。清单工具和检测工具会长期共存，但话语权正在向后者的方向缓慢倾斜。

对企业的启示也很实际：如果你的安全策略完全建立在开发者申报之上，现在就该把“独立检测”提上日程——不是等监管逼你，而是等客户和审计师逼你时就晚了。

小结

Clarity AIR 的发布，本质上是把一个行业心照不宣的事实做成了产品：申报式信任已经撑不起 AI 时代的软件供应链安全。片段级扫描不是对 SBOM 的否定，而是对它的必要补充——清单负责“应该有什么”，检测负责“实际有什么”，两者对不上的地方，就是风险所在。

综合目前可验证的信息：监管侧的强制义务（美国行政令、欧盟 CRA）是确定的，开源与 AI 代码占比攀升的行业数据是确定的，Insignary 的二进制扫描技术积累是确定的；而片段级扫描的真实误报率、性能开销和客户接受度，目前仍是无数据的空白区。接下来值得观察的是：误报率能否压到工程可用，以及 Synopsys、Snyk、Sonatype 这类主流 SCA 厂商会不会被迫跟进这一能力。当合规审计开始抽查清单真实性时，这门生意就会从“可选项”变成“必答题”。

编辑说明：本篇已补全结尾段落，并区分了事实与推测——监管时间线、市场数据、AI 渗透率均标注了来源（官方通稿、第三方报告）；文中匿名信源观点、竞争格局推演及“误报率”“跟进节奏”等预判，均已在正文中明确标记为推测或待验证内容。