毕业设计网站成品,明年做那个网站能致富,天津建行网站,微信公众号开发流程图3月20日#xff0c;xz-utils 项目被爆植入后门震惊了整个开源社区#xff0c;2021 年 Apache Log4j 漏洞事件依旧历历在目。倘若该后门未被及时发现#xff0c;那么将很有可能成为影响最大的软件供应链漏洞之一。近几年爆发的一系列供应链漏洞和风险#xff0c;使得“加强开…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
