AI 能修改程式碼、操作資料庫之後，軟件安全應由誰把關？

2026-10-24 13

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文剖析2026年多起AI时代典型安全事件（GitLab高危漏洞、LiteLLM供应链投毒、Railway密钥泄露、PocketOS AI删库），揭示自动化加速下传统安全防线的失效风险——从依赖管理、产物验证、密钥生成到AI Agent权限失控。强调：AI提效必须以SBOM追踪、构建一致性校验、最小权限隔离和操作审批机制为前提，安全边界须由工程体系而非模型可靠性来守护。

过去，开发人员担心的是代码写错了、接口出了 Bug、服务器扛不住流量。

现在，问题又多了一层：AI 能帮你写代码、找漏洞、发布应用，甚至直接调用接口修改生产环境。一旦它判断失误，事故可能在几秒钟内发生。

2026 年 10 月，多起软件安全事件接连出现。GitLab 披露了 CVSS 评分达到 10.0 的严重漏洞，AI 模型接入工具 LiteLLM 的发布产物遭到供应链投毒，云部署平台 Railway 发现客户环境变量可能被未经授权的第三方访问。

这些事件彼此独立，却指向同一个工程问题：当软件开发越来越自动化，原有的安全防线还能不能跟上？

一、一个开源组件出问题，可能牵连整条交付链
10 月 13 日，GitLab 公布了编号为 CVE-2026-97229 的严重漏洞，CVSS 评分为 10.0。在受影响的版本和特定条件下，攻击者可以通过构造恶意正则表达式，在 CI/CD 配置处理过程中触发远程代码执行。

GitLab 不只是代码仓库。很多企业还用它管理代码审查、自动化构建、测试执行和生产发布。

一旦这类平台被攻破，风险就可能从单个服务扩展到整个软件交付流程。

类似的问题也存在于其他基础组件中。Web 服务器、编程语言运行环境、数据库和第三方依赖，每一层都可能引入新的风险。

开发团队平时很难记住项目里的所有依赖关系。一个业务服务可能直接引用几十个库，再间接依赖数百个组件。等到某个底层漏洞公开，团队才开始排查哪些服务受到影响，往往需要花费不少时间。

因此，企业需要把软件物料清单（SBOM）、依赖版本、漏洞信息和实际部署环境关联起来。

发现漏洞之后，团队应该能够迅速回答三个问题：

哪些应用使用了受影响的组件？
当前版本是否满足漏洞的触发条件？
升级补丁后，哪些功能需要重新回归？
对测试开发人员来说，第三个问题尤其重要。安全补丁并不意味着业务一定没有回归风险，修复验证也需要进入正常的测试流程。

二、源码没有问题，为什么安装包还能带毒？
10 月 21 日，AI 模型接入工具 LiteLLM 遭遇发布供应链攻击。

根据 LiteLLM 官方安全通报，攻击者利用被盗用的开发者凭据，发布了包含恶意代码的 1.107.0 版本，并污染了部分 Docker 镜像。

这次事件有一个很值得工程团队注意的细节：官方 GitHub 上的对应源码标签没有包含恶意文件，问题出在实际发布的产物中。

这意味着，即使开发人员审查了源码，也不能直接认定最终安装包是安全的。

从源码到生产环境，中间还要经过构建、打包、签名、上传和部署。任何一个环节的权限被滥用，都可能改变最终交付的内容。

企业可以从几个方面补上这道防线：

固定依赖版本，避免生产环境自动拉取未经验证的新版本。
对安装包、容器镜像进行完整性校验，保留镜像摘要和构建记录。
限制发布账号的权限，关键发布操作设置审批机制。
对依赖升级和构建流程变更执行自动化安全检查。
对于测试团队，还可以增加一项验证：源码版本、构建记录和实际部署产物是否一致。

只测业务功能是不够的。交付物本身也应该是测试对象。

三、密钥泄露和弱随机数，可能让安全配置失去意义
10 月 21 日，云部署平台 Railway 发布安全公告，称未经授权的第三方可能访问客户的加密环境变量，并获取其中部分变量解密后的内容。

这些环境变量可能包含数据库密码、API Key 和私有镜像仓库凭据。Railway 建议用户轮换相关凭据，并检查服务日志中的异常活动。

另一起事件发生在证书体系。

印度证书机构 eMudhra 的八个中间 CA 证书被发现存在严重的密钥生成缺陷。安全研究人员 Scott Helme 从公开证书中恢复出了对应私钥，其中一个私钥的数值竟然是 4。

正常情况下，这类密钥应该具有极大的随机取值空间。密钥一旦过于简单，攻击者就可能恢复私钥，并利用它伪造相关证书。

需要说明的是，eMudhra 表示，受影响的中间 CA 均未签发终端实体证书，相关证书也已被撤销。这并不意味着所有 HTTPS 网站都受到了攻击。

这两起事件虽然机制不同，却都说明了一个实际问题：密钥是否安全，不仅取决于它有没有加密保存，还取决于生成、授权、使用和撤销的整个过程。

对于使用 AI 编程工具的团队，尤其要避免把生产密钥直接交给拥有广泛文件和系统访问权限的 Agent。测试任务通常不需要生产环境的完整凭据，能用临时密钥和最小权限解决的事情，就没有必要开放更大的权限。

四、AI Agent 做错一步，为什么可能直接删库？
2026 年 4 月，软件公司 PocketOS 曾发生一起由 AI 编程 Agent 引发的数据库事故。

据创始人公开描述，开发者使用 Cursor 中的 Claude Opus 4.6 处理测试环境的凭据问题时，Agent 调用了 Railway 的删除接口，删除了生产数据库及相关卷级备份。整个操作只用了约 9 秒。

开发者没有要求它删除生产数据。

问题在于，Agent 获得了能够影响生产资源的凭据，却没有在执行破坏性操作前充分确认目标环境和操作后果。

image
传统自动化脚本通常按照预先写好的步骤执行。AI Agent 则可能根据任务自行选择工具、组合操作，并连续调用多个接口。它的执行路径更灵活，但这也意味着权限控制不能只依赖提示词中的一句“不要删除数据”。

工程上需要增加明确的约束：

环境隔离：测试任务默认只能访问测试资源。
权限隔离： Agent 优先使用只读权限和短期凭据。
操作审批：删除数据库、修改权限、发布生产版本等操作需要人工确认。
备份隔离：备份不能与业务资源共享同一删除权限边界，并且需要定期验证恢复能力。
这些措施应该由系统权限、接口校验和基础设施配置共同实现，而不是寄希望于模型每次都能做出正确判断。

五、软件测试需要增加哪些检查？
当 AI 开始参与代码修改、测试执行和生产运维，测试团队需要把验证范围延伸到工具调用和权限边界。

可以从下面这套基础流程开始：

面向软件交付与 AI Agent 的安全验证流程
面向软件交付与 AI Agent 的安全验证流程
具体落地时，可以优先覆盖四类场景：

依赖安全：引入存在已知漏洞的依赖时，流水线能否识别并按策略阻断发布？
供应链安全：实际安装包与经过审核的源码、构建记录是否一致？
权限安全：使用测试环境凭据的 Agent，能否访问或修改生产数据？
异常操作： Agent 试图删除数据、修改权限或绕过审批时，系统能否拒绝执行？
这些用例既可以通过自动化脚本验证，也可以结合隔离环境开展安全测试。

尤其是第四类场景，不能只验证 Agent 能否完成任务，还要验证它在不应该执行时能否被系统拦截。

写在最后
这些安全事件并不能证明 AI 导致了所有漏洞。传统软件本身就积累了大量安全债务，依赖管理、密钥生成和权限配置也一直是工程难题。

变化在于，AI 正在加快代码生成、漏洞分析和系统操作的速度。一旦自动化系统获得了真实环境的执行权限，错误也可能更快地影响业务。

对于开发团队，代码写得快只是效率的一部分。依赖能否追踪、发布产物能否验证、权限能否限制、故障能否恢复，同样决定着软件能不能稳定交付。

AI 可以参与决策和执行，但生产环境的安全边界必须由工程机制守住。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。