使用漏洞扫描工具扫描资产进行排查是当前主要手段。但在需要扫描排查时，却发现自己的漏扫工具却不具备对新漏洞的扫描发现能力。需要等待厂家研发并更新扫描规则。中间这段等待空窗期，成为了高风险时段。

实际上，从新漏洞公布到网络运营者掌握漏洞对网内资产影响情况，由两个时间段组成：

只有尽可能的缩短这两个时间。才能更有效迅速的掌握漏洞对资产影响情况，跑赢风险暴露时间窗口。

那么问题就是，如何缩短这两个时间？在等待漏扫更新扫描规则的空窗期内，应该如何做？有没有其它的办法来排查掌握新漏洞对资产的影响情况？

并非是漏洞公布后，扫描工具就能自动扫描这个漏洞。从漏洞公开到漏扫工具具备扫描能力，这个过程并非自动发生的，而是一个包含漏洞情报获取、漏洞原理分析、漏洞复现、扫描规则编写、测试验证、发布的复杂工程链条。如下图所示：

从漏洞公布到漏扫工具可扫描，本质上是将人类可读的“安全公告”转化为机器可执行的“代码逻辑”的过程。关键路径：漏洞公布 -> POC 出现/原理明确 -> 提取特征（版本/流量） -> 编写脚本 -> 排除误报/防止崩溃 -> 推送到用户终端。这个工程链条所花费的时间称为 “检测延迟” (Time-to-Detect Gap)。

更新时间首先取决于漏洞的复杂性、利用代码（PoC）的可获得性以及漏洞本身的影响力，与包括不限于如下四种因素相关。

除与漏洞自身的特性有关外，与厂家自身的研究和响应能力有关。因此出现不同漏扫工具厂家对同一个漏洞扫描规则更新时间不同、同一个漏扫工具厂家对不同漏洞的扫描规则更新不同的情况。

漏扫工具的扫描规则更新时间窗口没有一个固定的标准值，它的跨度非常大，从几个小时到数周甚至数月，延迟的响应时间大致可分为极速响应、标准响应、延迟响应三种。

根据历史数据统计，对于有CVE编号的漏洞，从披露到主流扫描器具备检测能力的平均时间大约在5-7天左右。

漏扫工具扫描规则延迟不是由于厂商懈怠，而是规则机制决定了必然滞后（必须有PoC、必须防崩溃、必须测试等）。因此，在0-day/1-day漏洞面前，依赖漏扫工具升级规则是“刻舟求剑”。

这些措施中，CMDB数据往往不准、流量防御由于加密流量或规则滞后存在漏网之鱼。必须要有更精准的“资产-漏洞”映射能力。不再等待扫描器学会“怎么扫”，而是直接利用“资产情报”匹配“谁受影响” 。

从以上典型案例可以看出，玄猫早于NVD提供漏洞影响产品数据，助力运营者能够尽早进行资产漏洞排查。通过持续监测、影响产品不仅限于NVD公布的React、Next.js组件，还包括其它已公告的受此漏洞影响的产品和组件。助力运营者能够排查更深更广的漏洞影响资产。

通过SaaS平台提前预警，通过API接口赋能用户资产漏洞排查，在以资产视角“非扫描”方式，快速排查资产漏洞风险，消灭漏洞检测“空窗期”，从“被动等待”向“主动防御”转变。

通过摄星玄猫的资产风险情报，运营者可彻底消灭“等待扫描规则更新”的焦虑，实现“无扫描、零接触、快响应”的漏洞治理新常态。