数治长文 | 五大路径尽览云原生安全威胁全景

全面分析云原生关键技术的威胁，形成云原生关键技术的威胁全景图和攻击路径图，能够帮助企业构建更完善的云原生安全防护体系，从而更全面的保障云网环境的安全。

随着云原生技术的广泛应用，容器化基础设施、容器编排平台以及云原生应用等都面临着多种多样的新型安全威胁，这些威胁直接或间接影响着云网环境的整体安全。因此，全面分析云原生关键技术的威胁，形成云原生关键技术的威胁全景图和攻击路径图，能够帮助企业构建更完善的云原生安全防护体系，从而更全面的保障云网环境的安全。

云原生化的应用主要由两个部分组成，一是支撑应用的云原生计算环境，包括容器、镜像、镜像仓库、网络和编排系统等。二是云原生化的应用本身，主要包括微服务、Serverless。图 1 中攻击路径 1 至攻击路径 5，从攻击者角度展示云原生应用关键技术面临的安全威胁。

图 1 云原生关键技术威胁全景

路径 1：攻击者通过攻击镜像层，改变云原生应用的不可变基础设施，引导受害者使用该镜像创建容器，进而实现入侵容器、宿主机的目的。路径 1 显示针对镜像层可能存在的攻击手段，包括：镜像投毒攻击、镜像仓库攻击、中间人攻击、敏感信息泄露攻击和针对镜像不安全配置的攻击。
路径 2：攻击者直接对容器或容器运行时发起攻击，通过利用容器或容器运行时存在的漏洞，实现入侵宿主机的目的。其中低级容器运行时负责创建和运行容器，而高级容器运行时负责容器镜像额传输和管理等，低级容器运行时和高级容器运行时只是强调了容器化的不同方面。路径 2 显示针对容器运行时可能存在的攻击手段，包括：容器运行时攻击、容器提权和逃逸攻击、拒绝服务攻击和容器网络攻击。
路径 3：攻击者对编排工具发起攻击，通过利用编排工具存在的漏洞，实现入侵宿主机的目的。路径 3 显示针对编排工具可能存在的攻击手段，包括：攻击 k8s 组件、服务对外暴露攻击、业务 pod 攻击、集群环境下的横向攻击、k8s 管理平台攻击和第三方组件攻击
路径 4：攻击者针对微服务发起攻击，如通过利用存在安全风险的 API 网关、 API 以及微服务应用本身，实现入侵的目的等。路径 4 显示针对微服务可能存在的攻击手段，包括：API 攻击、API 网关攻击和微服务应用攻击。
路径 5：针对 Serverless 发起攻击，无服务器架构颠覆性的变化，给应用服务开发商和拥有者带来了全新的安全挑战。路径 5 显示了攻击者利用Serverless 存在的安全风险进行攻击的路径，可能存在的攻击手段包括：事件注入攻击、敏感数据泄露攻击、身份认证攻击、权限滥用攻击、拒绝服务攻击和针对函数供应链的攻击。

下面我们对威胁全景中攻击路径 1 至路径 5 的具体攻击手段，进行详细的分析。

1. 镜像攻击

镜像是一个包含应用/服务运行所必需的操作系统和应用文件的集合，用于创建一个或多个容器，容器和镜像之间紧密联系，镜像的安全性将会影响容器安全。图 2 展示了攻击者利用镜像进行攻击的主要方式。

1.1 镜像投毒攻击

图 2 容器镜像安全风险

攻击者通过上传恶意镜像到公开仓库或受害者本地仓库，然后将恶意镜像伪装成正常镜像以引导受害者使用该镜像创建容器，从而实现入侵。根据入侵目的的不同，可以分为恶意后门镜像和恶意 EXP 镜像。

恶意后门镜像攻击者的目的是为了控制容器，一般是在受害者使用镜像启动容器后，就会向攻击者反弹一个容器的 shell。这种情况下攻击者可能是为了部署挖矿程序或者攻击容器内运行的业务。恶意 EXP 镜像攻击者的目的是利用隐藏在其中的 Exploit 进行容器逃逸，然后获得宿主机的控制权。

1.2 镜像仓库攻击

这里指的是攻击受害者本地的镜像仓库，如 Harbor[8]、Docker Registry[9]等。其中 Harbor 镜像库从发布开始就被爆出权限提升、枚举、SQL 注入、CSRF等多项漏洞。除此之外，如果私有镜像仓库由于配置不当而开启了 2357 端口，将会导致私有仓库暴露在公网中，攻击者可直接访问私有仓库并篡改镜像内容，造成仓库内镜像的安全隐患。

1.3 中间人攻击

如何保证容器镜像从镜像仓库到用户端的完整性也是镜像面临的一个重要安全问题。由于用户以明文形式拉取镜像，如果用户在与镜像仓库交互的过程中遭遇了中间人攻击，导致拉取的镜像在传输过程中被篡改或被冒名发布恶意镜像，会造成镜像仓库和用户双方的安全风险。

1.4 敏感信息泄露攻击

当开发人员使用默认的或在容器镜像中保留硬编码的敏感数据，比如密码、API 密钥、加密密钥、SSH 密钥、令牌等，或者在 Dockerfile 文件中存储了固定密码等敏感信息并对外进行发布，都可能导致数据泄露的风险。攻击者会使用扫描工具，比如 SecretScanner 等，探测镜像中存在的敏感信息，发现容器镜像和文件系统中的敏感数据。

1.5 针对镜像不安全配置的攻击

镜像是容器运行的基础，容器引擎服务通过使用不同的镜像来启动容器。镜像是按层封装好的文件系统和描述镜像的元数据构成的文件系统包，包含应用所需要的系统、环境、配置和应用本身。如果镜像配置不当，将会导致运行的容器面临攻击的危险，比如镜像未使用特定用户账号进行配置导致运行时拥有的权限过高，从而引起容器逃逸等安全风险。

2. 容器攻击

容器提供了独立隔离的环境来打包和运行应用程序，容器的隔离和安全措施使得用户可以在给定主机上同时运行多个容器。通过 Namespace、Cgroup、 Capability、内核强访问控制等多种安全机制以及隔离措施，保证容器内应用程序的安全与隔离。图 3 展示了攻击者可能利用的直接对容器进行攻击的方式。

2.1 守护进程攻击

图 3 容器运行时安全风险

Docker Daemon 是 Docker 架构中一个常驻后台的 Docker 守护进程，用于监听 REST API 请求并相应地执行容器操作，只有信任的用户才能向 Docker Daemon 发起请求。默认情况下，对于 Docker Daemon 的访问请求未经加密和身份验证，攻击者可能通过伪造请求的方式，来达到欺骗 Docker Daemon 端执行危险的操作。

除此之外，攻击者可以通过暴露在互联网端且不安全的 Docker Daemon，获得 Docker 平台的完全控制权，进而再部署“挖矿”或其他恶意容器。由于 Docker Daemon 作为主机上的根进程运行，攻击者还可能获得主机的完全控制权。

2.2 容器提权和逃逸攻击

攻击者通过劫持容器，获得了容器内某种权限下的命令执行能力，然后利用这种命令执行能力，借助一些手段进一步获得该容器所在宿主机上某种权限下的命令执行能力，实现容器逃逸的目的。根据不同的原因，容器逃逸方式包括以下几方面：

内核漏洞导致的容器逃逸：容器本身是一种受到各种安全机制约束的进程，因此从攻击角度来看，攻击者通过权限提升达到逃逸的目的，一旦有新的内核漏洞产生，就需要考虑它是否能够用于容器逃逸。
危险配置导致的容器逃逸：Docker 容器基于 Linux 内核中的 Capabilities 特性划分特权集，以便进程可以只分配“执行特定功能”的特权，例如通过使用privileged 参数获得所有特权集，使用 cap-add 和 cap-drop 参数增减特权集。然而，无论是细粒度权限控制还是其他安全机制，用户都可以通过修改容器环境配置或在运行容器时指定参数来缩小或扩大约束。如果用户为不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的逃逸可能性。

需要特别强调的是，当用户通过 Privileged 参数运行特权容器时，容器将具备访问宿主机资源的权限，同时可以修改 AppArmor 或 SELinux 的配置。该场景下，攻击者可以通过多种手段实现容器逃逸，例如可以直接在容器内部挂载宿主机磁盘，然后通过切换目录实现容器逃逸。

危险挂载导致的容器逃逸：为了方便宿主机与容器进行数据交换，用户往往会采用将宿主机目录挂载到容器中，将宿主机上的敏感文件或目录挂载到容器内部，将会导致容器逃逸风险。例如 Docker Socket 套接字文件（/var/run/docker.sock）、宿主机的 procfs 文件等敏感文件。
程序漏洞导致的容器逃逸：参与到容器生态中的服务端、客户端程序自身存在的漏洞都可能导致容器逃逸的风险，例如 CVE-2019-5736 漏洞。

2.3 拒绝服务攻击

由于容器与宿主机共享 CPU、内存、磁盘空间等硬件资源，且 Docker 本身对容器使用的资源并没有默认限制，如果单个容器耗尽宿主机的计算资源或存储资源（例如进程数量、存储空间等），就可能导致宿主机或其他容器的拒绝服务。

计算型 DoS 攻击：Fork Bomb 是一类典型的针对计算资源的拒绝服务攻击手段，其可通过递归方式无限循环调用 fork()系统函数，从而快速创建大量进程。由于宿主机操作系统内核支持的进程总数有限，如果某个容器遭到了 Fork Bomb 攻击，那么就有可能存在由于短时间内在该容器内创建过多进程而耗尽宿主机进程资源的情况，宿主机及其他容器就无法再创建新的进程。
存储型 DoS 攻击：针对存储资源，虽然 Docker 通过 Mount 命名空间实现了文件系统的隔离，但 CGroups 并没有针对 AUFS 文件系统进行单个容器的存储资源限制，因此采用 AUFS 作为存储驱动具有一定的安全风险。如果宿主机上的某个容器向 AUFS 文件系统中不断地进行写文件操作，则可能会导致宿主机存储设备空间不足，无法再满足其自身及其他容器的数据存储需求。

2.4 容器网络攻击

Docker 提供桥接网络、MacVLAN、Overlay 等多种组网模式，可分别实现同一宿主机内容器互联、跨宿主机容器互联、容器集群网络等功能。由于容器间的网络缺乏安全管理机制，无法对同一宿主机内各容器之间的网络访问权限进行限制。因此，无法避免容器间互相攻击的安全风险。容器网络所面临的攻击主要包括容器网络内部攻击和容器网络外部攻击。

容器网络内部，由于网络流量不通过物理网卡而在宿主机内部的容器通信，存在容器虚拟网络间的 DoS 攻击风险。容器网络外部，由于宿主机上的所有容器共享物理网卡资源，若外部攻击者向某一个目标容器发送大量数据包进行DDoS 攻击，将可能占满宿主机的网络带宽资源，造成宿主机和其他容器的拒绝服务。

3. 编排工具攻击

编排工具的工作依赖于容器及容器镜像技术，所以用户在使用编排工具时，同样会面临容器及容器镜像的安全风险。在针对编排工具的攻击一节，我们重点介绍编排工具本身存在的安全风险。目前，常见的开源编排工具包括 k8s、OpenShift等，其中 k8s 在功能性、通用性以及扩展性方便表现良好，同时具有较强的社区支持，使其得到广泛的应用。图 4 以 k8s 为例展示了编排工具的架构，以及攻击者可能对编排工具进行攻击的方式

3.1 k8s 组件攻击

图 4 针对 k8s 进行攻击的路径分析

攻击点 1 至攻击点 4，罗列了 k8s 各组件的不安全配置可能带来的安全风险，即 API Server 未授权访问、etcd 未授权访问、kubelet 未授权访问、 kube-proxy 不安全配置。除此之外，还有很多组件都存在着类似的安全问题，比如 dashboard、Docker 等组件也存在未授权访问的隐患，这些都是 k8s 集群的重要系统组件，一旦被攻击成功，都是可以直接获得相应集群、节点或容器的权限。

3.2 服务对外暴露攻击

攻击点 5 表示 Node 节点对外暴露的服务。由于管理员的疏忽或为了方便管理而故意留的一些接口，导致内部服务的暴露，使得编排组件存在一个潜在的攻击点。比如 Mysql 对外服务存在弱口令登录的问题，目标系统的其中一个节点通过 NodePort 对外映射了 Mysql 服务端口，且经过尝试，通过弱口令可登录。这种情况就属于是管理员的安全意识不足引起的服务对外暴露风险，相应的攻击行为即服务对外暴露攻击。

3.3 业务pod 攻击

在云原生环境下，上层应用程序对攻击者来说就像是集群的一个入口，攻击应用程序的目标就是突破入口，拿到业务环境也就是业务所在 pod 的 shell。攻击点 6 显示的是攻击者利用 Web 服务的漏洞对 pod 发起的攻击。

Web 安全发展这么多年，可利用的漏洞非常之多，比如 Log4j2-RCE 漏洞（CVE-2021-44228）以及 Spring-RCE 漏洞（CVE-2022-22965），其危害非常之大，且其利用也很简单。Log4j2 漏洞，虽然在高版本和低版本的 JDK 环境下利用方法不同，但网上都已经分别有非常多的现成 EXP 可用，一旦成功利用即可以完全接管整个业务pod。尽管进入 pod 后的权限仍然是受限的，但接下来可以通过尝试更多攻击手法，比如横向、逃逸等，逐步扩大战果，直至控制整个集群。

对于 pod 发起的本地攻击，主要包括以下几个方面：

信息收集: 进入一个新 pod 中，首先要做的就是收集当前环境的信息。通过信息收集，一是为后续攻击做准备，二是发现敏感服务和敏感信息,例如内网端口、k8s 组件端口等。
提权：包括 pod 内提权和 k8s 提权，pod 内提权和容器的提权类似，详见容器安全内容。k8s 提权的方式和场景有很多，比如 RBAC 提权，还有一些用于 k8s 提权的 Nday，比如 CVE-2018-1002105、CVE-2020-8559 等。
拒绝服务：主要从 CPU、内存、存储、网络等方面进行资源耗尽型攻击。

3.4 集群环境下的横向攻击

可能存在的横向攻击内容包括攻击 API Server 以及攻击其他服务，如攻击路径 7、8 所示。

攻击 API Server ： k8s 集群的 pod 和 API Server 通信是通过 ServiceAccount 的 token 验证身份的，这里存在一个攻击点就是如果 pod 的 ServiceAccount 权限过大，便可以以高权限和 API Server 通信，则有可能查看集群的一些敏感信息或者执行高权限操作，甚至进一步控制集群。

攻击其他服务：集群中往往会有一些通过 ClusterIP 暴露在内部的 Service，这些服务在集群外部是扫描不到的，但是在内部 pod 中通过前文提到的信息搜集方法就有可能发现一些敏感服务，比如通过扫描端口或查看环境变量等。

3.5 k8s 管理平台攻击

除了官方推出的 Dashboard，还有很多 k8s 管理平台，比如 Rancher、 KubeSphere、KubeOperator 等，k8s 管理平台存在未授权访问、弱口令登录等安全风险。因为管理平台是直接控制着整个集群的，一旦出现安全问题，危害十分严重，从安全的角度讲，管理平台应该尽量避免暴露在外网。

3.6 第三方组件攻击

k8s 生态中还会使用一些第三方组件，比如服务网格、API 网关等，这些组件也有可能存在漏洞，比如开源 API 网关 Apache APISIX[14] 的 RCE 漏洞、服务网格 Istio[15] 的未授权访问或 RCE 漏洞等。

4. 微服务攻击

微服务是一种软件架构模式，把一个应用拆分成多个服务，每个服务间通过约定的 API 接口方式进行通信，从而形成一个整体的应用系统。微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当前应用产生的故障不会影响到其他应用，单应用的负载也不会影响到其他应用。这其中每个拆分的服务就是微服务，彼此之间都是松耦合的，甚至可以使用各研发人员擅长的不同开发语言进行编写。图 5 展示了微服务场景下可能存在的攻击类型。

4.1 API 攻击

图 5 针对微服务进行攻击的路径分析

API 是一种计算接口，定义了软件之间的数据交互方式、功能类型。随着互联网的普及和发展，API 从早期的软件内部调用的接口，扩展到互联网上对外提供服务的接口。调用者通过调用 API，可以获取接口提供的各项服务，而无须访问源码，也无须理解内部工作机制的细节。针对微服务 API 的攻击，包括但不限于以下几个方面：

缺少身份认证导致的攻击：某些 API 在设计之初由于未充分考虑用户群体或者具体的使用场景而未进行身份认证。身份认证的缺失导致相关 API 可被任意访问，若相关 API 涉及敏感数据则会埋下严重的数据泄漏的隐患。
输入参数未校验导致的攻击：API 的参数组合及各参数值类型相对固定，这些参数也决定着 API 返回的数据。若 API 未对参数值的类型进行校验则可能会被攻击者利用来进行注入类攻击；若攻击者未将参数与用户身份进行关联则可能会导致越权类攻击。
明文传输导致的攻击：API 未对传输数据进行加密设计而直接进行明文传输，攻击者可通过网络嗅探等手段直接获取 API 的交互格式以及数据，通过对获取的数据进行分析，并进行下一步的攻击。
权限设计不合理导致的攻击：权限设计不合理可能导致水平越权、垂直越权和数据越权等攻击行为。水平越权，由于服务端在接收到客户端请求数据后进行操作时没有判断数据的所属对象，致使用户 A 可以访问到属于同一角色的用户 B 的数据。

垂直越权，由于服务端没有设置权限控制或权限控制存在缺陷，导致恶意用户只要猜测到管理页面的 URL 地址或者某些用于标识用户角色的参数信息等，就可以访问或控制其他角色拥有的数据，达到权限提升的目的。

数据权限，某些 API 在设计时为兼容多个功能会将过多的数据杂糅到一起返回至前端，然后由前端去筛选相关的数据。这导致 API 返回过多的数据，攻击者可通过流量拦截等手段获取 API 原始返回的数据，从而存在数据泄漏的隐患。

安全配置缺陷导致的攻击：安全配置缺陷是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储等问题所造成的攻击。

4.2 API 网关攻击

微服务网关作为微服务后端服务的统一入口，它可以统筹管理后端微服务， API 网关提供路由、负载均衡、流量控制、服务发布等核心功能，API 网关在微服务架构中起到流量枢纽的作用。常用的 API 网关类型包括 Spring Cloud Gateway、Kong、Zuul等。

不安全的微服务网关将给攻击者提供可乘之机，如2022 年3 月1 日，Spring官方发布了关于 Spring Cloud Gateway 的两个 CVE 漏洞，分别为 CVE-2022-22946[19] 与 CVE-2022-22947 。攻击者通过利用 CVE-2022-22947 漏洞，执行 SpEL 表达式，允许在远程主机上进行任意命令执行，获取系统权限。CVE-2022-22946 漏洞，将会导致网关能够使用无效或自定义证书连接到远程服务。

4.3 微服务应用攻击

微服务最终也是一个个独立的应用，也是通过代码方式进行编写的，也会使用一些开源的组件。因此在开发期间如果未做好安全开发管控与检测依然会引发相应的安全风险。如开发维护不当导致的安全漏洞，可能为 API 带来严重安全隐患，不法分子可通过安全漏洞、恶性 Bug 等因素获取敏感信息、造成服务器失陷。开发过程中引入开源或第三方插件、加载库、模块、框架等存在安全问题时，导致代码中出现安全漏洞、恶意代码、“后门”等安全隐患。

5. Serverless 攻击

无服务器计算是一种云计算运行架构，在该架构下，云平台根据开发者编写好的代码，自动准备好相应的计算资源，完成运算并输出结果，从而大幅简化开发运维过程。无服务器计算作为事件驱动架构，将工作负载分解成多个无缝隔离的执行环境，每个执行环境都承载着一个特定任务并负责处理一个单独事件，在时间与空间中各自运行。例如，基于 Knative 实现的 Serverless 架构将无服务抽象为三个关键的组件，分别为构建应用的 build 组件、提供流量的 serving 组件和生产消费事件的 event 组件。无服务器架构颠覆性的变化，给应用/服务开发商和拥有者带来了全新的安全挑战，包括攻击面增多、攻击方式复杂、可观测性不足、传统安全方案不兼容不适用等。图 6 展示了基于 Knative 实现的 Serverless 场景下可能存在的攻击类型。

图 6 针对 Knative 进行攻击的路径分析

5.1 事件注入攻击

无服务器计算本身是由事件驱动的，当函数订阅一个事件源后，该函数在该类型的事件发生时被触发，这些事件可能来源于平台内部或外部，其中部分事件可能是无法确认其来源的，对于来源未知且不可控的事件都是一种潜在的事件注入威胁。

通常情况下，攻击者将可以控制的信息作为事件的一部分传递给可调用单元，可调用单元在得到事件后未对事件做合理的筛选和过滤，就直接对事件进行处理，此时就有可能产生数据注入风险，攻击者利用注入事件所携带的信息控制主机或造成数据泄露等。举例来说，可调用单元的事件还可能来自受攻击者控制的Web 请求。假设可调用单元直接使用事件携带的信息作为数据库访问请求的一部分。那么在这种情况下，攻击者将会使用精心构造的信息来修改数据库或读取机密信息。有关无服务器应用程序的注入攻击实例研究可参考 Top10 Interpretation for Serverless 。

5.2 敏感数据泄露攻击

在无服务器计算体系结构中，敏感数据的暴露与在其他任何体系结构中一样令人担忧。传统体系结构中使用的大多数方法，如窃取密钥、执行中间人攻击以及在静止或传输中窃取可读数据，仍然适用于无服务器应用程序。然而，由于无服务器计算架构的存储共享特点，攻击者可以利用共享存储权限配置错误或漏洞窃取系统的敏感数据。

全局信息泄露：无服务器计算架构中函数调用的不同服务通常也会被其它用户的函数调用来提供服务，无法像传统应用程序使用单个集中式配置文件存储的方式，因此开发人员多使用环境变量替代，使服务使用的敏感数据可能会留在容器中，并可能在函数的后续调用期间暴露。攻击者可以利用无服务器计算架构的这一特点，通过恶意程序植入等手段，获取服务中的全局敏感数据，造成敏感数据泄露。

密钥的不安全存储：通常，服务被触发的时候需要访问特定的云或外部资源。

要做到这一点，服务可能需要获取密钥。攻击者可以利用未安全存储的密钥或使用标准凭据集等情况发起攻击，造成严重的数据泄露等。像任何其他使用无服务器功能的应用程序一样，凭据和密钥的泄漏可能导致虚拟身份和数据泄漏。

5.3 身份认证攻击

Serverless 架构的应用是由几十甚至上百个函数组成，每个函数实现特定的业务功能，这些函数组合完成整体业务逻辑。一些函数可能会公开其 Web API，需要进行身份认证，另一些则可能只允许内部调用，所以不用进行身份认证，这就使 Serverless 应用的整体身份认证变得复杂，你要为每个函数及事件源提供合理的身份认证机制，一不小心就会出错。

如果一个函数提供了公开的 API 给用户使用，并且该 API 也有正确的身份认证逻辑，用户访问函数后，函数内部首先会从云存储读文件，然后将读取后的数据作为输入源调用内部函数，内部函数无须身份认证，如果云存储没有设置合适的身份认证，攻击者可能直接向云存储注入数据进行攻击。

5.4 权限滥用攻击

一个无服务器应用程序可以由数百个微服务组成。不同的功能、资源、服务和事件，所有这些都被编排在一起，以创建一个完整的系统逻辑。无服务器体系结构的无状态特性要求对每个资源进行仔细的访问控制配置，未遵循最小化权限的配置原则，配置了不适当的权限，将会增加事件驱动无服务器计算架构中的攻击面，使敏感数据更容易被窃取。

5.5 拒绝服务攻击

Serverless 平台具有自动化弹性扩展的特性，这就意味着用户只需要为函数的调用次数付费，函数的扩展交由云厂商负责。如果攻击者掌握了事件的触发器，并通过 API 调用大量的函数资源，那么在未受保护情况下函数将急速扩展，随之产生的费用也呈指数增长，最终会导致开发者的账户资金被消耗光，造成后续正常调用的拒绝服务。另外，即便受到保护的情况下，也未必可以完全规避风险，例如云厂商替开发者设置了调用频次上限，虽然开发者的钱包受到了保护，但攻击者也可以通过攻击频次达到设定上限实现了对开发者账户拒绝服务的目的。

5.6 针对函数供应链的攻击

无服务器计算的函数通常是功能单一的微服务，随着功能逻辑的复杂度提升，代码量也会随之增加，随之而来的供应链风险也愈发严重。例如利用基础镜像中已经存在的安全漏洞进行攻击、利用应用程序引入第三方依赖库的漏洞进行攻击等。

本文摘编自中国联通研究院发布的《云原生安全威胁分析与能力建设白皮书》，全文下载：