最近很多 AI 生成 Dockerfile 时，都非常喜欢使用：

FROM node:latestFROM ubuntu:latestFROM python:latest

表面上看：

这只是一个“方便开发”的问题。

但实际上：

这已经开始变成一个典型的：

AI-Generated Infrastructure Security Risk

尤其是在：

• AI Coding Agent
• 自动化 DevOps
• AI CI/CD Workflow
• Agentic Infrastructure

逐渐进入生产环境后。

很多开发者开始默认：

“AI 生成的基础设施代码应该是可用且合理的。”

但现实是：

AI 在生成 Dockerfile、K8s YAML、Terraform、CI Workflow 时，

经常会优先选择：

“最容易生成”

而不是：

“最安全”

这会导致一种非常危险的问题：

AI 正在大规模复制“历史上的不安全默认配置”

而 latest tag，就是其中最典型的案例之一。

为什么 latest tag 有风险？

很多人会觉得：

FROM ubuntu:latest

只是“不够规范”。

但在真实生产环境里：

它可能导致：

• 不可预测构建
• 供应链漂移
• 镜像污染
• CI/CD 不可复现
• 自动升级引入漏洞
• 依赖链失控

本质上：

latest 不是版本

latest 是：

“动态指针”

而不是固定资产。

今天：

FROM node:latest

和明天执行：

FROM node:latest

得到的镜像可能完全不同。

这会导致什么问题？

1. Build Reproducibility（构建不可复现）

这是最直接的问题。

例如：

FROM python:latestRUN pip install -r requirements.txt

开发阶段没问题。

但三个月后：

CI/CD 重新构建时：

基础镜像可能已经：

• 更换 Debian 版本
• 更新 OpenSSL
• 升级 glibc
• 修改 PATH
• 引入新依赖

最终：

同一个 Dockerfile

构建出不同结果。

这在安全领域是非常严重的问题。

因为：

你失去了：

“可审计性”

2. 供应链攻击面扩大

这才是真正危险的地方。

很多企业现在：

• 自动 nightly rebuild
• 自动 Agent 修复
• 自动 Dependabot merge
• 自动生成容器
• 自动发布镜像

如果 AI 自动生成：

FROM something:latest

实际上等于：

企业把供应链控制权部分交给了外部 Registry

这意味着：

上游镜像一旦：

• 被污染
• 被劫持
• 被错误发布
• 引入高危依赖

下游所有自动化系统都会受到影响。

这和传统：

人为选择版本

已经完全不同。

现在的问题是：

AI 会持续自动生成这种危险模式。

AI Agent 会放大这个问题

传统开发中：

工程师通常会：

• review Dockerfile
• 固定版本
• 审计依赖

但在 Agentic Workflow 中：

AI 可能会：

生成 Dockerfile→ 自动 commit→ 自动 push→ 自动 CI/CD→ 自动部署

于是：

一个“不安全默认配置”

开始变成：

自动化传播的风险。

这也是 AI Agent Security 和传统 LLM Security 最大的区别之一：

AI 不再只是生成文本

而是：

开始参与基础设施生命周期。

一个现实中的危险场景

下面这个例子其实并不夸张。

很多 AI Coding Assistant 都会生成类似内容：

FROM node:latestWORKDIR /appCOPY . .RUN npm installCMD ["npm", "start"]

问题包括：

1. latest tag

不可预测。

2. npm install

不会固定 lockfile。

可能动态升级依赖。

3. COPY . .

可能把：

• .env
• SSH key
• build secret
• token

直接复制进镜像。

4. 默认 root 用户运行

容器权限扩大。

5. 没有 multi-stage build

攻击面扩大。

6. 没有镜像最小化

增加 CVE 暴露面。

单独看每个问题都不致命

但组合起来：

就是典型的：

Emergent Infrastructure Vulnerability

即：

每一个部分看起来都“还能用”

但组合后形成高风险系统。

这和现代 AI Agent 系统的问题非常类似。

也是为什么：

我认为未来 AI Security 的重点会逐渐从：

模型安全

转向：

AI 系统安全

AI 为什么会生成这些“不安全默认配置”？

因为：

AI 学习的是：

“互联网平均实践”

而不是：

“最佳安全实践”

而现实世界中：

GitHub 上大量公开 Dockerfile：

本身就存在：

• latest tag
• root user
• COPY .
• curl | bash
• apt upgrade
• 暴露 secrets

等问题。

于是：

模型会把这些模式视为：

“高频正确答案”

这其实是一个很重要的问题：

AI 会继承互联网历史技术债务。

更危险的问题：开发者会逐渐失去审查意识

这是目前很多人忽略的地方。

过去：

工程师知道：

Stack Overflow 的代码不一定安全

所以会 review。

但 AI 出现后：

很多人开始默认：

AI 生成 = 已经优化过

于是：

审查开始下降。

这会导致：

Infrastructure-as-Text

逐渐演变为：

Infrastructure-without-Review

这个风险真实吗？

是的。

但需要严谨表达。

目前：

还没有出现：

“因为 latest tag 导致全球 AI 灾难”

这种夸张事件。

但：

以下问题已经是现实：

• 不可复现构建
• 供应链漂移
• 自动化依赖污染
• CI/CD 不稳定
• 容器安全基线缺失
• AI-generated insecure IaC

这些已经在真实企业环境中大量存在。

因此：

更准确的说法应该是：

AI 正在放大历史基础设施安全问题，而不是凭空创造全新问题。

这一点非常重要。

Mitigation（缓解方案）

1. 固定镜像版本

不要：

FROM ubuntu:latest

而是：

FROM ubuntu:24.04

更进一步：

使用 digest pinning：

FROM ubuntu@sha256:xxxxx

2. 强制 AI 输出安全模板

例如：

• non-root user
• multi-stage build
• fixed version
• minimal image
• explicit COPY
• no secret inclusion

不要让 Agent 自由生成。

而是：

“约束生成”

3. AI Generated Code Review

重点不是：

AI 能不能写代码

而是：

AI 生成的基础设施代码是否经过安全审计

未来企业很可能会出现：

AI Code Security Gate

专门审计：

• Dockerfile
• Workflow YAML
• Terraform
• Helm Chart
• K8s Manifest

4. 不要让 Agent 直接拥有生产部署权限

这是未来非常关键的一点。

很多企业现在已经开始：

AI generate→ AI commit→ AI merge→ AI deploy

但：

AI Agent 的问题并不只是“代码漏洞”。

更大的问题是：自动化错误传播。

未来真正危险的，可能并不是：“AI 会不会毁灭世界”

而是：AI 会不会把历史上的不安全工程实践，以自动化方式大规模复制。

而这，很可能已经开始发生了。