有关容器环境的一个常见问题是，如何保证只有授权过的镜像才能作为容器运行呢？各种产品和开发团队在这个问题上花了不少心思，想要把软件和配置的那一套标准应用到容器管理中。
在传统的IT环境中，有两个进程可以并行：一个是软件开发（dev.），另一个是软件运行环境的基础设施运营（ops.）。针对这两个进程，已经有成熟的安全控制措施。
上述两个过程独立进行，只有当新开发的软件安装到基础设施上之后，二者才有交集。最重要的是，如果基础设施配置出了问题，基本上会在安全控制和运营过程中得到妥善处理，很少会影响到软件开发。
为了保证代码安全，第一步并不是简单的将其过渡到容器应用中，之后的控制步骤需要根据容器化环境进行调整。
容器把所有的操作系统组件、必备组件和相关设置都嵌入到镜像当中。一旦镜像被建好和传输（ship），之后就不应该再有变动。运行状态的容器不允许调整配置、修补和替换组件。修改镜像内部环境的唯一方式就是重建新镜像。
这就是说，基础设施的安全方法唯一可以应用到的地方就是在镜像的创建过程中。因为一旦镜像完成部署，就没有改动的余地。
嵌入基础设施的安全控制在很大程度上，或者说是在根本上改变了创建流程。这种方式把当前的安全控制流程完全的转移了。
不用等到开发和一体化进程完成后再进行迭代评估、修补和配置调整，安全控制需要在第一时间进行，即在镜像创建之后，在进一步的CI/CD（持续集成和持续交付）过程之前。这就是“把安全控制挪到前面来”这句话表达的真正意思。
在此过程中，需要执行基础设施安全方针中的所有要素，这点非常重要，同时，还有一些针对容器镜像的方针：
