查看原文
其他

OWASP发布10大开源软件风险清单

爱吃炸鸡 FreeBuf播客电台
2024-10-07

作者 | 爱吃炸鸡

编 | 疯狂冰淇淋


3月20日,xz-utils 项目被爆植入后门震惊了整个开源社区,2021 年 Apache Log4j 漏洞事件依旧历历在目。倘若该后门未被及时发现,那么将很有可能成为影响最大的软件供应链漏洞之一。近几年爆发的一系列供应链漏洞和风险,使得“加强开源软件(OSS)安全”的呼声越来越高,以维护脆弱的现在数字生态系统。



基于此,OWASP发布了开源软件风险清单TOP 10,旨在帮助企业用户更好地解决开源软件组件安全问题,帮助安全从业者更成熟地治理和安全使用OSS。风险清单TOP 10由Endor Labs首创,该公司专注于OSS安全、CI/CD管道和漏洞管理、软件供应链安全等。


传统漏洞管理获取已知漏洞的渠道,CVE漏洞库通常是重点关注来源之一,但越来越多的网安从业者都意识到,已知漏洞是风险的滞后性指标。


为了更好地应对风险,管理开源软件漏洞,网安人必须关注风险的先行指标,以便更快发现特定OSS库、组件和项目之间存在的威胁。



以下OWASP发布10大开源软件风险清单。



1. 已知漏洞


这部分内容涉及已知漏洞的OSS组件,如软件缺陷,这些缺陷通常是软件开发者和维护者无意中引入,然后由社区中的安全研究人员公开披露。


这些漏洞是否可被利用取决于它们在组织和应用程序中的使用环境。虽然这一点可能看起来微不足道,但实际上并非如此——未能为开发者提供这种环境会导致大量辛苦工作、浪费时间、挫败感,以及常常对安全部门产生抱怨。


针对这些风险,美国网络安全与基础设施安全局(CISA)会公布已知被利用漏洞(KEV)目录和漏洞预测评分系统(EPSS)。


组织可以采取措施来减轻已知漏洞OSS组件的风险,例如扫描企业已使用的OSS组件中的漏洞,基于已知利用、利用概率、可达性分析(这可以减少80%的无效发现)等方法来确定优先级。



2. 伪装合法软件包


越来越多的恶意行为者发现,通过伪装成合法维护人员,以看似合法实则恶意的软件包来影响下游企业和用户非常好用。具体来说可以使用多种方法来实现这种攻击途径,例如劫持项目维护者的账户或利用仓库中的漏洞。


他们还可以自愿成为开源社区的维护者,只是为了在将来某个时候发起恶意攻击,最近爆发的XZ Utils事件就是其中的典型例子。攻击者伪装成合法的社区维护人员,利用长达数年的时间在系统中植入了后门。


那么该如何减少上述风险?安全专家建议使用类似微软的(现已捐赠给OpenSSF)安全供应链消费框架(S2C2F)等典型框架。



3. 名称混淆攻击


在名称混淆攻击中,攻击者创建的恶意组件名称与合法的OSS包或组件相似,它们会被潜在受害者在无意中下载和使用。这种攻击在CNCF软件供应链攻击目录中也有体现,包括拼写错误、抢注和品牌劫持。当这些恶意的包被带入组织的IT环境时,可能会影响系统和数据的机密性、完整性和可用性(CIA)。



4. 未维护的软件


0SS与常用软件不同,它没有“确定的供应商”,OSS维护者提供的软件是“原样”,这意味着无法保证软件会被维护、更新或持续。Synopsys发布的OSS报告数据显示,85%的代码库超过四年未更新OSS组件,且在两年内没有任何新的开发。


考虑到软件的老化速度极快,新漏洞正在以创纪录的速度出现,许多未能积极更新OSS组件的软件存在极大的不安全性,这点从国家漏洞数据库(NVD)发布的数据中可见一斑。


这也是无法避免的现状。由于OSS主要依靠无偿的志愿者维护,那么其组件不被积极开发、更新、修复缺陷等也在情理之中。即使有一定的维护,可能也存在较大的滞后性,不符合下游企业用户的期望,更不会像供应商那样向下游客户提供漏洞修复的服务级别协议(SLA)。


导致OSS组件未维护的另一个关键因素是,有25%的OSS项目只有一个开发者贡献代码,94%的项目维护者/开发者低于10人。如果一个项目只有一个维护者,风险是显而易见的。考虑到60-80%现代代码库由OSS组成,人们开始意识到当下数字生态系统的相当一部分,甚至我们最关键的系统都运行支持和维护最少的软件上。这也代表潜在的系统风险无比巨大,且很容易被攻击者利用。


处理这种风险的建议包括检查项目的活力和健康状况,如维护者和贡献者的数量、发布频率以及修复漏洞的平均时间(MTTR)。



5. 过时的软件


一个项目正在使用一个过时的组件版本,可能存在低版本的安全风险。据Synopsys发布的报告数据显示,在开源软件领域这种情况是常态,在绝大多数代码库和仓库中都会发生。


另外,许多现代软件应用和项目的依赖关系错综复杂,令人眼花缭乱,并且直接提升了漏洞安全风险。Sonatype和Endor Labs联合发布的《依赖管理现状》指出,95%的漏洞与传递依赖关系有关。



6. 未跟踪的依赖关系


开发者/组织有时未意识到使用了特定的依赖关系或组件的情况,其原因可能是企业没有使用软件组成分析(SCA)等工具来了解他们所使用的OSS软件;或者是没有采用新兴工具如软件物料清单(SBOM)进行检查分析,这些工具为企业提供已使用的软件/组件可见性。


经过SolarWinds和Log4j等事件,网络安全行业深刻意识到,大多数企业的软件资产清单多年来一直是SANS/CIS的关键控制,但仍缺乏全面的软件资产管理,更别提细化到组件/库级别。因此我们更需要SBOM等工具,为企业进一步了解所使用的组件清单,以便打造更安全的软件供应链。



7. 许可和法规风险


许可和法规风险是指组件或项目在实施过程中缺乏相应的授权许可,那么可能会导致下游企业违规使用组件的风险。


OWASP指出,组织需要确保他们对OSS组件的使用符合适用许可条款,不然很有可能因此引发侵犯风险,造成大量财产损失甚至是法律诉讼。这也可能会影响组织的商业目标、并购活动等,因为在其专有产品、服务和产品中可能广泛地使用OSS组件。


组织可以采取措施来减轻这些风险,例如确定他们在软件中使用的组件具有授权,同时当授权许可存在冲突或风险时,需避免使用这类组件,及时规避可能发生的损失。



8. 不成熟的软件


不成熟的软件风险在于并非所有的开源软件都能保持较高的成熟度,这是由开发者和维护者的个人技术能力决定。例如一些OSS项目可能没有应用安全软件开发实践(NIST安全软件开发框架(SSDF)),具体来说可能没有文档、缺乏回归测试、没有审查指南以及其他最佳实践。


另外一个无法回避的现实是很多开发者并不重视安全性,更关注使用性和便捷性。Linux Foundation和哈佛大学的创新科学实验室(LISH)研发后发现,自由和开源软件的开发者投入在代码安全性的比例仅仅只有可怜的2.3%。


企业可以通过一些工具来对开源软件的安全性进行检查,例如OpenSSF发布的Scorecard就可以为Github的OSS组件提供安全性分析,包括安全保护、贡献者的数量、CI测试、模糊测试、维护措施、授权许可等。目前市面上也有其他类似的工具可以实现上述功能。



9. 未经批准的变更


OWASP将未经批准的变更的风险定义为,OSS组件可能发现变化但开发者没有注意到,因此未能及时审查或批准变更的情况。这可能发生在下载链接变化或指向未版本化资源的情况下,甚至是被篡改的不安全数据传输,该风险强调了安全传输的作用。


缓解措施包括使用资源标识符以确保并指向不可变工件,在实际安装和使用组件之前,还可以验证组件的签名和摘要。此外,为了减轻组件在传输中被妥协的风险,组织应使用安全协议来传输和网络流量通信。



10. 依赖关系过小/过大


最后的风险是依赖关系过小/过大,例如开源软件具有很少或大量的功能,而实际上企业只使用了其中的一部分,这通常被称为“软件膨胀”。


在依赖关系过小的例子中,由于代码行数有限,组件变得依赖于上游项目的安全。另一方面,当代码膨胀或代码行数成倍增加时,会引入更多的攻击面和潜在的可利用代码/依赖关系,给企业带来不可知的安全风险,且不符合既定预期。


因此企业应尽可能重新开发内部所需的功能,以此来减轻依赖过小或过大的风险。安全专家也发现,可在云原生容器化环境中利用“安全基础镜像”进行推广,例如Chainguard一直倡导具有有限漏洞甚至没有漏洞的最小加固基础镜像——"安全基础镜像 "。



参考链接

https://www.csoonline.com/article/2088471/owasp-top-10-risks-list-attempts-to-establish-more-mature-approach-to-open-source-software-consumption.html


精彩推荐


继续滑动看下一个
FreeBuf播客电台
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存