Sonatype 最近的一份报告发现,AI 对开源项目的升级建议中,有 27% 是凭空捏造的;而 Veracode 的研究发现,在 100 多个不同的语言学习模型 (LLM) 的 80 项编码任务中,AI 在 45% 的项目中引入了安全漏洞。
Black Duck 最新发布的一项《2026 年开源安全与风险分析 (OSSRA) 报告》则揭示了与 AI 生成的代码相关的另一个紧迫问题:知识产权和许可风险。
报告分析了 947 个商业代码库,发现其中三分之二存在许可冲突——这是该报告发布以来的最高比例。这一比例较去年增长了 12%,也创下了该报告历史上增幅最大的纪录。
Black Duck 审计的一个代码库包含 2,675 个不同的许可冲突,表明知识产权管理的复杂性呈指数级增长。
该公司在一篇博文中解释道:“这种增长部分是由‘许可清洗(license laundering)’造成的,即 AI 助手生成源自反版权(例如GPL)源代码的代码片段,却不保留原始许可证信息。”
例如,报告显示,17%的开源组件通过复制粘贴代码片段、直接由供应商包含或 AI 生成的方式,在传统包管理器之外进入代码库。这带来了一个挑战,因为以这种方式进入的代码可能无法被传统的基于清单的扫描工具检测到。
![]()
今年的 OSSRA 报告还发现,代码中的漏洞平均数量比去年几乎翻了一番。87%的代码库至少存在一个漏洞,78%存在高风险漏洞,44%存在严重风险漏洞。
该公司解释说,在深入研究过程中,他们发现了一个“僵尸组件”问题。93% 的代码库包含两年内未进行任何开发的组件,92%的代码库包含至少四年未更新的组件,而正在使用的组件中只有 7%升级到了最新版本。
研究人员写道:“这些被弃用的组件就像一颗定时炸弹。当一个多年未更新的项目中发现漏洞时,往往已经没有维护人员来修复它。组织面临着艰难的选择:要么派生项目,要么重构应用程序,要么接受风险。”
Black Duck 总结认为,今年报告的一个关键结论是,AI 的应用与治理之间存在越来越大的差距。:“随着欧盟 AI 法案和网络弹性法案等监管框架带来的监管压力不断加大,‘交付即忘’的软件交付模式已不再可行。各组织必须转向持续供应链透明化的模式,在这种模式下,每个组件,无论是人工编写的、AI 生成的还是开源的,都必须纳入考量。”