有关容器环境的一个常见问题是，如何保证只有授权过的镜像才能作为容器运行呢？各种产品和开发团队在这个问题上花了不少心思，想要把软件和配置的那一套标准应用到容器管理中。
在传统的IT环境中，有两个进程可以并行：一个是软件开发（dev.），另一个是软件运行环境的基础设施运营（ops.）。针对这两个进程，已经有成熟的安全控制措施。
上述两个过程独立进行，只有当新开发的软件安装到基础设施上之后，二者才有交集。最重要的是，如果基础设施配置出了问题，基本上会在安全控制和运营过程中得到妥善处理，很少会影响到软件开发。
为了保证代码安全，第一步并不是简单的将其过渡到容器应用中，之后的控制步骤需要根据容器化环境进行调整。
容器把所有的操作系统组件、必备组件和相关设置都嵌入到镜像当中。一旦镜像被建好和传输（ship），之后就不应该再有变动。运行状态的容器不允许调整配置、修补和替换组件。修改镜像内部环境的唯一方式就是重建新镜像。
这就是说，基础设施的安全方法唯一可以应用到的地方就是在镜像的创建过程中。因为一旦镜像完成部署，就没有改动的余地。
嵌入基础设施的安全控制在很大程度上，或者说是在根本上改变了创建流程。这种方式把当前的安全控制流程完全的转移了。
不用等到开发和一体化进程完成后再进行迭代评估、修补和配置调整，安全控制需要在第一时间进行，即在镜像创建之后，在进一步的CI/CD（持续集成和持续交付）过程之前。这就是“把安全控制挪到前面来”这句话表达的真正意思。
在此过程中，需要执行基础设施安全方针中的所有要素，这点非常重要，同时，还有一些针对容器镜像的方针：
理想情况下，这些方针与当前的物理、虚拟或者云上的主机中所应用的是对应的。例如，镜像不可接受的漏洞清单和评估服务器合规性的漏洞清单基本上是一样的。
很久以来，安全组织都在关注未授权的变更。跳转服务器、特权身份管理、管理日志、变更窗口以及根因分析，这些手段都是为了检测和防止对软件组件及其配置进行未授权的变更。对主机进行内部和外部双重连续漏洞评估，是为了能及时衡量IT基础设施中不可避免的变更。
容器化环境的实现看起来不太现实。它同时要求动态性和一致性。有了容器之后，主机不再是必须的，因为主机已经没有有效荷载或配置的意义了（容器引擎除外）。同时，对运行中的容器进行变更也不再是必须的，因为当编排或重新创建容器会覆盖掉这些变更。总之，以后再也不用进行传统意义上的变更了。
在需要进行变更的地方，只需要重新构建新的镜像来替代、增加或是修补想要改动的容器，使之切合预期。如果把安全控制引入这一过程并能够有效运作，之前觉得不可能的事情就会得以实现：在根本上创造了更多的安全应用，比以往更快更高效。
