这种现象有了一个专门的名称:苦力转移(toil shift)。AI并没有真正消除工作,而是把工作从创建阶段转移到了验证、测试和修复阶段。Black Duck的总结一针见血:“大多数组织生产AI代码的速度,已经超过了他们审查、加固和治理这些代码的能力”
。
这里的“治理”并非繁文缛节。它指的是制定明确的政策,规定哪些工具可以使用、如何审查AI生成的代码、必须通过哪些安全门槛,以及谁为最终的代码输出负责。本质区别在于:“开发人员想用什么就用什么”,还是“开发人员在结构化、可审计的流水线中使用经过审批的工具”。
让治理更加复杂的是**影子AI(Shadow AI)**的兴起——开发人员违反或绕过公司政策使用AI工具。Black Duck发现,18%的组织报告影子AI是重大的未管理风险。当Cursor、Windsurf或Claude Code这类工具由开发者个人自行采纳,而未经过采购或安全审查,组织就失去了对自己攻击面的可见性
。
供应链层面的影响,是治理缺口转化为实际漏洞的地方。Black Duck的相关研究——包括其关联发布的《2026年开源安全与风险分析报告》——揭示了AI编程助手特有的三重连锁风险:
许可证洗白。 AI助手在开源代码库上训练,可以生成来自“著佐权”(copyleft)来源的代码片段,却不会保留原始许可证信息。2026年OSSRA报告发现,三分之二的受审计代码库存在许可证冲突——这是该报告历史上最高的比例
。组织可能在不知情的情况下,分发着他们没有权利使用的代码。
依赖爆炸。 每个代码库中的开源组件数量同比激增了30%,而平均漏洞数更是飙升了107%。AI编程助手加速了这一趋势,因为它们从更广泛的训练语料中更快速地组合解决方案——这意味着每个AI生成的函数都可能引入开发者并未显式选择的依赖。
Black Duck的发现并非孤证。同一时期发布的多项独立调查,用更细粒度的数据印证并扩展了这幅信任图景:
这些调查传达的共识出奇一致:开发者已经离不开AI工具,但也无法充分信任它们。代码生成与验证之间的鸿沟,已成为整个行业的全新瓶颈。
Black Duck给出的解决方案并非泛泛之谈。报告指出了将30%“治理优等生”与其余团队区分开来的一系列具体措施:
Black Duck的报告并不是反对使用AI编程助手。它的核心论点是:没有与之匹配的治理体系就贸然使用,是自我挫败。当97%的团队以前所未有的速度生成代码,却只有30%具备必要的监管基础架构时,整个行业正在集体开出自己兑现不了的支票。
治理与效率提升之间的强相关性——90%对44%——使商业逻辑变得无比清晰。那些先建好护栏的组织,才能真正把AI许诺的生产力纳入囊中。而那些跳过了这一步的团队,将反复发现一个苦涩的真相:省在键盘前的时间,全赔在了审查队列里。
Comments
0 comments