当前位置:当前位置:首页 >系统运维 >高危漏洞并不意味着要最先修复 正文

高危漏洞并不意味着要最先修复

[系统运维] 时间:2025-11-27 01:53:32 来源:设计引擎 作者:系统运维 点击:186次

安全团队每天都会被越来越多的高危漏洞所淹没,但通过改变漏洞的漏洞优先级 ,可以极大地减少修补工作量。意味

大多数企业都会关注通用漏洞评分系统(CVSS)框架中对缺陷的着最评分 ,评分范围从0到10 ,先修并根据漏洞的高危特点,分为低、漏洞中、意味高和极危。着最一般而言 ,先修企业会从被视为“极危”的高危漏洞开始补救工作,然后再高中低逐级往下解决。源码下载漏洞

但现实情况是意味 ,对于许多企业来说 ,着最大多数漏洞都不会对它们构成威胁 。先修安全公司Rezilion在5月发布的一项研究报告显示 ,组织中约85%的漏洞并没有加载到内存 ,也就意味着不能够真正被利用。(Rezilion成立于2018年 ,专注方向为自动化的攻击面管理)

在这项研究中,Rezilion的研究人员检查了Docker Hub上20种流行的容器镜像,这些镜像总共被下载和部署了数十亿次 ,云计算包括MariaDB 、WordPress 、Memcached、MongoDB 、Nginx和MySQL 。此外 ,他们还研究了来自AWS 、Azure和GCP的基本操作系统镜像  ,以确定有多少漏洞不适用,又有哪些漏洞构成了实际风险 。

在Rezilion研究人员分析的21种容器镜像中,有4347多个已知漏洞 ,但经测试后发现,只有平均15%的模板下载CVE漏洞曾加载到内存中并构成威胁。研究人员还在分析的12个基本操作系统镜像中发现了6167个已知漏洞 ,其中约有20%加载到内存中。

因此报告得出结论 ,容器和主机中发现的所有漏洞 ,有85%从未加载到内存,因此不可利用 。如果使用传统的漏洞管理方法,人们将花费85%以上的时间和精力来修补对环境没有实际风险的漏洞 。

不仅如此,在实际的源码库漏洞修补工作中,许多补丁是手动打上的,更为糟糕的是 ,有些漏洞的性质很难快速进入修补流程,时间长的可能需要几个月,往往还需要系统停机 。

一方面 ,组织在处理漏洞和补丁管理方面的资源和能力十分有限。另一方面漏洞发现和披露的香港云服务器数量逐年增加 。因为只要人们编写代码,漏洞就会出现,修补工作就跟不上。因此,一个看上去比较合理化的建议是,首先处理实际加载到内存中的漏洞  ,如果再有额外的时间或资源再处理其他的漏洞 。因为只有这些能够进入到内存中的漏洞,才是高防服务器真正重要的 ,真正构成威胁的漏洞 。

但问题是,那些从未加载到内存的漏洞真得没有风险吗?谁能保证这些漏洞以后不会加载到内存?理论上而言 ,存在漏洞的软件,即使没有运行 ,仍然存在风险 。因此  ,一个非常有效且简便易行的方法就是,删除那些执行指定任务时系统不需要的软件 。

方法论有了 ,但最大的问题在于 ,现实中的大多数组织缺乏对其所有信息资产的了解,也不知道哪些软件程序的哪些部分会加载到内存中 。所以 ,一切又回到了对企业资产环境的充分了解上。

​不清楚保护对象,何谈保护  ?

不管怎样,组织面临的风险永远存在,修补能力也永远赶不上漏洞的增长 。回归到最佳实践上,那就是合理利用现有的资源、工具和预算  ,将工作重点放在与自身更相关的漏洞上。​

(责任编辑:人工智能)

    相关内容
    精彩推荐
    热门点击
    友情链接