文章总结： 生成式AI正从代码助手演变为软件供应链的自主参与者，能发起PR、修改依赖并触发CI/CD流程，传统人类监督机制因认知超载而失效。企业需重新定义治理模型，从管理访问权限转向控制AI行为权限，通过量化AI生成代码占比、权限范围等指标实现持续审计与风险控制。 综合评分： 78 文章分类： 供应链安全,安全建设,安全运营,应用安全
代码里的“特洛伊木马”：当AI接管开发，你的软件供应链还安全吗？
原创
Puneet Puneet
信息安全D1net
2026年5月8日 16:38 北京
在小说阅读器读本章
去阅读
点击上方“蓝色字体”，选择 “设为星标”
关键讯息，D1时间送达！
企业网D1net
生成式AI正在从“代码助手”进化为“软件参与者”：它能自主提交PR、修改依赖、触发CI/CD，甚至在无人干预下改变企业系统。问题已不再是效率，而是治理。传统“人在回路中”的安全机制正在失效，AI正成为拥有权限、可生成行为的新型机器身份，并带来前所未有的攻击面。真正的风险，不是AI写代码，而是企业仍在用“管理人”的方式管理AI。未来，CIO必须重新定义软件供应链治理：重点不再是谁能访问系统，而是AI被允许做什么，以及这些权限如何被持续控制与审计。
随着生成式AI工具演变为自主开发系统，企业必须重新思考如何管理这些系统在整个软件供应链中所行使的权限。
旨在辅助开发人员的AI工具不再甘居幕后，它们开始影响实际构建和部署的内容。
它们发起拉取请求(pull request)。
它们修改依赖项。
它们生成基础设施模板。
它们直接与代码仓库和持续集成/持续交付(CI/CD)流水线交互。
在某种程度上，这已不再是辅助。
它变成了参与。
而参与改变了问题的本质。
当辅助演变为参与
从生成式行为向自主式行为的转变是一个转折点。
早期的工具在一个紧密循环中运行，开发人员发出提示，系统给出建议，开发人员进行审查。没有人类的意图，任何操作都不会进行。
但这一界限正在逐渐模糊。
较新的系统能在有限的人工干预下提出变更、更新库、修复漏洞，并与开发流水线进行交互，它们不仅加速了开发人员的工作，还开始塑造在软件供应链中流转的产物——代码、依赖项、配置和基础设施定义。
这使它们变得与众不同。
不再是工具。
而是参与者。
一旦有事物参与到供应链中，它就会面临与其他参与者相同的问题：
如何对其进行管理?
一个简单场景
考虑一个在许多环境中已经出现的常见模式。
一个AI系统识别出一个存在漏洞的依赖项。
它发起一个拉取请求来更新该库。
一个工作流触发自动化测试。
该变更被推广到预发布环境。
四个步骤。
无需人工审查。
没有明确的治理检查点。
每一步单独来看都是合理的，单独看没有任何问题。
但综合起来，它们创造了一个本质不同的东西：一个无需在任何时候重新确立人类意图就能改变企业软件的系统。Black Duck的研究发现，虽然95%的企业现在在开发过程中使用AI，但只有24%的企业对AI生成的代码进行适当的安全和质量风险评估。
这是软件供应链中的自主变更传播。
“人在回路中”的谬误
许多组织依赖“人在回路中”(HITL)要求作为AI生成代码的安全机制。
在少量情况下，这可行。
但大规模应用时，这就行不通了。
当一个AI系统在短时间内生成数十个拉取请求时，审查就变成了一个吞吐量问题，而非控制问题，验证机器生成逻辑的认知负荷超出了人类实际能管理的范围。
剩下的不是监督，而是一个检查点。
而没有有效审查的检查点不是控制措施。
治理缺口
大多数治理模型都基于一个稳定的假设：人类是主要的行为者。
控制措施将身份与个人绑定，将审批与意图关联，将审计跟踪与问责制挂钩。
即使是自动化系统也被视为人类意图的延伸——可预测、有界限且确定性的。
AI系统打破了这一模型。
它们可以生成新的逻辑，据此采取行动，并在系统间传播变更，然而，在大多数环境中，它们仍被当作静态工具来管理。
这种不匹配就是缺口所在。
机器身份已今非昔比
清楚地看到这一点的一个方法是通过身份。
AI系统的每一次交互——代码仓库访问、流水线执行、API调用——都需要凭证。实际上，这些系统以机器身份运行。
但它们不是传统的机器身份。
服务账户执行预定义的逻辑，其行为事先已知，其风险受配置内容的限制。
AI驱动的系统则不同，它生成随后要执行的逻辑。
它可以提出新的代码路径，与新系统交互，并触发在授予访问权限时未明确定义的行动。
这是一种类别上的变化。
不仅是新的身份类型，还是新的攻击面：能够生成其被授权执行的行为的身份。
世界经济论坛已将这类非人类身份确定为企业采用AI过程中增长最快且治理最少的安全风险之一。
在解决问题前先衡量风险暴露程度
大多数组织已经在跟踪与访问相关的指标，这些指标是为人类驱动的系统设计的。
它们已不再足够。
如果AI系统参与到软件供应链中，企业需要衡量这种参与在何处以及如何引入风险。
有几个信号立即显得重要：
• AI生成产物足迹：生产环境中代码、依赖项或基础设施定义中有多少源自AI辅助流程?
• AI系统的权限范围：这些身份可以访问哪些系统，以及它们可以在代码仓库和流水线中采取哪些行动?
• 自主变更率：在没有明确人工审查的情况下，变更被引入和传播的频率有多高?
• 跨系统交互界面：在正常操作中，单个AI工作流会触及多少个系统?
• AI驱动行动的可审计性：能否清晰地将变更追溯到系统、工作流和触发上下文?
这些不是抽象的担忧，它们是可以衡量的。
而在未被衡量之前，它们就未被治理。
监管要求
这不仅仅是一次技术转变，它还是一次治理和责任转变。
随着监管期望的演变——从AI问责框架到网络安全披露要求——企业越来越有责任解释和控制其环境中的自动化决策。
如果AI驱动的变更引入了漏洞或导致了重大事件，“系统生成的”将不是一个可接受的答案。
责任仍将由企业承担。
这提高了标准：治理必须延伸到自主系统的行为方式，而不仅仅是它们的访问方式。
架构缺口
问题不在于缺少任何一个控制措施。
而在于AI系统在旨在在其自身边界内进行治理的系统之间的缝隙中运行。
代码仓库实施代码控制。
流水线实施部署控制。
身份系统实施访问控制。
安全工具实施策略检查。
每个系统都按设计运行。
但AI系统跨越了所有这些系统。
它们从一个系统读取数据，生成变更，触发另一个系统，并影响第三个系统。权限在系统间行使，而治理仍停留在系统内。
这就是架构缺口。
不同的治理模型
大多数组织将通过尝试扩展现有访问控制来应对这一转变，这种本能可以理解——但不够充分。
问题不再仅仅是谁或什么可以访问一个系统，而是当权限可以动态生成新行动时，如何维持控制。
这需要一种不同的治理模型。
一种将软件系统视为行为者，其行为必须在整个工作流中被界定、观察和持续评估的治理模型——而不仅仅是在访问点被允许或拒绝。治理不再那么关注静态权限，而更多地关注控制跨系统行动的形状和影响。
这就是转变所在。
结 论
围绕软件开发中AI的讨论往往聚焦于生产力。
但随着AI系统开始参与生成和修改企业软件，更重要的问题变成了治理。
AI不仅在加速软件开发生命周期，它正成为软件供应链本身的一部分。
而这改变了问题的本质。
对于CIO来说，挑战不再仅仅是管理开发人员、工具或流水线，而是理解和治理软件系统在这些方面所行使的权限。
因为在软件可以代表企业采取行动的世界里，治理不再仅仅是关于访问。
它是关于权限——系统被允许做什么，以及这种权限如何随时间被控制和衡量。
版权声明：本文为企业网D1net编译，转载需在文章开头注明出处为：企业网D1net，如果不注明出处，企业网D1net将保留追究其法律责任的权利。封面图片来源于摄图网
（来源：企业网D1net）
关于企业网D1net(www.d1net.com)
国内头部to B IT门户，同时在运营国内头部的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。旗下运营19个IT行业公众号(微信搜索D1net即可关注)
如果您在企业IT、网络、通信行业的某一领域工作，并希望分享观点，欢迎给企业网D1net投稿。
投稿邮箱：
[email protected]
合作电话：
010-58221588（北京公司）
021-51701588（上海公司）
合作邮箱：
[email protected]
企业网D1net旗下信众智是CIO（首席信息官）的专家库和智力输出及资源分享平台，有六万多CIO专家，也是目前较大的CIO社交平台。
信众智对接CIO为CIO服务，提供数字化升级转型方面的咨询、培训、需求对接等落地实战的服务。也是国内较早的toB共享经济平台。同时提供猎头，选型点评，IT部门业绩宣传等服务。
扫描 “二维码” 可以查看更多详情
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：信息安全D1net Puneet Puneet《代码里的“特洛伊木马”：当AI接管开发，你的软件供应链还安全吗？》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论