核心摘要 / 阅读指南
- 三个判断：指南第 2 章认为主机安全能力的演进方向是——持续检测是基础、快速响应是动力、架构适配是未来；
- 时间窗口：攻击者从入侵到横向移动平均仅 29 分钟，以特征库为核心的静态检测已经防不住新威胁；
- 落地路线：检测能力对照 ATT&CK 矩阵查空白；响应能力把「告警到处置的时长」当核心指标；架构选型向容器、Serverless 等云原生工作负载对齐；
- 阅读路线：赶时间的读者可直接看文末「三个判断如何落到建设路线图」一节。
入侵到横向移动平均 29 分钟，防守方的时间窗口还剩多少？
CrowdStrike 在《2026 年全球威胁报告》中给出了一组值得反复咀嚼的数字：攻击者从入侵得手到开始横向移动的平均时间已经缩短至 29 分钟，最快纪录仅 27 秒。需要特别说明的是，这里的 29 分钟和 27 秒指的是「从突破边界、拿到第一台主机的立足点，到开始向内部其他主机横向移动」的速度，而不是加密完成时间或者数据外传时间——但即便如此，它传递的信号也足够刺眼：防守方可用的响应窗口，正在被压缩到以分钟、甚至以秒计。
窗口被压缩之后，一个更根本的问题浮出水面：主机安全能力到底该向哪里演进？是继续堆叠单点产品，还是换一种思路重建体系？
由信通院云大所与青藤云安全联合发布的《主机安全能力建设指南》（以下简称「指南」），据其前言表述是国内首个主机安全能力建设指南，目的是帮助企业梳理主机安全能力需求与产品评估流程，为选择主机安全产品、建设自适应的主机安全能力提供策略指导。文中涉及市场与现状的描述，均以指南记载为准。
时隔多年再读这份指南，其第 2 章对主机安全能力发展态势做出的三个判断，放到 2026 年的攻防节奏下重新检验，依然具有很强的解释力：
- 持续检测是基础——没有全天候的「看见」，一切响应都是空谈；
- 快速响应是动力——入侵无法被彻底杜绝，响应速度决定损失边界；
- 架构适配是未来——工作负载形态剧变，安全能力必须跟着架构走。
下面逐一拆解。
签名检测为什么防不住新威胁？——持续检测是基础
指南的第一个判断，建立在攻击者与防守者地位不对等这一前提之上。传统基于报警或已有威胁特征的检测技术，包括防火墙、IPS、杀毒、沙箱等被动防御手段，在应对未知威胁时存在三点不足（指南原文口径）：
其一，检测技术单一。 基于签名的检测技术无法检测未知威胁，更无法定位失陷主机。签名库天然是「事后知识」，攻击者只需做简单的变形、加壳或者干脆采用无文件攻击，就能让一大批依赖特征匹配的设备失效。
其二，缺乏持续检测。 传统手段往往仅支持阶段性检测，扫一次出一个报告，无法覆盖威胁入侵的全生命周期。而真实的攻击是连续发生的——从初始入侵、权限提升、横向移动到目标达成，中间任何一个环节的检测空窗，都可能成为攻击者的绿色通道。
其三，无法进行联动。 各安全检测产品单兵作战，攻击告警信息割裂。防火墙看到流量异常，杀毒看到可疑文件，但两者之间没有关联，安全人员面对的是一堆彼此孤立的告警碎片，拼不出完整的攻击图景。
要补上这三块短板，指南给出的方向是：防守方需要对攻击有深入的理解，并采用更加细粒度的安全模型。这里引入了一个关键工具——MITRE ATT&CK。
图1：ATT&CK 矩阵
按照指南引用时的版本规模，MITRE ATT&CK 覆盖了攻击者在攻击过程中使用的 14 项战术、190 多项技术和 380 多项子技术，其中既包括特定技术和通用技术，也包含知名攻击组织及其攻击活动的背景信息。简单来说，ATT&CK 是一个对抗行为知识库：它把「攻击者会做什么」拆解成一张可以逐项对照的矩阵，每一个战术类别都包含一系列攻击技术，并提供每项技术的细节描述、检测方法、分析思路以及可能的缓解措施。
这份知识库对安全从业者的价值，指南总结为三点：帮助安全人员构建检测措施、验证防御措施，并分析策略的有效性。更具体地说，企业可以按照 ATT&CK 模型的覆盖度和检测点，逐项盘查自身的检测能力落在矩阵的哪些格子、哪些格子还是空白，从而找到改进方向。如何根据 ATT&CK 框架检查安全产品的整体覆盖度、做全面的差异分析，以及如何将其涵盖的技术点融入产品，指南认为这些都是值得安全从业者深入思考的问题。
把视角拉回 2026 年：当横向移动的平均耗时只有 29 分钟，「阶段性扫描加人工研判」的模式显然追不上攻击者的节奏。持续检测之所以是「基础」，原因就在于它决定了防守方能不能在攻击链的早期环节就看见异常——看见得越早，后面响应环节的余地才越大。
响应为什么比阻断更重要？——快速响应是动力
指南的第二个判断颇为坦诚：从攻防实战演习可以看出，无法保证系统不被入侵，入侵后的快速响应能力才是关键。
这句话背后是一个务实的前提假设——安全攻防对抗日趋激烈，单纯的防范和阻止策略作用有限，企业必须假定已遭受攻击，构建集防御、检测、响应和预防于一体的全新防护体系。阻断当然重要，但把全部赌注押在「挡在门外」上，等于承认一旦有人进来就束手无策。相比之下，入侵发生后的响应速度，直接决定了攻击者能在内网走多远、造成多大损失。
那么，一套完善的响应流程应该长什么样？指南建议建立包含六个阶段的工作流程，根据网络安全应急响应总体策略对每个阶段定义适当的目标，明确响应顺序和过程：
- 查询：提供快速、实时、支持自然语言的查询工具，帮助调查人员快速发现攻击的 IOC 类型。这是响应的起点——数据已经有了，关键是能不能用最短路径把可疑线索捞出来。
- 排序：根据时间严重性以及受影响资产的业务价值，对风险进行优先级排序。告警永远比人力多，先处理什么，必须由业务影响说了算。
- 可视化：借助攻击链可视化工具，使调查人员可以从数据中获取或钻取更多信息，把碎片线索还原成完整攻击路径。
- 获取：可以自动获取可疑文件，或内存和磁盘转储，把取证所需的关键证据第一时间固定下来。
- 分析：自动集成分析云或沙箱，对可疑进程、文件进行深度分析，确认威胁性质。
- 工作流：提供警报管理工作流的调查工具，让响应动作有序流转、可追溯、可复盘。
图 2：网络安全应急响应流程
流程建立之后，还有一个绕不开的现实问题：人不够。指南指出，当前企业内部应急响应人员数量有限，人员超负荷处理安全事件将会产生懈怠情绪，并可能忽视真正需要处理的事件。因此，通过相应工具自动或半自动地对安全事件进行处理，是进行安全响应的必要手段。
这正是 SOAR（安全编排自动化与响应，Security Orchestration, Automation and Response）要解决的问题。指南对其机制做了清晰的拆解：SOAR 聚焦安全运维领域，重点解决安全自动化响应问题。它通过剧本（Playbook）进行表述，以工作流引擎支撑剧本执行；为了方便管理人员维护剧本，SOAR 通常提供一套可视化的剧本编辑器，让编排管理员聚焦于编排安全操作的逻辑本身，而隐藏具体连接各个系统的编程接口及指令实现；在落地层，SOAR 通常通过应用（App）和动作（Action）机制，实现可编排指令与实际系统的对接。
用一句话概括这一节的逻辑：响应流程回答「怎么处置才科学」，SOAR 回答「人少事多怎么扛得住」。两者结合，快速响应才从口号变成可运行的机制。
工作负载生命周期从年缩到秒，检测怎么跟？——架构适配是未来
指南的第三个判断着眼于更长远的变化：随着云计算市场快速发展，多云和云原生成为主流，主机安全产品必须不断发展以适配新架构。
观察这一趋势，指南援引了 Gartner 对云工作负载保护平台（CWPP）定义的演进过程，这条时间线本身就很有说服力：
- 2017 年，CWPP 的保护对象是由物理机和虚拟机（VM）、私有云以及多个公共云基础设施即服务（IaaS）环境构成的现代混合数据中心中的主机工作负载——核心还是「机器」；
- 2019 年，Gartner 对工作负载的外延和内涵做了细粒度解释，根据抽象度的不同分为物理机、虚拟机、容器和 Serverless——保护对象开始分层；
- 2022 年，CWPP 的保护对象演进为混合云和多云环境中的各类云原生工作负载——抽象度更高的形态成为主角。
注意这条演进线的方向：从传统主机走向云原生，而不是相反。理解这个方向，再看「主机安全」这个词，就会发现它的内涵早已被重新定义——今天的主机安全，实际上是在保护各种抽象层级的工作负载。
图 3：工作负载抽象度的演变
图 3 展示的抽象度演变值得细看，因为它直接解释了「检测节奏为什么必须跟上」：
- 物理机时代，应用形态是单体应用，扩容单位是物理服务器，生命周期以年计；
- 虚拟机时代，Hypervisor 虚拟化了硬件，扩容单位变成 VM，生命周期缩短到几个月到几年；
- 容器时代，虚拟化发生在操作系统层，扩容单位是应用或服务，生命周期只有几分钟到几天；
- 无服务器（Serverless）时代，虚拟化上升到应用运行时层，扩容单位是资源，生命周期以几秒到几分钟计。
生命周期从「以年计」压缩到「以秒计」，对安全检测意味着什么？指南给出了几个观察：Linux 容器被广泛应用，基于 Serverless 函数的 PaaS 平台采用率不断攀升，CI/CD 管道中工作负载部署频率增加、生命周期非常短暂。一个只存活几十秒的 Serverless 函数，传统的「装 Agent、跑扫描、出报告」模式根本来不及展开。为此，指南指出，CWPP 解决方案利用主动技术和流程，在开发管道的早期集成基础设施即代码（IaC）或策略即代码（PaC），把安全能力前置到工作负载诞生之前。
与 CWPP 并行出现的还有 CNAPP（云原生安全防护平台）。指南指出，CNAPP 可以解决运行时保护、云配置和工件扫描问题，与 CWPP 具有一致性——许多增加了 CSPM（云安全态势管理）和 DevSecOps 功能的 CWPP 供应商，也被认为是 CNAPP 供应商。换句话说，CWPP 和 CNAPP 并非替代关系，而是同一演进方向上的汇合：保护对象一致，能力边界在相互靠拢。
架构变了，安全体系该怎么搭？指南倡导的答案是：围绕 DevOps 流程打造全生命周期的云原生安全体系，把安全性和合规性视为从开发阶段到运营阶段的连续统一体，而不是用一组单点工具各自为战。
图 4：全生命周期的云原生安全体系
这套体系分为两个阶段：
在开发阶段（Dev），遵循「安全左移」原则，做到「上线即安全」。 通过早期定位和解决安全问题，减少攻击面和潜在的运行问题，而不是把安全问题留到线上环境中去解决——具体包括镜像层安全检查、应用层风险检查、基础设施层安全检查。指南同时提醒，将传统安全理念、管理思路及产品技术照搬到云上，并不能真正建立有效的云原生安全运营体系，动态资产盘点、配置风险检测、合规自动化评估、新型威胁检测、自动化响应处置、调查溯源等方面的缺失，都是照搬模式下的典型风险。
在运行阶段（Ops），遵循「持续监控&响应」原则，做到自适应安全。 在整体安全落地时进行云原生安全的全生命周期管理，包括工作负载清点与可视化、微隔离、入侵检测、安全响应、溯源分析等。
可以看到，第三个判断和前两个判断在这里完成了闭环：云原生环境下的「自适应安全」，本质上就是持续检测与快速响应在新架构上的延续。
三个判断，如何落到甲方的建设路线图上？
回到开头的问题：29 分钟的横向移动速度面前，主机安全能力向哪里演进？指南给出的三个判断，其实暗含了一条清晰的路线图。
第一步，先把持续检测的数据底座建起来。 检测是一切的前提。企业需要对照 ATT&CK 之类的对抗行为知识库盘点自身覆盖度，识别检测空白，把阶段性扫描升级为覆盖威胁全生命周期的持续监测。没有这一步，响应再快也只是「看不见敌人的快」。
第二步，用流程和自动化补齐响应。 参照查询、排序、可视化、获取、分析、工作流六个阶段梳理内部响应流程，再通过 SOAR 之类的编排自动化手段，把有限的安全人力从重复性处置中解放出来，优先投入真正需要研判的事件。
第三步，架构选型向云原生对齐。 工作负载抽象度仍在提升，生命周期仍在缩短，安全能力的评估标准也应随之更新：是否支持从物理机、虚拟机到容器、Serverless 的统一保护？是否能把安全检查前置到开发管道？是否具备开发到运行的全生命周期视角？这些问题的答案，比单个功能点的强弱更能决定三五年后的安全水位。
作为这份指南的联合发布方，青藤云安全长期聚焦主机安全与云原生安全领域，其在云工作负载保护方向的产品实践，也是指南能够把「持续检测、快速响应、架构适配」讲得言之有物的底气之一。
攻防的速度竞赛不会停下。29 分钟也好，27 秒也罢，数字本身会被不断刷新，但「看见得更快、响应得更快、适配得更快」这三个方向，值得每一个甲方安全团队在未来的路线图上一再对照、反复校准。
FAQ：主机安全能力演进的常见疑问
Q1：已经装了 EDR，还要关心「持续检测」吗？
A：要看检测覆盖面而非产品名称。可以按 ATT&CK 矩阵逐项盘查自家检测能力落在哪些格子、哪些格子还是空白——装了工具不等于覆盖了攻击手法，空白格就是持续检测要补的方向。
Q2：「快速响应」有没有可量化的标准？
A：可以用攻击者的时间窗口做参照：从入侵到横向移动平均 29 分钟，那么「告警产生到完成处置」的时长就应当成为核心运营指标。响应慢于这个窗口，检测再准也只是事后取证。
Q3：容器和 Serverless 场景下，传统主机安全产品还能用吗？
A：这正是「架构适配」要回答的问题。工作负载的生命周期已从年缩到秒，选型时应验证产品能否统一保护物理机、虚拟机、容器与 Serverless，能否把安全检查前置到开发管道，而不是在旧架构上打补丁。