从辅助补全到默认生成
过去，AI编程工具更像自动补全；如今，它已进入IDE、代码评审和CI流程，参与函数、测试甚至架构片段的生成。到2026年，AI生成代码占比过半被视为一种趋势判断，而非精确预测。效率提升的同时，代码来源、责任归属和安全审查方式都在发生变化。
软件供应链的边界被改写
传统软件供应链关注开源组件、依赖版本、构建产物和分发渠道。AI生成代码则把模型、提示词、训练语料、微调数据和生成上下文带入链路。开发者可能只看到一段可运行代码，却难以判断它是否复制了受许可证约束的片段，或隐藏了过时API与逻辑缺陷。
风险不止漏洞，还有看不见的依赖
AI可能建议不存在的包名，攻击者可抢注同名恶意包，形成新的供应链投毒入口。它也可能生成硬编码密钥、弱加密、越权逻辑，或把训练数据中的敏感信息带入代码。更棘手的是，这些问题往往在评审中被“看起来能跑”所掩盖。
此外，模型版本更新、提示词变化和生成环境差异，会让同一需求产出不同代码。若缺少记录，事后审计和漏洞溯源都会变得困难。软件物料清单需要从组件级扩展到“AI代码来源级”。
谁来兜底：平台、企业与开发者共责
AI平台应提供生成溯源、内容签名、策略过滤和依赖可信提示，而不是只输出代码。企业需要把SCA、SAST、密钥扫描和许可证检查嵌入CI/CD，并对关键系统保留人工复核。开发者仍是最后一道防线，不能把安全责任完全交给模型。
- 平台侧：记录模型版本、生成时间与提示上下文，支持可追溯。
- 企业侧：建立AI代码准入规则，关键模块双人评审。
- 开发侧：对生成代码执行依赖验证、单元测试和安全扫描。
治理路径：把AI代码当第三方组件
最现实的思路，是不把AI生成代码视为“自己写的”，而当作外部引入的第三方组件。为每段重要生成代码建立来源记录，纳入SBOM和审计日志。CI中自动检查依赖真实性、许可证和已知漏洞，高风险变更触发人工门禁。
同时，安全团队需要更新威胁模型：除了传统依赖漏洞，还要覆盖提示注入、模型供应链和生成内容污染。监管与行业标准也应明确披露义务，让责任链条可验证。
结语：兜底不是单一角色
AI生成代码占比过半，并不意味着安全必然失守，但意味着旧流程不再够用。软件供应链安全没有唯一兜底者，平台、企业、开发者和标准组织必须共同承担。只有把安全能力嵌入生成、评审、构建和运行全流程，效率红利才不会变成系统性风险。
