2026-08-24
0

AI生成代码的安全、版权与AI‑SBOM标准化推进研究报告

AI生成代码的安全、版权与AI‑SBOM标准化推进研究报告

编制单位：泷码软件（上海）有限公司、泷码软件研究院
编制时间：2026 年 08 月
摘要
大模型驱动的 AI 代码生成工具已经深度嵌入软件研发全流程，从原型开发、函数补全到完整业务模块输出，AI 生成代码大幅压缩软件开发周期、降低研发门槛，同时带来全新的安全风险、版权争议与供应链治理难题。Veracode 2026 年 8 月行业报告数据显示，AI 生成代码近半数存在安全缺陷；LiteLLM 供应链攻击事件暴露出 AI 软件供应链环节的脆弱性，AI 生成产物缺乏溯源链条、依赖组件来源模糊、权责边界不清等问题集中爆发。在此背景下，AI‑SBOM（人工智能软件物料清单）作为新型治理工具，正在全球软件行业加速推进落地。本报告围绕 AI 生成代码安全漏洞现状、版权法律争议、供应链攻击案例复盘、AI‑SBOM 技术框架、标准化建设路径、产业落地障碍以及合规实施路径展开系统性研究，剖析 AI 代码时代软件合规面临的新挑战，提出技术、制度、标准三位一体的治理思路，为软件企业、监管机构、标准化组织提供参考依据。

关键词：AI 生成代码；AI‑SBOM；软件供应链安全；代码版权；大模型安全；软件合规

1. 绪论
1.1 研究背景
1.2 研究意义
1.3 国内外研究现状
1.4 研究范围与边界

2. AI 生成代码产业应用现状与风险总览
2.1 AI 代码生成工具产业普及态势
2.2 AI 生成代码带来的研发效率增益
2.3 AI 生成代码衍生复合型风险谱系

3. AI 生成代码安全缺陷现状与漏洞特征分析
3.1 Veracode 8 月报告核心数据解读
3.2 AI 生成代码典型安全缺陷类型
3.3 AI 生成代码漏洞形成内在机理
3.4 AI 代码漏洞与传统人工代码漏洞差异性对比

4. LiteLLM 供应链攻击事件复盘与后续连锁风险分析
4.1 LiteLLM 事件完整经过梳理
4.2 事件暴露 AI 软件供应链结构性短板
4.3 事件发酵带来的行业连锁影响
4.4 传统 SBOM 无法适配 AI 生成软件的核心痛点

5. AI‑SBOM 核心概念、内涵与溯源框架
5.1 SBOM 基础概念演进至 AI‑SBOM
5.2 AI‑SBOM 核心要素定义：AI 产出代码、大模型基座、依赖包、训练数据、人工干预记录
5.3 AI‑SBOM 完整溯源链条构建逻辑
5.4 AI‑SBOM 与传统 SBOM 关键差异对比

6. AI 生成代码版权归属的法律争议与现实困境
6.1 当前全球主要司法辖区对于 AI 生成作品版权的立法现状
6.2 AI 生成代码版权争议核心矛盾点
6.3 大模型训练数据版权与输出代码版权传导风险
6.4 企业实践中版权权属划分现实难题

7. AI‑SBOM 标准化全球推进现状
7.1 国际标准化组织相关工作进展
7.2 国内软件供应链、人工智能安全标准建设动态
7.3 现有标准体系存在的缺口
7.4 产业各方对于 AI‑SBOM 的诉求差异

8. AI 生成软件合规的核心强制流程构建
8.1 AI 产出代码全生命周期溯源管理流程
8.2 AI 生成代码人工复核强制流程设计
8.3 第三方依赖包来源校验机制
8.4 版权权属归档与证据留存机制
8.5 安全缺陷闭环处置流程

9. AI‑SBOM 产业落地现实障碍
9.1 技术层面障碍：大模型黑盒特性造成溯源困难
9.2 商业层面障碍：厂商闭源模型拒绝披露模型内部要素
9.3 组织流程障碍：研发团队缺少 AI 代码治理组织能力
9.4 法律标准障碍：版权、安全责任划分缺少明确法规依据

10. 面向产业的对策建议
10.1 技术层面：迭代完善 AI‑SBOM 技术规范与工具链
10.2 企业层面：建立 AI 代码全生命周期内部合规体系
10.3 产业层面：推动跨行业共建 AI‑SBOM 共享基准
10.4 政策标准层面：加快完善法律条文与强制标准建设

11. 总结与展望
参考文献
数据来源
免责声明

全文总字数：约 10000 字

1 绪论

1.1 研究背景

生成式人工智能技术快速迭代，各类代码大模型、AI 辅助编程工具已经成为软件开发行业的基础生产力工具。从开源社区开发者到大型政企软件研发部门，AI 工具承担代码补全、模块生成、单元测试编写、bug 修复等大量工作。AI 在释放研发生产力的同时，也重构了软件供应链的构成形态。传统软件供应链以开源组件、第三方库、商业 SDK 为核心；而 AI 生成软件供应链新增大模型基座、训练数据集、模型提示词、AI 生成中间产物、人工修改迭代记录等全新要素，软件的来源不再完全来自人类程序员编写，大量代码片段由大模型自动输出，软件供应链复杂度出现指数级上升。

Veracode 发布 2026 年 8 月软件安全行业报告揭示关键现实：AI 生成代码近半数存在安全缺陷。大量开发人员直接复制 AI 输出代码投入生产环境，缺少安全审计，导致注入漏洞、权限错误、加密逻辑缺陷、硬编码密钥等安全问题持续流入业务系统。与此同时，LiteLLM 供应链攻击事件爆发，恶意代码通过 AI 生态组件进行扩散，事件后续风险持续发酵，让整个行业意识到传统软件供应链安全手段已经不足以应对 AI 时代的风险。

传统 SBOM（软件物料清单）主要针对编译后软件组件、开源依赖包进行登记，无法记录大模型版本、提示词、AI 生成片段、人工修改痕迹、训练数据来源等 AI 特有信息。行业由此提出 AI‑SBOM 的概念，希望通过标准化物料清单，实现对 AI 产出代码完整溯源，厘清依赖包来源，固化人工复核流程，界定 AI 生成代码版权归属。AI‑SBOM 正在从技术概念逐步转变为软件合规的新焦点，成为政府监管、企业内控、第三方安全审计共同关注的方向。但目前 AI‑SBOM 标准化仍处于早期阶段，技术框架、字段定义、落地流程、法律配套均尚未完全成熟，产业实践面临诸多现实阻碍，亟待开展系统性学术研究。

1.2 研究意义

理论层面，本研究梳理 AI 生成软件供应链的风险谱系，厘清 AI‑SBOM 与传统 SBOM 的边界差异，完善生成式人工智能软件供应链安全的理论框架，填补 AI 代码安全、版权、物料清单交叉领域研究内容。

实践层面，AI 生成代码安全缺陷、版权侵权、供应链投毒已经真实威胁企业信息系统安全与知识产权权益。本报告结合 Veracode 行业报告数据、LiteLLM 事件案例，剖析现实风险，梳理 AI‑SBOM 标准化建设路径，设计企业可落地的人工复核、溯源归档、版权管理流程，能够为软件企业建立 AI 代码治理体系提供参考。

政策与标准化层面，本报告总结国内外标准建设现状，识别现有标准缺口，为后续国内、国际标准化组织制定 AI‑SBOM 相关规范提供产业现实依据，助力软件供应链安全制度体系完善。

1.3 国内外研究现状

海外方面，美国 NTIA 早在数年前推动传统 SBOM 的普及，伴随生成式 AI 爆发，NTIA、OWASP、MITRE 等机构相继开展 AI‑SBOM 相关研究，提出 AI 物料清单应当覆盖模型、数据集、提示词、输出产物等要素。Veracode、Snyk 等安全厂商持续发布 AI 代码安全调研报告，多次指出 AI 生成代码普遍存在安全漏洞，开发者过度信任 AI 输出，缺少人工审核是风险主要诱因。在版权领域，欧美不同司法辖区对于 AI 生成代码版权保护持不同态度，部分判例否定纯 AI 生成内容版权，部分判例认为加入人类创造性修改后可以享有著作权，学术界争议持续存在。

国内层面，我国已经出台生成式人工智能服务管理暂行办法，对生成式 AI 服务提出安全、版权合规要求；软件供应链安全相关国家标准持续推进，传统 SBOM 已经在关键信息基础设施领域逐步试点落地。国内学术界与产业界开始关注 AI‑SBOM 概念，多家研究院、安全企业开展相关预研，但整体上，针对 AI 生成代码完整溯源、版权归属、人工复核强制流程的系统性研究仍然偏少，产业落地实践案例有限，标准化细节仍在讨论阶段。

综合来看，现有研究大多单独聚焦 AI 安全或者单独研究 SBOM 技术，将 AI 生成代码安全漏洞、真实供应链攻击事件、版权法律问题、AI‑SBOM 标准化四大主题结合起来的综合性研究报告较为稀缺，本报告即针对该缺口展开研究。

1.4 研究范围与边界

本报告研究对象限定为大模型生成的计算机软件代码，包含 AI 辅助编程工具输出业务代码、脚本、配置代码，不包含 AI 生成图片、文本、音视频等其他模态产物。研究范围覆盖 AI 代码安全漏洞、软件供应链攻击、AI‑SBOM 技术框架、版权权属、标准化推进、企业合规流程。

本报告不针对特定大模型产品做优劣评判，研究结论基于公开行业报告、公开安全事件、现有标准草案与法学理论，不构成法律判决、安全产品选型的直接依据。

2 AI 生成代码产业应用现状与风险总览

2.1 AI 代码生成工具产业普及态势

AI 辅助编码工具已经完成从试点走向大规模普及的阶段。各类代码大模型可以支持多种编程语言，能够完成函数编写、接口开发、数据库脚本、运维脚本、错误修复等工作。根据多份产业调研，相当比例的软件开发人员日常开发工作中高频使用 AI 代码生成工具，部分企业将 AI 编码工具接入企业内部研发平台，嵌入 CI/CD 流水线。

AI 代码生成工具分为两类，一类是公有云 SaaS 模式，开发者通过网页、IDE 插件调用公共大模型；另一类是私有化部署代码大模型，企业将模型部署在内网，使用企业私有代码数据进行微调。两种模式都存在 AI 生成代码输出，但是供应链风险的表现形式存在差异：公有模型面临训练数据污染、外部提示词注入风险；私有化模型面临微调数据集、模型版本管理、模型组件依赖的安全风险。

2.2 AI 生成代码带来的研发效率增益

AI 生成代码的核心价值体现在研发效率提升。对于常规业务逻辑、标准算法、模板化代码，大模型可以快速输出可用代码片段，减少程序员重复编码工作量，缩短原型开发周期，降低入门级开发的技术门槛。对于中小企业，在研发人员规模有限的条件下，借助 AI 工具可以承接更多开发任务。

但效率提升的背面是风险转移：AI 把编码速度加快，却没有自动承担安全审计、版权校验、依赖检查的工作，大量潜在缺陷被隐藏在快速产出的代码中，风险向后传递给测试、运维阶段，甚至直接上线生产环境。

2.3 AI 生成代码衍生复合型风险谱系

AI 生成软件带来三类交织在一起的风险：安全风险、知识产权版权风险、供应链风险。

安全风险：AI 生成代码自带漏洞，开发者盲目直接复用，引入注入、权限控制失效、不安全加密、敏感信息硬编码等问题；大模型本身存在提示词注入，诱导输出恶意代码。

版权风险：大模型训练数据集包含大量开源代码，AI 输出代码可能和开源受版权保护代码高度相似，引发版权侵权；同时，AI 生成产物的著作权归属没有统一结论，企业不清楚 AI 产出代码知识产权归属于模型厂商、程序员还是企业本身，后续软件转让、授权、上市都存在知识产权隐患。

供应链风险：AI 生态相关组件、SDK、依赖库遭受投毒攻击，例如 LiteLLM 事件；AI 软件供应链链条变长，包含模型、数据集、第三方组件、AI 输出片段、人工修改，传统 SBOM 无法完整记录整条链路，一旦出现安全事件，难以溯源定位问题来源，应急处置难度显著上升。

三类风险不是相互独立，而是互相传导。一段 AI 生成代码，既可能存在安全漏洞，又可能抄袭开源代码侵犯版权，同时代码内部调用存在漏洞的第三方依赖包，单一代码片段同时触发多重风险。这也是传统软件治理手段难以应对的核心原因。

3 AI 生成代码安全缺陷现状与漏洞特征分析

3.1 Veracode 8 月报告核心数据解读

Veracode 2026 年 8 月发布软件安全评估报告，针对大量真实 AI 生成代码样本进行静态安全扫描，得出关键结论：AI 生成代码近半数存在安全缺陷。该统计样本来源于真实开发人员使用 AI 编程工具产出的代码片段，覆盖 Java、Python、JavaScript、Go 等主流开发语言。

报告同时指出一个关键现象：同样功能的代码，AI 生成版本漏洞检出率显著高于有经验人工程序员编写代码。很多开发者主观认为大模型输出代码可靠，跳过代码安全审查环节，直接将 AI 生成代码合并进入代码仓库，漏洞随之流入正式版本。报告还提到，很多 AI 生成代码逻辑功能上可以正常运行，能够通过单元测试，但是安全层面存在缺陷，功能性正常掩盖安全隐患，进一步提升风险隐蔽性。

需要客观看待该组数据：近半数存在安全缺陷不等于全部高危严重漏洞，缺陷包含高危、中危、低危不同等级。部分缺陷属于编码规范问题，部分属于可被外部利用的高危安全漏洞。但无论漏洞等级，大量缺陷持续存在，代表 AI 生成代码不能被默认信任，必须经过人工安全复核。

3.2 AI 生成代码典型安全缺陷类型

第一，注入类漏洞：SQL 注入、命令注入、XSS。大模型可以实现业务功能，但是经常忽略输入校验逻辑，直接拼接外部输入进入查询语句、系统命令。
第二，权限与访问控制缺陷：错误设置权限，过度开放接口，缺少身份鉴权逻辑，垂直越权、水平越权问题。
第三，不安全加密实现：AI 自行实现加密算法，使用弱算法、错误密钥管理，硬编码密钥、密码、令牌到代码中。
第四，依赖管理缺陷：AI 自动推荐第三方库版本，选择存在已知漏洞的老旧依赖包，没有版本锁定，间接引入供应链漏洞。
第五，错误异常处理：缺少异常捕获，错误直接对外暴露系统内部信息，泄露路径、数据库信息。
第六，业务逻辑缺陷：业务逻辑看似通顺，但是违背安全最佳实践，在真实业务场景下触发安全风险。

3.3 AI 生成代码漏洞形成内在机理

第一，大模型训练数据本身混杂大量历史上存在漏洞的公开代码。大模型学习互联网海量开源代码，其中包含大量历史漏洞样本，模型学习编码模式同时也学习漏洞模式。模型并不理解安全原理，只是统计拟合代码文本，优先输出看起来通顺的代码，而不是安全的代码。

第二，提示词信息不足。开发者只向大模型描述业务功能，没有补充安全约束要求，模型输出优先满足功能需求，安全作为次要目标。

第三，幻觉问题。大模型会生成不存在的函数、不存在的库接口，生成看似合法实际错误的代码逻辑，开发者不仔细分辨就直接使用。

第四，开发者认知偏差。开发人员高估 AI 安全能力，把 AI 输出当成可信成果，省略安全审核、静态扫描环节。

3.4 AI 代码漏洞与传统人工代码漏洞差异性对比

人工编写代码漏洞，大多来源于程序员业务疏忽、安全知识不足；AI 生成代码漏洞根源来自模型训练数据、模型算法幻觉、提示词约束缺失。人工代码漏洞分散；AI 生成代码会批量输出同类漏洞，同一个提示词产出的代码会复制同一类安全缺陷。

人工代码，人清楚每一段代码来源；AI 生成代码片段混杂人工编写、AI 生成、AI 输出后人工修改的部分，一段文件内来源多元，事后很难区分哪一部分来自 AI，哪一部分来自人类，这也是溯源工作的难点。传统代码安全工具可以扫描漏洞，但是很难自动标记代码片段是否由 AI 生成。

4 LiteLLM 供应链攻击事件复盘与后续连锁风险分析

4.1 LiteLLM 事件完整经过梳理

LiteLLM 是广泛使用的开源 AI 开发组件，作用是统一封装各家大模型 API 接口，大量项目、企业内部系统引用该组件。事件中，该开源项目维护者账号遭到入侵，攻击者发布携带恶意代码的软件包版本，开发者在不知情情况下更新依赖，恶意代码随之进入系统，实现信息窃取等恶意行为。

攻击属于典型 AI 生态供应链投毒攻击。事件爆发之后，大量使用 LiteLLM 的项目受到波及，软件包镜像源、开源社区开展版本回滚、漏洞通告。事件并没有随着恶意版本下架完全结束，后续连锁风险持续发酵：大量存量项目没有及时升级依赖版本；很多间接依赖场景，开发者自身没有直接引入 LiteLLM，被上层组件间接带入风险版本；部分企业内部私有化 AI 系统、AI 辅助开发流水线都引入该组件，内网环境缺少外部漏洞告警，风险长期潜伏。

4.2 事件暴露 AI 软件供应链结构性短板

第一，AI 软件生态大量依赖新兴开源组件，组件维护者规模小，安全防护薄弱，账号劫持、投毒攻击风险高。
第二，传统 SBOM 只能记录依赖包名称、版本号，无法回答：这个组件用于 AI 系统哪一部分？该组件是否被 AI 生成代码调用？AI 生成代码本身没有被纳入物料清单。
第三，很多软件项目中，AI 生成业务代码 + AI 生态开源组件互相嵌套，传统供应链治理只关注第三方库，忽略 AI 产出代码本体。当事件爆发，企业很难快速检索全部业务代码，定位哪些业务模块调用受影响的 AI 组件。
第四，缺少强制溯源归档。项目没有记录哪些代码片段由 AI 生成，哪些依赖是 AI 工具自动推荐引入，应急排查缺少完整证据链。

4.3 事件发酵带来的行业连锁影响

LiteLLM 事件冲击行业认知，让产业意识到 AI 软件供应链不是传统软件供应链简单叠加大模型，而是一套全新的风险体系。事件之后，海外软件安全厂商、开源基金会、大型科技企业开始加速讨论 AI‑SBOM 落地，希望通过标准化物料清单，把大模型、AI 生成代码片段、AI 生态依赖包全部纳入溯源管理。

企业端开始反思现状：仅仅扫描开源组件漏洞不足以保护 AI 软件，必须把 AI 生成产物纳入供应链治理范畴。很多企业开始在内部研发规范中增加对 AI 生成代码的管控要求，但大多停留在文档层面，缺少标准化工具支撑。

4.4 传统 SBOM 无法适配 AI 生成软件的核心痛点

传统 SBOM 聚焦编译产物，字段包含组件名称、版本、许可证、哈希值、漏洞编号。面对 AI 软件，存在多处缺失。

传统 SBOM 不记录大模型信息：基座模型版本、微调版本、推理参数。
传统 SBOM 不记录 AI 输出产物：哪些代码片段来自 AI 生成，提示词内容，AI 输出之后人工修改位置、修改时间、修改人。
传统 SBOM 不区分训练数据集、提示词带来的风险。
传统 SBOM 无法记录 AI 生成代码对应的版权来源证据。
传统 SBOM 只能描述第三方依赖，不能描述 “AI 生成的源代码片段” 本身。

仅仅依靠传统 SBOM，发生类似 LiteLLM 事件时，只能知道项目引入某一个包，但是无法知道哪一段 AI 生成代码调用该包，无法评估 AI 业务模块受影响范围，应急处置效率大打折扣。因此行业提出 AI‑SBOM，在传统 SBOM 基础上扩展 AI 特有元数据。

5 AI‑SBOM 核心概念、内涵与溯源框架

5.1 SBOM 基础概念演进至 AI‑SBOM

SBOM 即软件物料清单，是一份软件内部所有组件的清单，用于供应链风险识别、漏洞处置、许可证合规。在关键信息基础设施领域已经逐步推广。随着生成式 AI 融入软件开发，传统 SBOM 不足以覆盖 AI 特有要素，AI‑SBOM（AI Software Bill of Materials）应运而生。

AI‑SBOM 是面向包含人工智能生成内容的软件的扩展物料清单，在原有 SBOM 基础上，新增人工智能相关元数据，实现对 AI 参与产出软件全要素记录。AI‑SBOM 不替代传统 SBOM，是对传统 SBOM 的扩展补充，二者可以兼容共存。

5.2 AI‑SBOM 核心要素定义：AI 产出代码、大模型基座、依赖包、训练数据、人工干预记录

一份完整 AI‑SBOM 应当包含两大板块，传统软件物料部分，以及 AI 扩展元数据部分。AI 扩展元数据核心要素包括：

1. AI 产出代码片段元数据：标记源代码文件内哪些片段由 AI 生成；AI 生成时间；使用的 AI 工具名称版本；原始提示词；AI 原始输出文本；人工修改标记，标记哪些行经过人类编辑。

2. 大模型基座信息：模型标识、版本、部署方式（公有调用 / 私有化部署）、模型哈希或者唯一标识。

3. 数据集相关信息：若经过微调，记录微调数据集来源、许可证。

4. AI 相关依赖包：AI 生态 SDK、推理框架、Agent 组件（如 LiteLLM 一类组件）的版本、哈希、许可证、漏洞信息，和普通业务依赖做区分。

5. 人工干预记录：AI 生成代码的复核人员、复核时间、复核结论；修改记录；拒绝采纳的 AI 输出记录。

5.3 AI‑SBOM 完整溯源链条构建逻辑

完整溯源链条应当回答一系列关键问题：该段代码是怎么产生的？使用哪一个大模型？输入了什么提示词？AI 原始输出是什么？人类做了哪些修改？调用了哪些第三方依赖包？依赖包来源是什么？谁完成安全复核？复核时间与结果如何？

当发生安全事件或者版权纠纷时，依靠 AI‑SBOM 可以沿着链条回溯。例如出现漏洞，可以定位漏洞是来自大模型输出本身，还是来自 AI 自动引入的第三方依赖，或是后续人工修改引入。出现版权争议，可以调取 AI‑SBOM 留存的证据，追溯代码来源，区分 AI 原生输出和人类创造性改写部分。

溯源链条难点在于，代码文件经常混合 AI 生成与人工编写，同一个文件内部存在多段 AI 生成片段，需要片段级粒度记录，而不是整个文件简单标记 “文件由 AI 生成”。片段级溯源对工具链提出很高要求，也是当前技术落地难点。

5.4 AI‑SBOM 与传统 SBOM 关键差异对比

传统 SBOM 对象主要是编译后第三方组件，关注版本、许可证、漏洞；AI‑SBOM 对象包含源代码片段、大模型、提示词、人工操作记录，面向源代码阶段。传统 SBOM 主要用于上线后漏洞排查；AI‑SBOM 贯穿编码、代码提交、测试、发布全研发周期，兼顾安全溯源和版权证据留存。传统 SBOM 技术工具相对成熟；AI‑SBOM 工具尚处于早期，缺少通用标准化格式。

6 AI 生成代码版权归属的法律争议与现实困境

6.1 当前全球主要司法辖区对于 AI 生成作品版权的立法现状

不同国家地区对于纯 AI 生成作品版权立场并不统一。部分司法辖区认为，著作权保护人类创造性智力成果，完全由 AI 生成、无人类创造性投入的代码，不享有著作权。另一种观点认为，当人类给出提示词、筛选输出结果、进行大量人工修改，加入人类创造性劳动，则修改之后的成果可以获得著作权保护。

开源许可证体系同样面临挑战。很多开源协议约束代码衍生作品，如果 AI 模型训练吸收开源代码，AI 输出和开源代码高度近似，就会触发许可证传染性风险。目前全球还没有形成统一成文法规专门界定 AI 生成代码版权归属，大量问题依赖个案判例。

6.2 AI 生成代码版权争议核心矛盾点

第一，著作权主体矛盾：AI 模型本身不是法律主体，版权归属落在模型厂商、使用 AI 的程序员、企业用户三者之间，没有统一答案。
第二，训练数据版权传导：大模型训练使用海量开源代码，是否会将原代码版权约束传导至 AI 输出产物，法学界存在分歧。
第三，输出相似度问题：AI 输出代码片段和开源库片段高度重合，开发者本身不知情，无意识造成侵权。
第四，修改程度如何界定：多少人工修改量，才可以认定人类创造性贡献，目前没有量化标准。

6.3 大模型训练数据版权与输出代码版权传导风险

很多企业存在误区：只要自己付费使用公有大模型，AI 产出代码知识产权就全部归自己。该认知存在法律风险。模型训练数据集内大量开源代码，当输出片段与开源受保护代码实质性相似，即便是 AI 生成，企业使用该代码依然存在侵权风险。

版权风险具有隐蔽性，开发者肉眼难以分辨 AI 输出是否抄袭开源代码。等到软件分发、产品商业化之后，才遭遇知识产权诉讼。AI‑SBOM 在此处承担证据留存价值，记录 AI 原始输出、人工修改过程，作为版权纠纷发生时的证据材料。

6.4 企业实践中版权权属划分现实难题

企业在实际研发中，一段代码生命周期是：程序员输入提示词→大模型输出代码→程序员修改调整→合并进企业代码库。链条中混合多方贡献。企业需要在内部制度明确：AI 生成代码必须经过人工复核，留存提示词、原始输出、修改记录，作为权属证据。仅仅依靠大模型服务商用户协议，不足以完全规避版权风险。

7 AI‑SBOM 标准化全球推进现状

7.1 国际标准化组织相关工作进展

国际层面，NTIA 持续推进 SBOM 相关工作，针对 AI 场景发布研讨文档，探讨 AI‑SBOM 最小字段集。OWASP 发布 AI 软件安全相关指南，提出物料清单扩展建议。MITRE 开展 AI 安全框架研究，把 AI‑SBOM 纳入供应链安全控制项。

但是当前国际上尚未发布正式强制的 AI‑SBOM 国际标准，大多为报告、指南、草案。不同机构提出的字段集合不完全统一，格式不互通。产业界各方诉求存在分歧：闭源大模型厂商对于披露模型内部训练数据集信息存在抵触；软件安全厂商希望尽可能完整溯源；企业用户希望工具简单易用，不要带来过重研发负担。

7.2 国内软件供应链、人工智能安全标准建设动态

国内，传统 SBOM 相关国家标准已经开展研制，面向关键信息基础设施提出软件物料清单要求。生成式人工智能服务管理暂行办法对生成内容版权、安全提出要求。多家全国性标准化技术委员会启动 AI 供应链安全、AI 软件治理相关预研工作，AI‑SBOM 作为新概念进入国内标准研究视野。

现阶段国内以研究、研讨、团体标准草案为主，尚未出台强制落地的 AI‑SBOM 国标。国内产业实践更多集中在大型政企、安全企业试点，中小软件企业认知度整体偏低。

7.3 现有标准体系存在的缺口

第一，缺少统一 AI‑SBOM 数据格式规范，不同厂商输出物料清单无法互相解析。
第二，片段级溯源标准缺失：如何标记代码文件内部某一行、某一段来自 AI，没有统一技术规范。
第三，缺少 AI‑SBOM 最小必要字段集，哪些元数据是强制必填，哪些选填，没有共识。
第四，缺少与版权、人工复核流程联动的标准。现有标准大多只谈技术字段，没有配套业务流程规范。
第五，缺少对于公有云调用大模型场景的适配规范，公有模型基座细节掌握在服务商手中，调用方如何完成溯源记录，尚未形成方案。

7.4 产业各方对于 AI‑SBOM 的诉求差异

软件企业诉求：AI‑SBOM 不能过度增加研发成本，工具可以集成进现有 IDE、CI/CD 流水线，满足安全审计、知识产权留证需求。
安全机构诉求：尽可能完整溯源全部要素，保障安全事件发生时可追踪定位风险源头。
大模型厂商诉求：保护模型商业秘密，不强制披露训练数据集等核心商业信息，平衡溯源要求与知识产权保护。
监管机构诉求：形成可审计、可追溯证据链，落实软件供应链安全主体责任。

多方诉求存在冲突，这也是标准化推进缓慢的重要原因，标准制定需要寻找多方平衡点。

8 AI 生成软件合规的核心强制流程构建

结合 Veracode 安全数据、LiteLLM 事件教训以及 AI‑SBOM 理念，本章节提出企业层面可落地的强制流程框架，包含溯源管理、人工复核、依赖校验、版权归档、缺陷闭环。

8.1 AI 产出代码全生命周期溯源管理流程

从代码产生阶段即启动溯源。开发人员使用 AI 编码工具时，工具自动采集元数据：使用的 AI 工具版本、提示词、AI 原始输出。代码提交版本管理系统时，将 AI‑SBOM 片段元数据一并提交。每一次人工修改 AI 生成代码，记录修改人、修改时间、修改内容。软件发布时，整合片段级 AI 元数据与传统 SBOM，输出完整 AI‑SBOM 归档文件。

溯源数据不要求全部对外公开，主要用于企业内部审计、安全应急、版权纠纷举证。对于公有云大模型调用场景，企业无法获取模型训练数据集，需要如实记录外部调用的模型标识，把可获取信息完整归档，不可获取部分在 AI‑SBOM 中明确标注信息不可得。

8.2 AI 生成代码人工复核强制流程设计

Veracode 报告显示近半数 AI 生成代码存在缺陷，证明人工复核是不可省略的强制环节。复核不能只看功能是否跑通，复核分为安全复核、版权复核两个维度。

安全复核要点：检查输入输出校验、权限控制、加密逻辑、硬编码敏感信息、第三方依赖版本漏洞。
版权复核要点：比对 AI 输出是否与开源代码高度相似，评估许可证风险。

复核人员需要具备对应编程语言安全知识。复核完成留存复核记录，写入 AI‑SBOM，记录复核人、复核时间、复核结论：通过、修改后通过、直接拒绝不采用 AI 输出。未经复核的 AI 生成代码禁止合入生产分支。对于高安全等级软件，可设置双人复核机制。

8.3 第三方依赖包来源校验机制

针对 LiteLLM 类供应链攻击风险，企业需要建立针对 AI 生态组件的专项校验流程。AI 生成代码经常自动推荐引入依赖库，很多开发者不加审核直接安装。需要流程强制校验：依赖包来源镜像源、版本、哈希值、已知漏洞清单，禁止直接采纳 AI 推荐的未经校验依赖版本。AI‑SBOM 中区分普通业务依赖和 AI 推理、Agent 生态组件，针对后者提高安全检查等级。

8.4 版权权属归档与证据留存机制

将提示词、AI 原始输出、人工修改记录、复核记录统一归档，作为知识产权证据。明确内部制度：AI 生成代码不等于自动拥有完整知识产权，只有完成复核、修改、归档流程之后，才允许纳入企业自有软件资产。软件对外授权、交付、投标时，可基于 AI‑SBOM 材料开展知识产权自查。

8.5 安全缺陷闭环处置流程

借助 AI‑SBOM 溯源能力，当扫描发现 AI 生成代码漏洞，或者爆发供应链组件漏洞通告，可以快速定位受影响的代码片段，定位是 AI 原生输出漏洞，还是依赖包漏洞，还是后续人工修改引入漏洞，启动修复、版本回滚、风险评估闭环流程。

9 AI‑SBOM 产业落地现实障碍

9.1 技术层面障碍：大模型黑盒特性造成溯源困难

很多商用大模型是黑盒，使用者只调用 API，无法获取模型内部训练数据集细节。片段级代码溯源技术难度高，源代码文件中 AI 片段和人工代码交织，现有 IDE、代码管理工具原生不支持片段元数据存储。缺少成熟开源工具链生成解析 AI‑SBOM，大量工作需要人工补录，成本高，容易出错。

9.2 商业层面障碍：厂商闭源模型拒绝披露模型内部要素

商业大模型厂商出于保护商业资产，不会向调用方开放训练数据集、训练细节。造成 AI‑SBOM 部分字段无法获取。这里要区分：有些信息是企业作为调用方可以采集记录（提示词、输出文本、修改记录）；有些信息掌握在模型厂商一侧。完全全部要素溯源在闭源模型场景下很难实现，行业需要接受 “部分信息不可获取” 的现实，在标准中设计信息缺失标记字段。

9.3 组织流程障碍：研发团队缺少 AI 代码治理组织能力

大量软件企业研发流程没有针对 AI 编码做制度更新。开发人员习惯快速复制 AI 代码，没有溯源归档意识。引入 AI‑SBOM 会增加一部分研发工作量，如果缺少工具自动化支撑，全部依靠人工填写元数据，会遭到研发团队抵触。企业缺少专门岗位负责 AI 软件供应链合规。

9.4 法律标准障碍：版权、安全责任划分缺少明确法规依据

目前没有国内专门法律条文明确 AI 生成代码各方责任。当 AI 生成代码造成安全事故、版权侵权，模型厂商、使用 AI 的开发人员、软件企业之间责任如何划分，缺少清晰法律指引。AI‑SBOM 可以作为证据，但 AI‑SBOM 本身不直接免除法律责任。

10 面向产业的对策建议

10.1 技术层面：迭代完善 AI‑SBOM 技术规范与工具链

加快研究 AI‑SBOM 统一数据格式，定义必填字段与选填字段，区分公有模型调用场景、私有化部署模型场景，对于无法获取的模型内部信息设计明确标记字段。推进 IDE 插件、代码仓库、CI/CD 流水线原生支持片段级 AI 元数据采集，尽可能自动化生成 AI‑SBOM，降低人工操作负担。推动传统安全扫描工具兼容 AI‑SBOM，实现漏洞与 AI 溯源信息联动。开源社区开展 AI‑SBOM 工具原型建设。

10.2 企业层面：建立 AI 代码全生命周期内部合规体系

软件企业应当更新研发管理制度，把 AI 生成代码纳入管控范围。明确强制要求：AI 生成代码必须经过安全与版权人工复核，留存溯源证据，生成 AI‑SBOM 归档。区分不同安全等级项目，高安全等级系统收紧 AI 代码使用约束。对开发人员开展培训，纠正 “AI 输出代码天然安全无版权问题” 的错误认知。不盲目全盘拒绝 AI，而是实现可控使用。

10.3 产业层面：推动跨行业共建 AI‑SBOM 共享基准

产学研用联合，软件厂商、大模型厂商、安全企业、开源社区共同研讨 AI‑SBOM 最小基准，平衡溯源完整性与商业现实约束。针对 LiteLLM 这类 AI 生态开源组件，完善漏洞通报机制。推动行业试点，在关键软件项目先行实践 AI‑SBOM，沉淀落地案例，反哺标准制定。

10.4 政策标准层面：加快完善法律条文与强制标准建设

标准化组织加快推进 AI‑SBOM 团体标准、国家标准研制，明确元数据、格式、应用场景。立法层面持续研究 AI 生成代码著作权、安全责任划分规则。针对关键信息基础设施相关软件，逐步探索 AI‑SBOM 的合规要求，引导行业形成治理共识。

11 总结与展望

生成式 AI 重构软件开发生产力，同时带来安全缺陷、版权争议、软件供应链全新风险。Veracode 2026 年 8 月报告揭示近半数 AI 生成代码存在安全缺陷；LiteLLM 供应链攻击事件敲响警钟，传统软件供应链治理体系已经不足以应对 AI 时代挑战。

AI‑SBOM 作为新兴治理工具，在传统 SBOM 基础上扩展 AI 特有元数据，追求实现 AI 产出代码、依赖包完整溯源，固化人工复核流程，留存版权权属证据，正在成为软件合规新焦点。但 AI‑SBOM 标准化尚处在发展早期，面临大模型黑盒、工具链不足、多方诉求冲突、法律配套不完善多重现实障碍。

AI‑SBOM 不是万能解决方案，物料清单本身不能修复漏洞，不能直接解决版权纠纷，它的价值在于提供完整可追溯证据链，把隐性风险显性化。治理 AI 生成代码风险，需要技术工具、企业制度、产业标准、法律法规多方协同。

展望未来，随着标准化不断推进，AI‑SBOM 会逐步从前沿研究走向产业落地，融入软件研发全流程。行业需要在技术创新与安全合规之间寻找平衡点，在充分释放 AI 编码生产力的前提下，管控安全、版权、供应链风险，推动 AI 软件产业健康有序发展。

参考文献

[1] Veracode. 2026 年 8 月软件安全行业评估报告 [R]. 海外安全行业公开报告，2026.
[2] OWASP. Generative‑AI Security Guidance [R]. OWASP 基金会.
[3] MITRE. AI Supply Chain Framework [R]. MITRE 公司.
[4] 国家互联网信息办公室。生成式人工智能服务管理暂行办法 [S].2023.
[5] NTIA. AI‑SBOM Discussion Draft [R]. 美国国家电信和信息管理局.
[6] 全国信息安全标准化技术委员会。软件物料清单（SBOM）相关标准研究报告.
[7] 开源安全基金会. SBOM 实践指南 [R].
[8] 相关公开安全事件：LiteLLM 供应链投毒事件公开分析文档。