如今的漏洞管理工具会收集一些基础的数据，比如检测到的漏洞数量、受影响资产、严重性等。这些只能让安全团队监测到最需要修复的东西，但是这些工具无法提供能够提升修复成果的关联信息。比较成熟的团队会使用电子表格或者商业智能工具追踪一些数据矩阵，比如之前修复过的漏洞数量、依然存在的漏洞数量、以及最近一次扫描中发现的新漏洞数量。

虽然说这些数据也挺有用的，但是依然缺乏关联性，因此很少能为修复工作提供一个整体的视角。举例而言，它无法将一个漏洞的位置和受影响的业务单位关联、无法报告修复一个漏洞所需要的真正时长、也无法对漏洞修复优先级提出意见。这种类型的信息，恰恰是改善漏洞修复成果的基础。

▶ 真正需要的数据

安全团队不仅需要数据帮助他们基于业务风险对修复工作进行优化，还需要信息引导和推进流程的改善。真正需要的数据应该能帮助他们识别脆弱点，并且将修复的精力重新集中在最能影响自己最关键的业务的技术上。

举个例子，如果扫描器在第七行代码中发现了一个SQL注入漏洞，或者发现了一个需要进行补丁的Red Hat盒子，这些信息并没有告知受影响的具体产品、拥有者、或者对组织的重要性。这些漏洞是否有某些漏洞比其他漏洞会带来更多风险?如果无法同时修复，哪个漏洞应该得到更多关注?

另一个需要考虑的问题，在于因业务周期本身，产生的对受漏洞影响技术的依赖程度。举例说明，许多零售商管会在购物季面临更多的风险;而食品杂货店由于每个月都会有新的产品，因此会在不同的IT和业务单元中改变优先级。在这些情况下，漏洞管理团队需要更优质的数据，基于实时的业务需求进行修复决策。

接下来，修复团队需要理解某个修复会如何影响到业务运营。尽管说漏洞管理工具能够给出修复的平均时长，但是这个数据是基于每周的扫描得到的，依然缺乏关联性。上周报告的哪些漏洞已经被修复了?每个都花了多久修复?一天?五分钟过?还是 五天?

这些数据对于CISO们也是无价的。历史数据可以显示哪些平台的修复时间更长，以及相关原因。这些信息能帮助CISO们发现流程中的效率问题、产品脆弱性，甚至人员相关问题，从而着手考虑如何解决。

▶ 困境为何难以突破

改善漏洞修复流程的最大困难，在于相关的数据都被分散在许多不同系统中：扫描器中的漏洞数据、配置管理数据库或者资产库中的业务数据，甚至某些数据只在一些特定的人员手中。另一方面，安全团队可能在不同团队部署了多个漏洞管理工具——比如扫描漏洞的、威胁情报团队、IT运营人员等等，都使用不同的工具。

把这些问题聚集到一起，就是许多数据并不是由现有的工具所储存的：比如，很少有组织会追踪他们DevOps团队发现漏洞、安装补丁、检查补丁是否生效所花的时间长度。即使他们对这些时间长度进行了记录，也极少会将这个信息反馈给漏洞管理团队。

还有，一些漏洞管理工具会完全无视未储存的数据点。比如，如果CISO询问过去六个月修复了多少漏洞，大部分漏洞管理工具可能都没有相关数据。