夜雨聆风在分析了代码与依赖的集中度、开发者终端的信任碎片化之后，我们将目光移至SDLC中真正决定“杀伤半径”的两个环节——版本控制系统（VCS）和CI/CD流水线。在这里，漏洞本身的危害远不如“写权限”来得直接；自动化与AI进一步压缩了反应时间，让风险从单点渗透迅速演变为供应链级别的污染。
三、版本控制：不是代码仓库，而是信任引擎
3.1 公开暴露只是冰山一角，权限设计才是核心
版本控制系统（GitHub、GitLab、Bitbucket，以及国内的Gitee、CodeChina）记录了软件变更如何传播。仓库是否公开固然重要，但更关键的隐患是：一旦攻击者通过OAuth应用、GitHub App、泄露的令牌或被盗的开发者身份获得了访问权限，权限本身就会把“能看见”变成“能篡改”。
在Wiz的观测中，整体公开仓库暴露率约为2%（相对较低）。然而，从组织层面来看，大约54%的版本控制组织至少存在一个公开仓库。这意味着，多数企业多少都有一些代码处于可被外部审查的状态。但这远非最危险的情况——真正的高危场景出现在攻击者获得合法身份或集成权限之后。
3.2 写权限：供应链攻击的默认开关
版本控制系统中的决定性因素不是CVE编号，而是一个身份、集成或App是否具备写入权限。
写权限赋予了攻击者以下能力：
直接修改源代码：向仓库中注入后门、挖矿脚本或凭证窃取代码；
操纵审批路径：批准或关闭拉取请求，绕过人工审查；
修改工作流定义：更改GitHub Actions、GitLab CI的配置文件，让流水线在每次构建时执行恶意命令。
一旦写权限被滥用，妥协就不再依赖任何漏洞利用技巧——它变成由设计赋予的必然结果。
3.3 第三方集成：权限集中度再现“幂律”模式
GitHub Apps、OAuth应用常常请求大范围的权限。常见的高危作用域包括：
repo（完整仓库访问）pull_request（读写PR）workflow（修改流水线）administration（仓库设置）
研究显示，许多广泛安装的第三方应用默认请求写权限。而这些高影响作用域，恰恰集中在一小部分常用的工具上——这与代码依赖中的“少数核心包承载多数风险”如出一辙。例如，用于自动化测试的某款热门前端工具、用于依赖更新的某款机器人，一旦这些App被入侵，攻击者便能通过它们获得所有关联仓库的写权限。
3.4 AI加速了变更传播，但未改变权限模型
AI辅助开发并不会改变VCS底层的信任机制，但它显著加快了变更速度。至少71%的组织已经拥有AI编程助手，这些工具越来越多地直接生成PR内容、自动修复建议、甚至自动提交代码。当AI生成的拉取请求继承了当前身份的写权限，自动化 + 写权限的组合可能压缩人工审查的时间窗口，使得一个带着风险变更的代码块在团队反应过来之前就已合并并进入流水线。
这并非AI“制造”新风险，而是AI放大了权限模型中原有的弱点。如果写权限过度授予，AI不过是一个更快、更不知疲倦的恶意代码提交者。
3.5 中国企业的本土化实践
在国内版本控制场景下，以下几点值得注意：
Gitee企业版与私有部署：多数国内企业使用私有化部署的GitLab或Gitee。应重点审计第三方应用授权清单——特别是那些请求了
write作用的CI集成、代码审查机器人、IDE插件。定期运行“最小权限复查”，移除不再使用或请求权限过大的应用。内部开源与跨项目依赖：许多大型企业推行内部开源（Inner Source），一个团队的仓库可能被数十个其他服务通过个人访问令牌（PAT）拉取。应建立令牌生命周期管理，强制使用短期令牌或OAuth代理，避免长期有效的PAT散落在各个构建脚本中。
AI提交的审查适配：对于使用AI生成PR的团队，应在Git服务器端配置规则：AI账号提交的PR必须经过至少一名人类审核者批准，且不得跳过某些高危目录（如
.github/workflows）的强制审查。
版本控制的本质是信任决策转化为软件分发。宽泛的写权限、长期存在的集成授权、极少被重新审视的App作用域，使得供应链影响成为妥协的默认结果，而不是边缘案例。安全团队应把写权限视为高危能力，持续重验证哪些身份和App可以修改代码或工作流，并且在权限和复用最为集中的地方优先治理。
四、CI/CD流水线：当自动化成为攻击者的高速公路
4.1 设计使然：执行、自动化、凭证三位一体
持续集成与持续交付平台是SDLC中权限密度最高的系统之一。它们的核心职责就是自动执行代码、编排构建过程、将产物推送到生产环境。正因为它们携带可信身份和自动化特权，CI/CD平台通常继承了源代码仓库的访问权限、云服务商的长期凭证、以及部署基础设施的API权限。
从攻击者的视角看，CI/CD流水线就是一条从“开发侧”通向“生产侧”的高速公路。只要在流水线中获得一次执行机会，后续的横向移动和权限提升往往只需要跟随既有的信任关系。
4.2 CI/CD普及率极高
在Wiz观测的企业中，45%～50%的组织启用了GitHub Actions。考虑到还有大量组织使用GitLab CI、Jenkins、CircleCI、阿里云云效、腾讯云CODING等，可以认为CI/CD已是现代软件交付的标准组件。
这样高的普及率意味着，每一次提交、每一个PR、每一次标签推送，都可能触发一个具有生产级权限的自动化作业。表面上微小的配置决策，会带来广泛的操作性影响。
4.3 工作流配置错误：可靠且常见的攻击路径
Wiz的研究发现，大量CI/CD工作流包含以下高风险模式：
权限限制缺失：未明确设置
permissions字段，导致作业默认继承GITHUB_TOKEN的写权限；未固定第三方Action版本：使用
actions/checkout@v2（v2是可变标签）而非actions/checkout@5a4ac90（具体SHA），可能被重定向至恶意版本；工作流请求了写权限：例如对仓库内容或PR的写权限，而这些权限对于只读构建任务完全是多余的。
单独看，每个问题似乎都不致命。但组合在一起——一个拥有写权限、使用未固定Action、且能通过PR触发的工作流——攻击者只需提交一个恶意PR，就能让工作流在其环境下执行任意代码，进而窃取令牌、修改仓库、甚至向产物中注入后门。
4.4 第三方Action的风险集中
对GitHub Actions工作流的SBOM分析显示，绝大多数组织都在使用同一小套可复用Action。actions/checkout出现在几乎所有环境中；actions/setup-node出现在约78%的组织；actions/setup-python和actions/cache也超过60%。这种高度集中的复用，意味着如果某个流行Action（例如actions/checkout）出现投毒版本，后果将是灾难性的。
国内使用阿里云云效、CODING的企业，同样存在类似“官方插件”和“社区任务插件”的复用集中现象。建议企业建立内部Action/Task的允许列表，并强制使用摘要锁定（SHA256）而非版本标签。
4.5 Runner的访问权限：自托管Runner尤为危险
CI/CD Runner的执行环境通常持有大量特权。在Wiz观测的Shai-Hulud攻击活动中，GitHub Actions是占比最高的CI/CD平台（59%），其中自托管Runner约占三分之一。
被攻陷的Runner中经常可以发现：
云服务商长期凭证（AK/SK）
源代码仓库访问令牌
构建工具链（可编译恶意代码）
出站网络访问（可外发数据）
托管Runner（GitHub托管、云效托管）是临时性的，运行在提供商的基础设施内，攻击者难以持久化；但自托管Runner运行在企业自己的环境内（如Kubernetes集群、ECS或物理机），一旦被攻破，攻击者可以横向移动到内网其他系统。
4.6 自动化抹平了开发与生产的边界
一旦在CI/CD流水线中获得执行，开发基础设施与生产环境之间的隔离就形同虚设。构建系统通常负责：
部署基础设施（Terraform、Pulumi）
推送容器镜像到注册表
调用云API创建资源
更新配置文件和存储桶
当这些工作流在受损的条件下执行，自动化可以迅速将恶意变更推送到下游环境。攻击者不需要再去寻找生产环境的入口——流水线自己就把大门打开了。
4.7 对策：将CI/CD视作关键安全基础设施
CI/CD平台是开发侧到生产侧最短的路径。它们组合了远程执行、自动化编排和凭证访问，且规模覆盖全组织。如果仅仅把CI/CD当作“构建便利工具”，而非“特权执行环境”，那么几个微小的配置缺陷就有可能酿成重大入侵事件。
有效的防御需要做到：
持续审计工作流权限：所有工作流应遵循最小权限原则，明确声明
permissions，并避免使用write-all。锁定第三方Action/Task：使用完整的SHA256摘要固定版本，定期更新但需经过审查。国内平台若支持，应启用“只允许使用内部审批通过的插件”。
Runner隔离：自托管Runner应运行在专用、不可变、网络隔离的环境中，禁止挂载宿主机敏感目录；使用临时凭证，并在作业结束后立即撤销。
流水线扫描：在PR触发流水线时，额外增加一层安全检查（如代码静态分析、密钥扫描），并对来自fork的PR禁用某些高危操作。
五、AI作为加速器：放大既有弱点，而非引入全新范式
整份报告贯穿始终的基调是：AI并非颠覆了SDLC安全的底层逻辑，而是极大地加速了既有弱点的传播与放大。
代码层面：AI生成的代码更多、更快，也更容易携带不安全模式。如果团队依赖AI自动补全而不辅以静态分析，那么不安全代码会被大量“印刷”进代码库。
密钥泄露：AI开发工作流（Notebook、自动API集成）频繁涉及密钥操作，且AI助手有时会“好心”地帮开发者把密钥填入配置文件。
权限滥用：AI提交的PR、AI触发的流水线动作继承了底层身份的写权限，压缩了人工审查的时间窗。
攻击自动化：攻击者也可以利用AI自动扫描公开仓库中的泄露密钥、自动构造针对CI/CD配置错误的利用链。
报告中提到的“Moltbook暴露事件”便生动说明了这一动态：AI生成的开发模式（自动保存环境变量、自动上传日志）无意间导致了数百万API密钥的泄露。这不是AI的“过错”，而是AI将人类开发者原有的不良习惯规模化、自动化了。
对中国企业而言，这意味着不能仅仅在“使用AI”和“禁止AI”之间二选一。正确的路径是：在使用AI提升效率的同时，加固AI所依赖的底层信任路径。包括但不限于：
对AI生成的代码进行强制静态分析和人工抽查，设置代码质量门禁；
对AI IDE扩展实施权限管控，禁止其读取非项目目录或外发数据；
在版本控制系统中，为AI代理账号设置只读或受限写权限，并强制双人审查。
六、结论：从追漏洞到管信任
回顾整个SDLC——从源代码依赖，到开发者终端，到版本控制，再到CI/CD流水线——一个相同的结构模式反复出现：
风险主要通过集中度、权限继承和自动化来放大，而非通过新颖的漏洞或高级的利用技术。
在源代码和依赖层面，流行的语言、框架和包创造了效率，也集中了风险。当弱点出现在横跨数千组织的组件中，小问题迅速演变为跨环境的暴露事件。
在开发者终端层面，底层的标准化与扩展层的碎片化形成了矛盾。AI助手的嵌入进一步增加了可信执行路径的数量。
在版本控制层面，写权限的宽泛授予使得供应链影响成为妥协的默认结果。
在CI/CD层面，自动化系统连接了开发环境与生产基础设施，一次构建环境的入侵可瞬间转化为生产环境的失陷。
对于安全建设者而言，启示是明确的：现代应用安全无法仅靠寻找单个漏洞或提升告警数量来解决。有效防御需要理解信任在整个软件开发生命周期中如何流动，以及那些在权限和自动化上集中了风险的节点。
那些把代码、开发工具、版本控制、CI/CD视为独立安全域的组织，注定会疲于奔命地追逐症状。而那些能够分析这些系统之间如何交互、以及特权与自动化在何处集中风险的组织，将更有希望在不拖慢创新的前提下，降低系统性暴露。
应用程序安全的未来，不在于产生更多的“发现”，而在于更清晰地理解：在那些构建、信任和交付软件的系统里，究竟哪些弱点才是真正重要的。
