该论文是一篇系统性综述，聚焦云计算多租户共享物理硬件所导致的隔离边界失效问题。作者收集并分析了 2008 至 2025 年间超过 120 篇安全文献，覆盖虚拟机隔离与容器隔离两条主线。论文考察的威胁类别包括：虚拟机逃逸（guest 突破 hypervisor 边界）、虚拟机跳转/跨租户 VM hopping、CPU 缓存侧信道（利用缓存时序跨租户泄露数据）、容器逃逸（突破 namespace 与 cgroup 等隔离机制）、存在漏洞或污染的容器镜像（涉及镜像供应链），以及分布式拒绝服务（DDoS）攻击。作者围绕三个核心研究问题对这些威胁及其对应对防御手段进行结构化评估，以回答攻击面如何演化、现有防御覆盖到什么程度、还有哪些空白。为便于横向比较不同防御方案，论文提出量化评分框架 ADPO，从准确性（Accuracy）、部署难易度（Deployment ease）、性能影响（Performance impact）、运维开销（Operational overhead）四个维度给出 0 到 3 的评分；同时将攻击影响映射到机密性、完整性、可用性（CIA）三元组上的 1 至 5 级严重度刻度。论文最后讨论了安全性与系统性能之间的固有权衡，并列出开放挑战，包括构建低开销的入侵检测机制，以及构造真实、可复现的测试数据集。整体上，这是一份面向云基础设施隔离攻防的综述与评估方法论工作，适合云平台安全架构师、hypervisor 与容器运行时研究者、以及负责云检测工程的 SOC 人员阅读。

该论文研究如何保护容器化工作负载(如 Docker 容器与 Kubernetes Pod)免受中间人(Man-in-the-Middle, MitM)攻击。作者首先指出一个常被忽视的事实：容器化环境虽然提供隔离与编排便利，但其内部工作负载仍然暴露于与非容器环境相同的攻击面，包括钓鱼、应用层漏洞利用以及网络入侵；而容器具有动态调度、生命周期短、东西向流量密集、配置易漂移等特性，使传统边界防护与静态网络策略难以覆盖通信链路上的窃听、篡改与会话劫持风险。方法上，研究采用基于 PRISMA 指南的系统性综述(Systematic Review)，对同一研究主题的既有证据进行检索、筛选与汇总，提取出可复用的成功要素(success factors)；在综述基础上开展设计型研究(design-and-creation)，提出一个面向容器化操作系统的安全框架。该框架的核心包括三部分：一是用于描述通信行为与密码原语的概念模型(conceptual model)，使安全属性可被形式化刻画；二是借助 AnBxJ Java 安全库来实现与验证通信安全；三是部署工作在 OSI 模型第 7 层(应用层)的容器防火墙，将访问控制与检查从网络层提升到应用层，并结合零信任(Zero Trust)架构原则，对通信双方进行持续的身份确认与完整性校验。研究围绕一个核心问题展开：如何有效保护容器化操作系统免受 MitM 攻击。验证部分在一个容器化操作系统场景中成功实现了该安全机制，并识别出实现过程中的成功因素。论文的价值主张是帮助从业者系统化容器安全实践，并为 Docker 与 Kubernetes 部署提供可落地的零信任参考架构。需注意，本文属于综述加设计型研究，重点在方法论与架构层面，摘要中并未给出量化实验结果、性能开销数据或具体攻击面测绘结论，因此结论的可迁移性仍需结合完整论文与实测验证。

论文《NACRE: Rethinking Confidential Containers through Native Architectural Support》针对Linux容器在共享主机内核设计下的安全缺陷展开研究。传统容器依赖主机内核实现高密度和快速生命周期操作，但也使被攻陷的主机能够任意查看或篡改容器状态。现有机密计算方案通常保护的是整个地址空间（enclave）或完整客户操作系统，即便有容器粒度的保护系统，也仍需引入额外的隔离保护上下文，未能将“一组由主机管理的动态Linux进程”视为体系结构层面的原生保护单元。为此，作者提出NACRE——一种基于RISC-V的软硬件协同设计，用于实现原生机密容器。其核心思想是：将主机对资源的管理权限与对受保护状态的访问/提交权限显式分离。硬件可识别容器身份，并将受保护陷阱导向隔离的S-mode代理；同时由M-mode监控器负责提交安全关键的身份、映射和页面转换状态。代理可在不修改satp的前提下将部分服务委托给主机Linux运行，且只要服务不访问私有字节或修改受保护状态，就无需陷入M-mode，从而显著降低开销。作者通过扩展QEMU、OpenSBI、Linux、可信代理和runc构建了原型系统，实现了单容器私有内存基础子层，覆盖启动、缺页异常、fork/写时复制、用户态访问及拆除路径。实验结果表明，在lmbench的5个系统调用和管道指标中，三次运行均值与runc基线相差在3.5%以内；在8种nginx对象大小的等权均值下，聚合吞吐量仅降低1.9%，有效验证了该架构的高性能和可行性。该研究为机密容器提供了体系结构级的新思路，适合从事系统安全、云基础设施和机密计算架构研究的读者。

本文提出 KubeCap，一个面向 Kubernetes 工作负载的最小权限能力缩减框架。研究背景是：Kubernetes 作为最流行的容器编排平台，允许开发者通过 manifest 文件管理 Linux capabilities，但实践中开发者常依赖默认设置或粗粒度的安全上下文，违反最小权限原则，扩大了容器化工作负载的攻击面。现有研究要么只检测 Kubernetes manifest 中的脆弱模式，要么只为独立 Linux 程序推断所需能力，均未直接解决 Kubernetes 环境下的能力最小化问题。作者首先对三个开源数据集进行实证研究，发现 74.67% 的项目缺乏能力配置，表明该问题普遍存在。KubeCap 的工作流程包括：将部署规格转换为确定性 manifest、定位容器入口点、执行可达性引导的系统调用分析，并利用 LLM 辅助规则推断从 Linux 内核代码中提取 syscall-参数-能力 的关联关系。基于这些结果，KubeCap 为每个工作负载推断所需的最小能力集合，并自动生成修复后的 manifest。在 10 个基于 Go 的代表性 Kubernetes 项目上评估，平均能力缩减率达 54.97%，优于快速类型分析和类层次分析基线，且保持了实用的分析成本。实验证明 KubeCap 能有效在 Kubernetes 中实施最小权限原则。

本文针对 Docker Hub 容器镜像中普遍存在的安全漏洞、密钥泄露和错误配置问题，提出了一套大规模生态系统测量方法。研究背景是：Docker Hub 是大多数容器部署的底层镜像仓库，一个广泛使用的基础镜像一旦存在缺陷，将被所有基于其构建的镜像继承。此前的研究规模较小，且通常依赖单一扫描器，导致统计结果受工具偏差影响而缺乏可靠性。作者提出了名为 ChimangoScan 的自动化管道：它爬取了 Docker Hub 全部命名空间（共 12,716,568 个仓库，累计拉取次数达 6638 亿次），重建了镜像图层依赖图（包含 5440 万个 IS_BASED_OF 边），设计了一个暴露评分指标——该指标综合镜像自身拉取量及其所有下游镜像的拉取量——将镜像按暴露程度排序，并选取其中暴露程度最高的 52,895 个仓库（占全部拉取量的 84.7%）进行扫描。研究使用了六种独立的扫描器，共产生 1.704 亿条发现。主要结果包括：(1) 漏洞几乎无处不在：96.3% 的镜像存在已知软件包漏洞，93.4% 存在严重漏洞，98.0% 至少有一项 CIS Docker 基准错误配置；(2) 单一工具的报告不可靠：在 8070 万个不同的（漏洞、包）组合中，66.8% 仅被三个漏洞扫描器之一识别，只有 2.7% 被全部三个识别，最好的单个扫描器召回率仅为 66.9%；(3) 密钥检测误报率极高：TruffleHog 在 76.9% 的镜像中标记出密钥，但人工标注 1100 个随机样本发现其中 99.7% 并非真实凭据；(4) 单个 zlib CVE 可传播至 113 万个下游镜像，且这些镜像承载了全部语料暴露量的 47.3%，但暴露程度并不能可靠预测镜像的脆弱性。作者公开了该管道和 283GB 的数据集，为后续研究提供了重要基础。该工作对容器供应链安全、漏洞扫描工具评估和镜像安全基线制定具有重要参考价值。

本文针对容器化工作负载在构建、存储和部署环节中面临的安全挑战，提出了一种基于透明性和可追溯性服务的可验证容器镜像分发架构。研究背景是：容器镜像通常通过 CI/CD 流水线构建，存储在镜像仓库中，并部署到云和边缘等异构基础设施。一旦某个构建步骤或凭据被攻陷，常规自动化流程就可能变成大规模分发恶意工件的过程，因此需要镜像完整性、透明性和部署时强制检查机制。核心问题是密钥管理困难以及缺乏可执行的准入时验证策略。作者设计的架构包含一个透明度服务，该服务生成与已认证身份绑定的一次性签名密钥，并将签名事件记录到仅可追加的透明性注册表中，同时返回密码学可验证的包含证明。这些证明和身份属性被附加到镜像元数据中，在准入阶段由策略即代码（Policy-as-Code）进行评估，从而只允许符合策略的工件被部署。作者实现了与 GitHub Actions 和 GitLab Runners 集成的概念验证系统，并在现实威胁模型下评估了该流水线如何缓解常见的供应链攻击。主要贡献包括：提出一种结合透明度日志和一次性密钥的镜像签名机制，降低密钥泄露风险；将身份属性与证明纳入准入控制，实现细粒度的策略执行；通过原型系统验证了方案在主流 CI/CD 平台上的可行性和有效性。适合云原生安全工程师、DevSecOps 从业者以及供应链安全研究人员阅读。

该论文研究现代云平台中容器和虚拟机（VM）之间通过共享页面缓存（page cache）产生的微架构时序侧信道泄漏问题。云平台为提升性能，通常让租户共享主机硬件资源，同时通过软件隔离（如容器、gVisor、Kata Containers、QEMU/KVM等）保证安全。然而，当租户访问主机文件系统状态时，主机页面缓存仍可能被共享且可观测。论文将这种页面缓存通道归类为操作系统介导的微架构时序侧信道，其信号由处理器微架构、内存和存储层次结构以及虚拟化机制共同塑造。作者评估了多种隔离运行时环境：Docker（直接共享宿主内核）、gVisor（使用systrap和KVM）、Kata Containers（使用QEMU和Cloud Hypervisor，搭配共享主机文件系统或块设备后端存储）、以及QEMU/KVM虚拟机（多种主机缓存策略）。实验发现，只要I/O路径暴露了共享、可缓存的文件对象（包括OverlayFS层、virtio-fs导出、回环块设备），时序信号就会持续存在。相反，直接I/O和专用块设备可以显著减弱或消除该信号。因此，虚拟化通过增加延迟和算法噪声改变了泄漏形态，但并未消除对共享硬件和缓存状态的底层依赖。论文通过一个案例研究展示了实际影响：从基于MySQL的WordPress部署中恢复粗粒度的活动信息。这些结果将页面缓存攻击置于更广泛的OS介导微架构时序信道类别中，并激励对时序隔离的协调硬件、虚拟化和OS支持。

该论文研究了ECS（Elastic Container Service）的快速增长趋势及其伴随的安全考量。作者通过分析大规模数据，揭示了ECS使用量的激增模式，并识别了常见的配置错误、访问控制漏洞以及镜像安全问题。论文提出了一套评估框架，用于量化ECS环境中的暴露面，并通过实证数据证明了当前实践中的安全风险。主要贡献包括：对ECS增长趋势的纵向分析、常见安全问题的分类以及可操作的缓解建议。适合云安全工程师、DevSecOps团队及云服务提供商参考。

该论文提出 Bulkhead，一个自动化框架，用于检测和修复容器逃逸中的路径遍历（PaTra）漏洞。背景是容器生态系统中的文件系统隔离常因跨边界路径解析错误而削弱，导致路径遍历漏洞。这些漏洞源于不安全的主机-容器交互，尤其是在云系统将共享资源（如GPU、代理工作区）挂载到容器中以支持AI工作负载时，此类漏洞日益普遍。现有防御不足：内核级防护具有侵入性，可能破坏系统调用稳定性，因此未被Linux主线接受；检测方法依赖于静态规则匹配或手动代码审计，静态规则会标记路径相关函数但无法捕获确定主机-容器交互所需的语义，导致大量误报；手动审查需要领域专业知识，成本高、效率低、难以扩展。Bulkhead创新性地将大语言模型（LLM）与形式化方法相结合，实现语义漏洞发现与修复。该框架使用多智能体系统，通过从已知案例中泛化的多维知识模式来识别和修复PaTra漏洞。首先，应用高风险功能模式定位容器化代码中跨边界交互的入口点；然后，利用调用链模式以适当深度恢复相应的执行路径。检测管道根据应用场景和威胁模型分析这些调用链，识别跨边界交互中的缺失安全检查、TOCTOU竞态等漏洞，并生成概念验证（PoC）漏洞进行验证。这些PoC随后指导补丁生成。为确保修复正确性，补丁管道使用预定义的模型检查模板进行断言驱动验证。实验（论文中应有）证明Bulkhead能有效发现真实世界容器环境中的漏洞并生成可靠补丁。该工作适合容器安全研究人员、云平台开发者及对AI基础设施安全感兴趣的从业者阅读。

该论文提出了一种无需训练即可检测容器化微服务环境中异常行为的新方法 REPLICAWATCHER。传统的基于异常的入侵检测系统需要建立全面的行为基线，但在微服务等动态环境中，“正常”概念频繁变化，导致基线老化并逐渐失效，需要定期重新训练，这在安全应用场景中颇具挑战。REPLICAWATCHER 的核心洞察是：微服务中为容错或可扩展性而部署的副本（replicas）会执行类似任务并呈现相似行为模式。通过实时观察同一服务的多个容器实例的行为，任何偏离其对应副本的显著差异都可作为安全威胁的重要指标。该方法完全无需训练阶段，避免了基线更新和模型老化问题。实验评估表明，REPLICAWATCHER 对正常行为偏移具有鲁棒性，无需重新训练即可保持有效性。与最先进的基于训练的方法相比，其性能相当，平均精确率达 91.08%，召回率达 98.35%。该研究适用于安全运维工程师、微服务架构师及威胁检测研究人员，尤其适合动态变化环境下的异常检测场景。

随着云原生技术的快速普及，多租户环境中的机密容器部署需求日益迫切。然而，现有基于微虚拟机（microVM）架构的机密容器设计，虽然增强了容器间隔离，但其复杂的软件栈导致较高的启动延迟和资源开销，不适合短期容器工作负载。本文提出 Fasco，一种基于 ARM 机密计算架构（CCA）的轻量级机密容器运行时。Fasco 将每个容器直接实例化为独立的容器域（Container Realm），利用 CCA 的硬件强制隔离机制，确保容器内应用数据的机密性和完整性。此外，Fasco 引入专门系统域（System Realm）为容器域提供系统服务和资源管理。通过异常转发和共享缓冲区，Fasco 保证不同容器域之间的隔离。作者在 ARMv8 硬件上实现了 Fasco 原型并进行了性能评估，实验结果表明，Fasco 相比现有机密容器架构，显著降低了启动延迟和性能开销，同时保持了较小的可信计算基（TCB）。该工作为机密容器提供了一种更轻量、高效的实现方案，特别适用于函数计算、微服务等短期容器场景。

容器在云平台中广泛使用，但其隔离性弱是主要安全威胁。本文提出 RContainer，一种通过扩展 ARM 机密计算架构（CCA）硬件原语来保护容器免受不可信操作系统侵害、并实现容器间强隔离的新型安全容器架构。RContainer 引入一个微小的可信 mini-OS，与权限降低的操作系统并行运行，负责监控操作系统与容器之间的控制流。此外，RContainer 采用 shim 风格隔离机制，利用 Granule Protection Check（GPC）硬件机制在内核层为每个容器创建一个称为 conshim 的隔离物理地址空间。作者在 ARMv9-A 固定虚拟平台和 ARMv8 硬件 SoC 上实现了 RContainer，并进行了安全分析和性能评估。实验结果表明，RContainer 能在适度性能开销和极小的可信计算基（TCB）下显著增强容器安全性。

本文提出EBCC（Enclave-Backed Confidential Containers），一种兼容OCI（Open Container Initiative）的运行时架构，旨在将机密计算工作负载无缝集成到标准容器生命周期管理中。现有机密容器系统通常依赖虚拟机后端或特定TEE的执行基板，导致机密执行与常规OCI运行时生命周期分离，增加了部署和管理的复杂性。EBCC将REE（富执行环境）侧的锚点和TEE（可信执行环境）侧的机密阶段视为一个单一的容器化机密计算复合体，保留标准OCI生命周期操作（如创建、启动、停止、删除），并将TEE特定执行逻辑封装在后端适配器之后。它维护每个实例的持久状态和每个阶段的工件，用于请求处理、响应生成、日志记录和证据绑定。作者在Keystone TEE后端上实现了EBCC原型，并评估了其正确性、性能、内存占用和并发行为。结果显示，EBCC相比原生Keystone执行引入了额外延迟，主要来自生命周期中介、请求验证、EID分配、后端分发和工件持久化，但额外开销集中在主机端管理状态。跨TEE案例研究（SGX、TDX、OP-TEE）表明，相同的生命周期和阶段抽象可以映射到enclave风格、VM风格和嵌入式风格的TEE。这些结果表明EBCC能够使基于TEE的执行通过OCI风格的生命周期进行管理，而不会显著扩大受保护侧的TCB（可信计算基）。

本文研究了容器隔离中的去同步风险（Desynchronization Risks），即容器运行环境与宿主机之间在时间、状态或资源视图上出现不一致，可能导致安全隔离失效或性能降级。作者首先系统分析了容器运行时（如runc、crun）与宿主机内核、cgroup、namespace等机制之间的同步点，识别出三类典型去同步场景：时钟漂移导致的定时器失准、cgroup统计更新延迟引发的资源超限、以及namespace切换时的竞态条件。针对这些风险，提出了一套分层的缓解策略：在运行时层引入同步检查点，在内核层优化cgroup事件推送机制，并在应用层提供可选的同步代理库。实验基于Docker和Kata Containers环境，测试了CPU、内存、网络I/O等负载下的去同步概率与影响，结果表明所提方法能将高危去同步事件的概率降低至1%以下，性能开销控制在5%以内。该研究对于云原生环境下的安全运行时设计与容器加固具有重要参考价值。