人工智能几乎改变了软件开发和网络安全的方方面面。但或许最深刻的变化,正发生在一个传统上未受到足够战略重视的领域:企业如何管理软件漏洞。

基本的漏洞管理模式多年来一直相对固定:扫描软件、识别CVE、分配严重性评分、对结果进行优先级排序,然后交给开发人员修复。这种方法从来都不是对风险的完美呈现。但在AI时代,其局限性已变得难以忽视。

问题不仅仅在于企业需要处理的漏洞数量增多。软件产出量正在快速膨胀,漏洞发现速度不断加快,开发利用程序所需的时间也在缩短。借助AI的攻击还能以人工难以预先察觉的方式组合多个漏洞,形成复杂的攻击路径。

结果是,安全团队能够识别的漏洞数量与他们能够真正调查和修复的漏洞数量之间的差距正在不断扩大。我们需要通过改变提问方式来缩小这一差距。与其问"我们有多少个CVE",不如问"哪些漏洞在我们的环境中构成了真正的风险"。

严重性不等于风险

CVE告诉我们公开识别出的某个安全漏洞确实存在。但它本身并不能说明该漏洞针对特定企业被利用的可能性有多大。这一区别至关重要。

例如,通用漏洞评分系统(CVSS)的设计初衷主要是传达技术严重性以及漏洞被成功利用后的潜在影响。但严重性并不一定能告诉我们是否存在利用程序、该漏洞是否正在被实际利用、存在漏洞的组件是否暴露在外,或者在特定环境中是否会执行存在漏洞的代码路径。

因此,两家企业环境中可能存在完全相同的CVE,但面临的风险水平却可能大相径庭。一家企业的脆弱组件可能被多层防护层层包裹,没有外部暴露,也没有相关的执行路径。

CVE相同,风险却不同。

另一家企业的同一组件可能运行在面向互联网的生产应用中,支撑着关键业务流程。CVE相同,风险却不同。

这正是为什么基于静态严重性评分构建的漏洞管理项目,可能会产生一种误导性的进展感。团队可能花费大量精力关闭了大批漏洞记录,却未必真正降低了企业最关键的风险敞口。我称之为"CVE剧场":衡量的是活动量,而非真正有意义的风险降低。

AI正在改变漏洞利用的经济规律

这一转变的紧迫性正被AI进一步放大。正在开发的代码量急剧增加。即便每行代码的漏洞密度有所下降,软件总量的巨大增长也可能导致整体风险敞口扩大。与此同时,现代软件中越来越大的比例依赖开源组件,这扩大了企业必须理解和保护的代码范围。

攻击者也从自动化中受益。以往需要大量人工投入的任务,如今越来越多地能够借助AI加速完成。更多的漏洞与不断压缩的利用时间窗口相结合,造就了一个根本不同的安全环境。

这意味着企业无法再承受依赖冗长、串行人工分类流程的漏洞管理方式。安全项目必须变得更加情境化、持续化、自动化。

从减少风险源头开始

改善漏洞管理最有效的方式之一,是不再只考虑漏洞出现后如何修复。我们还应该思考如何从一开始就减少进入环境的漏洞数量。这要从软件基础开始。

使用经过加固或精心策划的基础镜像与编程语言库,可以在应用部署之前就减少漏洞覆盖面。自有代码可以通过静态应用安全测试(SAST)和AI辅助代码扫描来处理,而配置缺陷则可以通过安全技术实施指南(STIG)等安全配置框架来识别。

这一点之所以重要,是因为漏洞只是软件安全的一个维度。一个系统可能CVE相对较少,却仍然因配置不当而危机四伏。过度的权限、薄弱的身份验证设置或其他配置问题,都可能给攻击者提供立足点或横向移动的机会。

STIG扫描通过对照既定的安全要求评估配置情况,解决了这第二个维度的问题。这些工具本质上是自动化的安全检查清单,能够识别甚至在某些情况下直接修复配置缺陷。目标应该是让软件在成为别人的修复难题之前,尽可能做到安全。

扫描实际运行中的内容

安全领导者应该考虑的另一个重要转变是:生产环境才是真相的来源。

历史上,企业往往在软件进入生产环境之前扫描注册表或代码仓库。这能提供有用的信息,但反映的是感知到的风险,而非实际部署的内容。生产环境会变化,镜像会变化,配置会变化,部署后还会披露新的漏洞。因此,企业需要了解实际运行中的内容,并需要持续评估。这正是生产环境扫描、可达性分析和环境上下文变得至关重要的原因。

网络可达性可以帮助判断系统是否可被外部访问。软件层面的可达性则能提供另一层洞察:存在漏洞的代码路径是否真正被执行?这些问题能够极大地改变修复的优先级。

构建基于风险的修复模型

一旦了解了实际运行的内容,下一步就是依据真正重要的情境来评估漏洞。这意味着要超越CVSS本身。

威胁情报能够提供重要信号。美国网络安全和基础设施安全局(CISA)的已知被利用漏洞目录(KEV)识别出已知正被利用的漏洞。利用预测评分系统(EPSS)则估算某个漏洞在特定时间窗口内被利用的可能性。这些信号随后可以与生产环境暴露情况、可达性、配置、业务影响以及漏洞暴露持续时间相结合。最终得出一个对工程团队更有用的问题:在这个环境中,我们应该优先修复哪个漏洞,为什么?

这与把一份包含数千个按严重性排序的CVE的电子表格直接交给开发人员,是截然不同的运作模式。

持续风险管理才是目标

最终目标不应该是一个完全清空的漏洞仪表盘。在现代软件环境中,这既不现实,也未必是衡量安全性的正确标准。目标应该是对实际风险持续加深的理解。这需要一种分层的方法:从安全的软件基础开始,扫描自有代码,加固配置,了解生产环境中实际运行的内容,判断可达性,纳入威胁情报,并根据真实世界的暴露程度和影响来排定修复优先级。这还需要时间纪律——不同类别的漏洞可能需要不同的修复时限,而不是对每个发现都一视同仁。

我们需要知道哪些门是开着的,哪些门攻击者能够到达,哪些门通向重要的地方,以及哪些门眼下代表着最大的风险。

AI已经让旧模式变得越来越难以为继。但它也给了我们一个机会,围绕更有意义的目标重新思考漏洞管理。我们不需要只知道软件里有多少扇门,我们需要知道哪些门是开着的,哪些门攻击者能够到达,哪些门通向重要的地方,以及哪些门眼下代表着最大的风险。

这就是计算漏洞数量与管理风险之间的区别。而在AI时代,这种区别正变得至关重要。

Q&A

Q1:为什么说传统的CVE评分体系已经不够用了?

A:CVE评分系统(CVSS)主要衡量的是技术严重性,而不是漏洞在特定企业环境中被实际利用的可能性。同样的CVE在不同企业中可能因暴露程度、配置和防护层级不同而带来截然不同的风险,仅凭严重性评分容易造成"看似在处理问题,实则风险未降"的假象。

Q2:AI是如何加剧漏洞利用风险的?

A:AI大幅提高了软件开发速度,导致代码总量激增,同时也让攻击者能够借助自动化更快地发现和组合漏洞、缩短开发利用程序的时间。这使得漏洞数量增多与利用速度加快同时发生,让传统依赖人工分类的漏洞管理方式难以跟上节奏。

Q3:企业应该如何改进漏洞管理方式?

A:建议采用分层策略:使用加固的基础镜像减少漏洞源头,通过静态代码扫描和配置检查提升基础安全性,持续扫描生产环境了解实际运行情况,并结合威胁情报、可达性分析等真实风险因素,优先修复真正构成威胁的漏洞,而不是简单按严重性排序处理。

The New Stack