2020年,成为科技行业的警示,突显了组织在应对关键CVE(常见漏洞和暴露)及安全事件时的紧迫需求。这一事件促使许多公司重新审视其运营框架,特别是其开源供应链的透明度和安全性。组织们意识到填补流程空白和赋予开发人员安全开发实践知识的关键性,开始探索如何引导开发人员。
在SolarWinds供应链攻击之后,2021年发生了涉及,这是一个广泛使用的Java日志库,暴露了其漏洞。最近震撼行业的事件是,这可能又是一场大规模开源供应链攻击。技术与社交工程的结合,几乎让整个世界陷入危机。
被利用的漏洞可能对组织造成巨大的经济影响。2021年7月,,这是一款被管理服务提供商(MSPs)广泛使用的IT管理软件。攻击者利用Kaseya软件中的一个漏洞,,影响了MSPs及其客户。攻击者索要7000万美元的赎金。
不仅大型组织容易遭受利用CVE(描述单个漏洞的唯一标识符)的攻击,小型企业也常常成为目标。显示,超过40%的网络攻击发生在小型企业身上。然而,做好了防备。
开源项目对开发人员来说极其有用,因为它们提供 ready-made的解决方案,可以轻松集成到新软件中,从而节省时间和资源。然而,这种便利性也有隐患。这些开源组件有时是过时的、不再维护的,或者缺乏对安全性的强烈关注。组织们还受制于缺乏应对新漏洞的策略,尤其是在应用内的使用情况。然而,大部分上游项目在及时发布修复和更新方面做得相当不错。问题在于,尽管修复版本可用,下游消费者仍然会继续下载和使用已知的易受攻击版本。
当开发人员将某些项目集成到其软件中时,可能会无意间引入可被网络犯罪者利用的漏洞,通常是通过依赖关系传递进行的。虽然主要用于安全的应用程序本身可能是安全的,但底层的库和组件在部署者未曾知道的情况下,可能会带来风险。这种情况下,组织更容易受到攻击,因为他们可能并不知道其软件依赖的易受攻击组件,也没有迅速有效的响应计划来应对潜在的攻击。
为了有效应对开源软件中的CVE,组织应优先建立全面的资产清单。此外,为应用程序生成至关重要,因为它们提供了用于消费软件组件清单信息的标准化格式,尽管SBOM并不是解决所有问题的银弹。SBOM的格式和内容在实际执行中差异极大。开源组件通常也可以在商业第三方软件中发现。的确,来自Synopsys的""显示,近乎所有(96%)的代码库中都含有开源组件。
与第三方供应商合作的组织应在合同谈判中要求其提供SBOM,这将帮助组织了解其第三方软件中的任何漏洞,并追究供应商修复漏洞的责任。了解您的关键资产及其所包含的开源组件,有助于在应对关键CVE时进行高效的排查处理。
利用软件组成分析(SCA)工具可以有效地构建SBOM,并检测与这些组件相关的已知CVE。根据开放全球应用安全项目(OWASP)的定义,是识别使用第三方和开源软件及硬件组件时,潜在风险区域的过程。
这些工具通过自动创建软件组件及其相互依赖关系的全面清单来提高效率。它们执行扫描以识别过时组件,并检测任何相关的已知CVE。然而,由于缺乏普遍接受的标准来命名和版本化这些组件,扫描器供应商往往面临准确识别软件的挑战,导致较高的误报率。
这一问题给企业带来了显著的运营负担,需要对扫描结果进行验证。此外,为了控制成本和开销,这些扫描工具通常依赖于国家标准技术院(NIST)的国家漏洞数据库(NVD),而该数据库自身在数据质量和更新及时性方面也存在问题。
此外,扫描器在提供准确的CVE数据时常常会遇到数天、数周甚至数月的延迟。组织必须将这些扫描设置为定期自动运行在所有包含开源软件组件的应用程序上。一些工具提供监控应用程序在运行时实际使用哪些库的功能,以帮助安全团队和开发人员优先处理需要修复的安全问题。,包括免费、开源和商业许可的工具。
没有来自拥有和支持应用程序的开发团队的支持,漏洞的补救是不可能实现的。针对安全主题进行的开发人员培训和设立安全倡导者,以促进安全意识和最佳实践是至关重要的。建立一个清晰的过程,以使开发人员能够在面对如Log4jCVEs的事件时迅速并协调地响应至关重要。
此外,在将一个漏洞认定为组织的“关键”之前,进行影响分析是重要的。为关键CVE定义上报路径,具体说明何时报告的漏洞升级为事故,并确保遵循所有正确的事故管理流程,以最小化对组织运营的影响。
Leave a Reply