安全团队每天都被越来越多的漏洞所淹没，但是通过改变漏洞的优先级，可以大大减少修补工作量。大多数组织都希望在通用漏洞评分系统(CVSS)框架中对缺陷进行评分，该框架的范围从0到10，并根据漏洞的特性将漏洞分为低、中、高和严重。一般而言，公司会从被认为是“关键”的漏洞开始修复工作，然后通过高、高和低级别逐步解决。但现实情况是，对于许多企业而言，大多数漏洞不会对他们构成威胁。根据安全公司Rezilion在5月份发布的一份研究报告，组织中大约85%的漏洞没有加载到内存中，这意味着它们无法被真正利用。（Rezilion成立于2018年，专注于自动化攻击面管理。）在这项研究中，Rezilion的研究人员检查了DockerHub上的20个流行的容器镜像，这些镜像总共被下载和部署了数十亿次，包括MariaDB、WordPress、Memcached、MongoDB、Nginx和MySQL。此外，他们查看了来自AWS、Azure和GCP的基本操作系统映像，以确定有多少漏洞不适用以及哪些漏洞构成了实际风险。在Rezilion研究人员分析的21个容器镜像中，有超过4347个已知漏洞，但经过测试发现，平均只有15%的CVE漏洞被加载到内存中并构成威胁。研究人员还在分析的12个基本操作系统映像中发现了6,167个已知漏洞，其中约20%被加载到内存中。因此，该报告得出结论，在容器和主机中发现的所有漏洞中，有85%从未加载到内存中，因此无法利用。使用传统的漏洞管理方法，人们会花费超过85%的时间和精力来修补对环境没有真正风险的漏洞。不仅如此，在实际的漏洞修补工作中，很多补丁都是人工打上的。更糟糕的是，某些漏洞的性质使其难以快速进入修补过程。时间长的话可能要几个月，而且经常需要系统停机。一方面，组织处理漏洞和补丁管理的资源和能力有限。另一方面，发现和披露的漏洞数量逐年增加。因为只要人写代码，就会出现bug，打补丁也跟不上。因此，一个看似合理的建议是先处理实际加载到内存中的漏洞，如果有额外的时间或资源，再处理其他漏洞。因为只有这些能够进入内存的漏洞才是真正重要的，真正构成威胁的。但问题是，那些永远不会加载到内存中的漏洞利用真的没有风险吗？谁能保证这些漏洞不会被加载到内存中？理论上，存在漏洞的软件，即使没有运行，也依然存在风险。因此，一个非常有效和简便的方法就是删除那些系统不需要执行指定任务的软件。方法论是存在的，但最大的问题是，实际上大多数组织缺乏对其所有信息资产的可见性，他们也不知道哪些软件程序的哪些部分被加载到内存中。因此，这一切都归结为对业务资产环境有很好的了解。不了解保护对象，谈何保护？无论哪种方式，组织面临的风险始终存在，修补能力永远跟不上漏洞的增长。回归最佳实践，合理利用现有资源、工具和预算，关注与自己更相关的漏洞。
