容器镜像的风险同样不容忽视，容器镜像通过镜像仓库的自动化、层级化管理大大降低了容器使用的难度，开发者在方便使用的同时也要重视可能发生的安全问题。镜像的风险一般来自于不可靠的镜像来源，镜像构建时引入的不安全第三方组件，及包括官方镜像在内的镜像自身存在的漏洞等。通常软件项目中会使用大量开源软件，按照以往的经验，官方提供下载的软件一般是最新且安全可靠的。但2015年一份研究报告显示，Docker公共仓库（Docker Hub）中超过30%的官方镜像包含高危漏洞，而2021年全年公开的通用漏洞披露（CVE）漏洞数为20139个，其中高危漏洞数高达4064个。漏洞镜像主要集中在种类繁多的应用程序中间件的镜像中。镜像的风险必然导致容器运行的风险。
2.2 容器编排平台的风险
云原生的焦点是业务服务，业务服务核心是对服务的管理和控制，如服务暴露、负载均衡、流量感知、应用扩容、灰度发布、应用更新等。服务编排提供了分布式的计算、存储和网络资源的管理功能，实现了按需、弹性地控制服务的位置、容量、版本，监控并保证业务的可访问性。
事实上，编排系统与容器之间并非完全独立。以当前最流行的云原生管理与编排系统Kubernetes（K8s）为例，K8s集群本身的API服务管理器（API Server）、控制器（Controller Manager）、调度器（Scheduler）、基本域名解析服务器（CoreDNS）等服务端组件和K8s网络代理（Kube-proxy）、K8s节点代理服务（Kubelet）等客户端组件均以宿主机的一个或多个进程形式运行，而集群使用YAML语言以声明形式创建的K8s最小部署单元（Pod）实际是同一网络命名空间下的多个容器组成的逻辑组，因此K8s并不能降低由其管理的容器环境本身已存在的安全风险。另外，多节点组成的K8s集群使用第三方网络插件提供节点间通信的机制，也使集群网络的风险比单宿主机运行容器的网络风险更大。
除此之外，K8s内部核心组件如API Server设置了便于测试环境或者集群初启动时使用的未加密端口8080，Kubelet和分布式键值对存储系统（Etcd）可以通过改变启动参数配置使用匿名访问功能，以及用于集群访问控制的认证、授权和准入机制设置过于宽松，高权限账号滥用等配置、操作、管理性问题同样威胁着云原生环境的安全，不安全的配置暴露于网络中将给云安全带来严重的风险。
2.3 云原生网络的风险
不同于网络位置有明确划分、具有单一网络连接关系的传统IT应用，云原生应用采用网络虚拟化的部署方式，实际上是对网络边界进行了重新定义。例如，Docker容器在网络命名空间隔离下，一般通过虚拟以太网（Veth）设备对、网桥等虚拟设备采用动态地址映射方式与外界通信；K8s则以Pod为单位，Pod内部的所有容器共享一个网络堆栈，不同Pod之间以非网络地址转换（NAT）的方式互相通信，即“每个Pod分配一个IP（IP-per-Pod）”模型。从宏观上看，集群中的网络空间、包过滤防火墙（Iptables）和路由随着容器的产生、消亡不断动态变化，分布式容器集群网络的复杂度大大提升，这必然会引入新的网络风险。
每个容器虽然与宿主机之间存在隔离，但一般情况下同一宿主机上的容器位于同一局域网，网络互通。如果攻击者非法获取局域网内一个容器的权限，就有可能与其他容器非法通信，发生容器间的网络攻击（东西向攻击）。
K8s实现了容器的分布式集群部署，集群Pod间可互相通信。在没有其他网络隔离策略和Pod安全策略的情况下，可能存在网络探测、拒绝服务和中间人攻击等网络攻击（南北向攻击）。
2.4 云原生应用的风险
云原生应用采用微服务架构、前后端分离的模式设计，交互方式从传统的Web请求/响应转向为各类API请求/响应，使用方式逐渐由“人-机交互”转变为“机-机交互”，通过表述性状态转移风格的超文本传输协议（RESTful/Http）、二进制/跨语言的远程过程调用（gRPC）等方式进行通信，App服务的数量和API请求量大大增加。新模式在带来高弹性、可扩展、可移植性优势的同时，也在安全方面有了新变化。
传统的以Web为主的应用风险依然存在，如注入、跨站脚本、敏感数据泄露、使用有漏洞的第三方组件等。当传统的单体应用拆分为多个服务后，前端的单一请求在后端可能有数以千计的服务调用关系，复杂的调用链和分布式问题更容易在外部访问急剧增加时，大量占用甚至耗尽CPU资源，从而造成拒绝服务风险。
相较于作为一个整体对用户进行授权、访问单一的传统IT应用，微服务应用的所有服务间需互相认证授权，请求来源除了用户侧外，还有大量内部或其他服务API调用，其认证授权更为复杂。若某些API或微服务之间的鉴权或访问权限配置错误，就有可能造成数据非法访问、非法操作等问题。同时，应用的配置数量与服务数量成正比，微服务数量的增加导致各种服务、证书、数据访问、环境变量等配置增加，且生产环境中要求实现的动态调整对服务的配置管理、密钥管理也提出更高的要求。复杂度和管理难度的上升，增加了数据泄露风险。