文章总结： 本文探讨了AI时代容器安全的攻防实践，分析了常见攻击场景、案例和注意事项，提出了AI时代容器安全建设的八大关注点和十条注意事项，并展望了未来三年容器安全攻防趋势。
综合评分： 85
文章分类： 安全培训,网络安全,应用安全,数据安全,安全运营
AI时代的容器安全攻防实践技术培训（下）
原创
小安伴你行
小安伴你行
小安伴你行
2026年9月22日 09:18
北京
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
第五章AI时代的容器安全常见攻击场景
5.1 场景一：恶意镜像与镜像投毒
攻击链路：攻击者先在公共镜像仓库投放携带挖矿程序或后门的仿冒镜像→研发人员检索拉取该镜像并基于它构建业务镜像→投毒代码随镜像流入生产集群→恶意进程在业务容器内启动运行，向外连接矿池或C2服务器。该场景的典型技术特征包括：将恶意层隐藏在镜像历史深处、把入口脚本伪装成环境初始化程序、将挖矿进程名伪装为系统进程、通过多阶段加载器规避静态扫描。该场景最突出的问题是“污染面广”：一个被投毒的基础镜像可能同时污染数十个业务镜像，事后排查需要对全量镜像做血缘分析。
5.2 场景二：容器逃逸攻击
攻击链路：攻击者先通过Web漏洞攻入容器获取容器shell→检查容器配置与挂载信息（包括是否开启特权模式、是否挂载宿主机路径、是否存在docker.sock）→选择对应逃逸路径（直接写入宿主机crontab、通过docker.sock创建特权容器、利用内核漏洞）→成功逃逸后控制宿主机→植入可规避EDR检测的后门并开展横向移动。在AI技术加持下，逃逸环节的路径选择可由AI完成自动化分析，攻击者仅需拿到容器入口即可发起攻击。该场景的危害在于，一旦逃逸成功攻击者就会获得节点控制权，进而可利用kubelet凭据、节点本地存储的kubeconfig向集群控制面发起权限升级。
5.3 场景三：K8s集群入侵与横向移动
攻击链路：攻击者通过暴露的API Server匿名接口、Dashboard或kubelet 10250端口接入集群→枚举Namespace与ServiceAccount权限→窃取高权限Token，或是利用配置过度宽松的RBAC→创建挂载宿主机根目录的恶意Pod（完成Pod逃逸），或是直接通过exec进入业务容器→横向移动至数据库、消息队列等核心服务。该场景在云上实战攻防中出现频率极高，问题根源多为“控制面暴露+RBAC配置粗放+默认Token挂载”三类问题的叠加。在横向移动阶段，攻击者还常借助K8s原生机制（例如使用集群内的合法镜像作为跳板），规避网络层检测。
5.4 场景四：AI供应链投毒
攻击链路一（恶意包）：攻击者在PyPI发布仿冒热门AI工具的恶意包→研发人员通过pip将其安装，纳入镜像构建流程→恶意包在构建或运行阶段执行代码，窃取环境变量中的云凭据与Token→攻击者利用窃取到的凭据访问企业镜像仓库、模型仓库或云API。攻击链路二（恶意模型）：攻击者在模型平台发布携带pickle反序列化载荷的“预训练模型”→算法开发人员下载并尝试加载模型→完成加载后攻击者即可执行任意代码，获取推理容器或训练容器的控制权限。该场景的特殊性在于，投毒目标是研发人员日常依赖的AI生态组件，安全边界存在于研发流程内部而非网络边界，传统防护手段对此几乎完全失效。
5.5 场景五：GPU算力劫持与挖矿
攻击链路：攻击者入侵面向公网开放的AI训练平台或Notebook服务（利用弱口令、未授权访问、框架漏洞实现入侵）→探测集群GPU资源与调度凭据→创建大量消耗GPU资源的恶意任务（任务会伪装成正常训练任务，镜像名与命令行高度仿真）→GPU算力被劫持，用于挖矿、代理出租或是对外出售。该场景的直接损失是算力成本增加与正常训练任务被挤占，间接风险是恶意任务所在Pod往往配置了高权限，攻击者可进一步在节点内开展横向移动。识别要点：GPU利用率与训练任务产出不匹配、存在异常外联矿池协议（Stratum）与代理端口、新增高资源消耗Pod无对应审批记录。
5.6 场景六：AI推理服务漏洞利用
攻击链路：攻击者对向公网暴露的大模型推理API开展探测→利用提示词注入诱导AI调用外部工具能力（包括文件读取、命令执行插件、Agent工具链等）→以推理容器为跳板读取配置文件与凭据→借助容器内的凭据横向进入内网，或是直接访问模型存储。另一种攻击路径是利用推理框架自身漏洞（例如历史上曝出的Multiple Protocol类RCE漏洞）直接获取容器权限。该场景表明，大模型应用和传统Web应用一样存在“从输入到执行”的通路，且其插件与Agent能力显著扩大了RCE发生后的破坏范围。
5.7 场景七：密钥窃取与凭据滥用
攻击链路：攻击者获取任意容器的执行权限→批量收集环境变量、已挂载的Secret、镜像元数据以及~/.kube/config配置文件→利用数据库连接串直接访问核心数据库，通过AK/SK调用云API，使用Token访问模型仓库与镜像仓库→最终完成数据窃取或资源滥用。凭据攻击是容器攻击链中“性价比最高”的环节，通常在初始入侵完成后的数分钟内即可结束。在AI场景下，被窃取的目标还新增了模型API Key与算力平台凭据，攻击者可利用这类凭据批量调用企业付费模型服务，进而造成资金损失。
5.8 攻击链路整体分析
将上述场景放到统一框架下观察可以发现，AI时代的容器攻击链呈现标准化的六段式结构：初始访问（暴露面+供应链+AI生态）→执行与驻留（镜像内载荷、容器内后门）→凭据收集（环境变量+Token+云AK/SK）→权限提升（RBAC滥用+容器逃逸）→横向移动（服务网段+K8s API）→达成攻击目标（数据窃取/算力变现/勒索/持久化控制）。对防御方而言，攻防对抗的本质，是在攻击链的每一段都增设“阻断或告警”控制点：供应链环节依靠扫描和签名准入，执行环节依靠行为基线检测，凭据环节依靠Secret管理与权限最小化，权限提升环节依靠收紧能力与逃逸检测，横向移动环节依靠微隔离防护，目标达成环节依靠数据与出口管控。任何单点防护都无法抵御全链路攻击，防御体系必须成体系搭建。
第六章AI时代的容器安全攻击案例剖析
6.1 案例一：Docker Hub恶意镜像挖矿事件
事件概况：安全研究人员在Docker Hub上发现大量携带挖矿程序的恶意镜像，其中部分恶意镜像伪装成流行中间件或基础镜像的仿冒版本。这类镜像累计下载量达数十万次，容器启动后便会运行XMRig挖矿程序，还会通过伪装进程名、隐藏CPU占用的方式躲避安全巡检。
技术分析：攻击者利用镜像仓库开放的发布机制，以及用户“搜到即用”的使用习惯投放恶意镜像；恶意镜像内通过环境变量配置矿池与钱包地址，方便攻击者动态调整参数；部分样本还集成了程序失效后自动重启的守护逻辑。防御侧暴露的问题包括：镜像来源未受管控、未开展准入扫描、缺少运行时阶段的CPU与外联监控。
经验教训：第一，企业使用的镜像必须从可信仓库、可信命名空间获取，应当将企业私有仓库作为生产环境的唯一镜像来源；第二，镜像扫描与准入必须形成制度化规范，不能依赖研发人员的自觉执行；第三，挖矿类威胁的检测重心应当放在“异常CPU/GPU占用+矿池协议外联”两项指标上；第四，需要将对公共仓库镜像引用的行为纳入威胁情报监控范围。
6.2 案例二：runc容器逃逸漏洞（CVE-2019-5736）剖析
事件概况：2019年披露的runc漏洞，允许恶意容器覆盖宿主机上的runc二进制文件，进而在其他容器下一次执行操作时，以宿主机root权限执行任意代码。该漏洞是容器逃逸类漏洞的标志性案例，在此后数年间，runC/containerd生态又持续出现同类逃逸漏洞。
技术分析：runc在执行exec进入容器的过程中，会短暂将容器内进程的文件描述符传递到宿主机执行环境，恶意容器可利用这一机制，通过文件描述符竞争写入宿主机的runc文件。完成攻击的前提是攻击者已经控制容器，并可覆写容器内进程（例如劫持sh入口）。该案例揭示了共享内核架构下“运行时组件本身也是攻击面”的规律——对运行时进行升级，就是对攻击面进行收敛。
经验教训：第一，容器运行时组件（runc/containerd/nvidia-container-toolkit）必须纳入高危漏洞应急清单，要具备小时级升级能力；第二，逃逸检测需要覆盖“运行时二进制被篡改”这一具体特征；第三，对容器内文件系统做最小化处理（如配置只读根文件系统、不落地存储编译工具），可以显著提高漏洞利用门槛；第四，任何“已失陷容器”都应当按照“宿主机即将失陷”的标准处置，不可低估其风险。
6.3 案例三：HuggingFace恶意模型与模型投毒
事件概况：安全研究人员多次在HuggingFace平台发现携带恶意载荷的模型文件，这类恶意文件会利用PyTorch、TensorFlow的pickle序列化机制，在模型加载时执行任意代码；还有部分组织通过上传仿冒知名开源模型的“投毒副本”诱导用户下载。除此之外，安全人员还发现了通过模型加载配置注入代码路径的攻击变种。
技术分析：pickle/py格式的模型文件本质上是“可执行代码的数据包装”，torch.load在默认配置下会对文件反序列化，并执行其中__reduce__定义的逻辑，“加载即执行”属于框架本身的结构性风险；由于模型文件体积大，且攻击行为发生在AI研发侧而非网络边界，传统防护手段对此完全无法感知。这类攻击可造成多重后果，包括研发环境凭据被盗取、训练集群被植入后门、模型资产在用户无感知的情况下被替换。
经验教训：第一，模型文件必须作为“可执行资产”开展管理，仅允许使用来自可信来源且经扫描（反序列化风险检测）的模型文件；第二，私有模型仓库要落实准入审批与哈希校验机制；第三，训练/推理容器按照最小权限原则运行，将模型加载路径与外网做隔离处理；第四，研发侧安全意识培训必须覆盖AI供应链相关内容。
6.4 案例四：K8s暴露面板致集群入侵（Tesla挖矿事件）
事件概况：知名车企特斯拉的云上K8s集群，曾因管理控制台暴露在公网且缺少认证防护被攻击者攻陷，攻击者获取集群控制权后部署挖矿负载，还通过Cloudflare Tunnel这类隐蔽外联手段规避流量检测，同时窃取了集群内对象存储中的敏感数据。
技术分析：攻击者的初始访问，依托于暴露在外且防护薄弱的管理界面；在横向移动和驻留阶段，攻击者将挖矿程序隐藏在K8s workload中，利用其自动重建能力实现难以清除的持久驻留；数据窃取则是利用集群内可用的云凭据访问对象存储完成。该案例完整呈现了“控制面暴露→集群失陷→算力与数据双重损失”的攻击流程，是极具代表性的样本。
经验教训：第一，所有容器与K8s管理界面（包括Dashboard、模型仓库、AI平台控制台）都必须收敛至内网，同时配置认证机制与最小授权规则；第二，集群内的云凭据需要按照最小化原则管理，并定期轮换，与控制面权限做隔离；第三，出网管控必须覆盖“隧道类隐蔽外联”场景，限制匿名代理与隧道协议的违规使用；第四，需要为“可自动重建的负载”建立变更基线，识别未经审批发布的异常负载。
6.5 案例五：PyPI供应链投毒事件
事件概况：安全社区已持续披露多起针对AI开发者的PyPI恶意包攻击：恶意包会仿冒知名AI工具的名称，累计下载量已达到相当规模；部分样本会在安装过程中窃取环境变量、浏览器Cookie、AWS密钥与Discord令牌，另一类样本则会植入后门，等待远程指令发起攻击。随着AI热潮兴起，这类攻击事件的发生频率已显著上升。
技术分析：攻击者精准利用了AI开发者“搜索到即安装”的行为习惯；恶意包通常会在setup.py的安装钩子中执行payload，让恶意动作发生在“构建镜像/安装依赖”阶段，而该阶段运行在企业CI环境内，本身凭据密度高、防护能力薄弱；除此之外，依赖混淆攻击还会利用企业内部包名未在公共仓库注册的空窗完成投毒。
经验教训：第一，引入依赖包应当走内部代理仓库+白名单审批流程，禁止构建环境直接连接公网包仓库；第二，CI/CD构建环境凭据要与生产凭据严格分离，并采用一次性凭据机制；第三，建立SBOM依赖基线，可基于恶意包情报按小时级回溯影响范围；第四，将“包名管理”纳入供应链安全治理，内部包统一前缀并在公共仓库注册占位。
6.6 案例六：GPU算力窃取与僵尸网络（TeamTNT/Kinsing类）
事件概况：以TeamTNT、Kinsing为代表的云僵尸网络组织长期在容器化云环境活跃，攻击者从暴露的Docker API与未授权访问的Redis服务切入，植入挖矿载荷；随着GPU资源价值攀升，这类组织已将攻击目标扩展至AI算力，出现了窃取GPU资源用于挖矿、出租的攻击活动，还有部分变种专门搜索目标环境中的AI相关凭据与模型接口。
技术分析：此类攻击具备高度自动化特征，攻击流程为：批量扫描暴露面→利用已知未授权配置与权限错配植入木马→清理竞品挖矿程序→实现持久化驻留并开展横向移动。这类攻击的工具链长期迭代演化，已具备云凭据窃取与K8s识别能力，可视为“容器攻击链的工业化样本”。
经验教训：第一，暴露面收敛是成本最低的防御手段——Docker API、Redis、K8s组件一律不得直接暴露在公网；第二，针对僵尸网络的高自动化攻击水平，要求防御方同步实现自动化防御，即搭建自动化暴露面巡检、准入阻断与运行时检测体系；第三，GPU集群需要建立“任务-审批-资源”对账机制，可快速定位异常高耗任务的责任人。
6.7 案例复盘与经验启示
结合六个案例，可以提炼出AI时代容器安全攻防的五条核心启示。
启示一：入口完全防住是常态，防线需要向纵深延伸——六个案例中有五个都是通过“暴露面或供应链”完成入侵，说明单一边界并不可靠，纵深防御与运行时防护才是安全防护的主战场。
启示二：凭据是攻击推进的加速器——几乎所有案例里，攻击者都会在入侵第一时间收集凭据，因此Secret治理与最小化授权的优先级应当高于漏洞修复。
启示三：AI资产在继承容器原有风险的基础上，进一步放大了安全危害——模型、算力、数据资产失陷带来的损失远高于传统业务负载，因此AI资产必须单独划分防护域开展防护。
启示四：防御的自动化水平决定了防护的最终成效——从挖矿僵尸网络到AI辅助红队，攻击侧已经实现全面自动化，人工防御已经全面落后。
启示五：安全运营与实战演练缺一不可——每个失陷案例背后，都存在“部署了防护设备但缺少有效运营”的问题，应急预案与实战演练直接决定了真实攻击发生后的响应水平。
第七章AI时代的容器安全关注点及注意事项
7.1 八大关注点
结合前述攻防分析，AI时代的容器安全建设应当重点关注八个方向。
关注点一：镜像与供应链可信治理。要将“可信来源、强制扫描、签名准入、SBOM追溯”确立为不可妥协的基础制度，尤其需要针对AI框架镜像、模型文件建立专项准入流程。
关注点二：容器逃逸防护与内核硬化。坚持落实最小化配置原则，禁止开启特权权限、禁止危险挂载、收紧capabilities权限，并持续跟踪运行时组件与内核高危漏洞，搭建“漏洞情报→影响面定位→升级验证”的快速响应通道。
关注点三：K8s编排平台安全基线。以CIS Benchmark与等保容器测评要求为标准，落实控制面收敛、RBAC最小化、审计与准入策略，杜绝API Server、Dashboard、etcd暴露至公网。
关注点四：AI模型与数据资产防护。将模型文件按照可执行资产进行管理，落实来源可信、扫描反序列化风险、哈希校验等要求，训练数据与向量库单独划分防护域，为推理API做好越权与注入防护，将模型API Key、算力凭据这类关键凭据纳入托管并定期轮换。
关注点五：GPU资源隔离与算力安全。制定GPU共享策略时需要评估侧信道与干扰风险，高敏感训练任务应当独占物理GPU；建立GPU任务审计与算力对账机制，重点监控“高占用低产出”的异常任务。
关注点六：运行时检测与微隔离。部署容器行为基线与逃逸特征检测，落实NetworkPolicy默认拒绝规则与服务间最小访问权限配置，避免出现“单点失陷、全网横向移动”的问题。
关注点七：AI赋能的检测响应能力建设。在告警降噪、攻击链还原、自动化响应环节系统性引入AI技术，同时通过紫队演练持续检验AI检测能力的对抗有效性，避免“AI防御”流于形式。
关注点八：合规与责任体系。将等保三级、数据安全与AI治理要求映射到容器平台的制度与流程中，明确平台、安全、业务三方责任矩阵，让安全要求可考核、可追溯。
7.2 十条注意事项
在实施层面，以下十条注意事项来自多年一线实践的经验总结，务必在日常工作中落实。
一是不要把容器当虚拟机管理：容器生命周期短、密度高，主机化的周期扫描与人工巡检模式必然失效，必须平台化、持续化。二是不要迷信单一工具：镜像扫描、运行时检测、准入控制、网络策略各管一段，缺一环即破一环。三是不要在镜像里存放明文凭据：凭据一律走Secret管理+加密存储，并在CI/CD中做密钥扫描。四是不要忽视”低权限”事件：容器内的任何异常执行都可能是攻击链前兆，处置要按”可能正在升级”来评估。五是不要放行特权与敏感挂载：任何”临时需要特权”的诉求都应走替代方案（Sidecar、专用节点池）而非放松基线。六是不要让AI资产游离于安全视野之外：模型仓库、算力平台、推理服务必须纳入统一资产台账与监控体系。七是不要在事件后急删现场：容器易失联的特点下，Pod被删即证据消失，应先取证（镜像、日志、网络连接快照）再处置。八是不要忽略研发侧安全：供应链与模型投毒针对的是人，制度要延伸到研发流程与人员意识。九是不要照搬互联网大厂方案：要以自身等保等级、资产规模与团队能力量身裁剪，优先做暴露面收敛与凭据治理这类高性价比措施。十是不要让防御停在建设期：容器安全能力要用演练校验、用指标运营、用威胁情报保鲜，否则一年内即告失效。
7.3 常见误区与纠偏
实践中普遍存在四个常见误区。
误区一：“只要给容器做漏洞扫描就足够安全”——纠偏：漏洞扫描仅能解决已知的静态风险，运行时攻击与零日逃逸必须依靠行为检测与纵深控制才能防护。
误区二：“部署在内网就足够安全”——纠偏：容器网络默认互通，横向移动速度极快，内网对攻击者而言只是下一步的攻击目标，微隔离防护必须落实。
误区三：“我们不使用公网镜像，不存在供应链安全问题”——纠偏：包依赖、基础镜像层、模型文件依然属于外部输入，只要存在外部输入就会有供应链风险。
误区四：“部署AI检测平台就能高枕无忧”——纠偏：AI检测同样面临对抗绕过与误报治理问题，必须以检出率、误报率、MTTR这类运营指标持续校验，还要通过红紫对抗检验其真实防护有效性。
第八章总结与展望
本次培训围绕“AI时代的容器安全攻防实践”展开，从安全挑战、攻击面分析、防御体系、常见攻击场景到案例剖析，再梳理建设关注点与注意事项，搭建起了完整的知识框架。核心结论可概括为三点：第一，容器安全已进入“AI时代”的新阶段，攻击面从传统的镜像、运行时、编排三个平面，扩展为叠加模型供应链、推理服务、GPU资源的七个平面，仅沿用传统容器安全思维的企业，必然会出现体系性防护盲区。第二，攻防对抗的胜负关键正在向“自动化与AI能力”转移，防御方必须完成从单一设备堆叠向平台化、AI化运营的转型，落实“秒发现、准研判、快处置”的安全闭环。第三，防御体系能否落地，不取决于技术的先进性，而取决于配套制度与责任体系——可信供应链制度、基线准入的刚性约束、凭据与Secret治理、面向AI资产的单独立域防护，才是所有技术能力发挥效用的核心基础。
展望未来三年，容器安全攻防将呈现三大趋势：一是AI智能体将深度介入攻防两端，“Agent化攻击链”与“Agent化响应链”的对抗将成为核心主线，防御方需尽快搭建可编排的自动化响应能力；二是机密计算（TEE）与GPU可信执行环境将逐步成熟，可为模型与数据提供强隔离底座，值得在AI平台规划阶段提前布局；三是容器安全与AI安全治理将走向融合，统一的“云原生+AI资产”安全运营平台将成为企业标配。对安全从业者而言，唯有保持攻防实践常态化、能力更新常态化，才能在AI时代的容器安全博弈中立于不败之地。
附录A 容器安全自评估Checklist
本次整理的自评估清单按五大类共24项编制，建议各团队每季度对照开展一次评估，并将评估结果纳入安全绩效考核。
一、镜像与供应链（6项）
1.生产镜像是否仅来源于企业私有可信镜像仓库，是否禁止直接从公共仓库拉取镜像？
2.CI/CD流程是否强制执行镜像漏洞扫描，存在高危漏洞未修复时是否阻断镜像出库？
3.生产环境部署镜像时是否校验镜像签名，能否防止镜像在仓库到运行时的传输过程中被恶意替换？
4.是否已建立SBOM依赖清单，在1day漏洞爆发后能否1小时内完成依赖级的影响面定位？
5.是否统一管理可信基础镜像（含AI框架镜像），并定期更新、下线老旧版本？
6.AI模型文件是否仅允许从可信模型仓库获取，加载前是否完成反序列化风险扫描与哈希校验？
二、运行时与逃逸防护（5项）
1.生产环境是否全面禁止特权容器，例外场景是否走审批与专用节点池？
2.容器是否默认启用seccomp/AppArmor，capabilities是否按白名单收紧？
3.是否禁止挂载宿主机敏感路径（如/、/var/run/docker.sock等）？
4.是否部署容器运行时行为检测，覆盖进程/文件/网络三类基线与典型逃逸特征？
5.运行时组件（runc/containerd/nvidia-container-toolkit）是否纳入高危漏洞小时级应急机制？
三、编排平台与集群安全（5项）
1.API Server、etcd、Dashboard以及AI平台管理界面是否全部收敛至内网，并且全部启用强身份认证？
2.是否启用RBAC最小权限原则，并定期开展权限审计，默认ServiceAccount Token自动挂载功能是否已经禁用？
3.是否通过准入策略强制执行非特权运行、禁用hostPath挂载、限定可信仓库等安全约束？
4.是否开启K8s审计日志并对集群资产进行实时清点，能否即时回答“当前有多少Pod、多少GPU任务正在运行”？
5.是否按业务域启用NetworkPolicy默认拒绝规则，核心数据服务是否仅开放白名单访问？
四、AI资产与数据安全（4项）
1.模型仓库、算力调度平台、推理服务是否已纳入统一资产台账与攻击面管理？
2.推理API是否配置了认证、限速与越权防护，插件与Agent能力是否落实了最小权限原则与审计约束？
3.GPU任务是否建立了审批与算力对账机制，能否快速识别高算力占用、低产出的异常任务？
4.训练数据、向量库与模型存储是否划分了独立安全域，集群内云凭据是否遵循最小权限原则并定期轮换？
五、检测响应与运营（4项）
1.是否已建成容器安全统一运营平台，实现资产、风险、告警的集中可视化展示与关联分析？
2.是否已预置恶意镜像、容器逃逸、凭据泄露、GPU劫持四类场景的响应剧本，并完成过实战演练？
3.是否对运行时检测能力开展过红队验证（含AI辅助攻击模拟），检测检出率是否符合要求？
4.是否建立了供应链威胁情报订阅与响应机制，恶意包、恶意模型类情报触发后能否支撑全量回溯排查？
附录B 相关法规标准速查
| | | |
| — | — | — |
| 序号 | 名称 | 与容器安全的关系 |
| 1 | 《中华人民共和国网络安全法》 | 网络运行安全、安全事件处置与应急响应的总体法律依据 |
| 2 | 《中华人民共和国数据安全法》 | 训练数据与业务数据在容器环境中的分类分级与保护要求 |
| 3 | 《中华人民共和国个人信息保护法》 | 容器内个人信息处理活动与推理数据出境的合规底线 |
| 4 | GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》 | 云计算扩展要求，容器化系统定级测评的核心依据 |
| 5 | GB/T 25070-2019《网络安全等级保护安全设计技术要求》 | 等保三级系统安全技术框架设计参照 |
| 6 | GB/T 28448-2019《网络安全等级保护测评要求》 | 容器化系统测评实施与核查项依据 |
| 7 | GB/T 36637-2018《ICT供应链安全风险管理指南》 | 容器镜像与依赖供应链风险管理的参照框架 |
| 8 | 《生成式人工智能服务管理暂行办法》 | 大模型推理服务与训练语料安全的合规要求 |
| 9 | 《网络数据安全管理条例》 | 数据在云原生环境流转、跨境与事件的细化义务 |
| 10 | CIS Kubernetes Benchmark / CIS Docker Benchmark | 容器与编排平台安全配置基线的国际通行参照 |
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：小安伴你行 小安伴你行
小安伴你行《AI时代的容器安全攻防实践技术培训（下）》