查看原文
其他

库依赖关系和开源供应链带来的噩梦

Kevin Townsend 代码卫士 2022-04-06

 聚焦源代码安全,网罗国内外最新资讯!


专栏·供应链安全

数字化时代,软件无处不在。软件如同社会中的“虚拟人”,已经成为支撑社会正常运转的最基本元素之一,软件的安全性问题也正在成为当今社会的根本性、基础性问题。


随着软件产业的快速发展,软件供应链也越发复杂多元,复杂的软件供应链会引入一系列的安全问题,导致信息系统的整体安全防护难度越来越大。近年来,针对软件供应链的安全攻击事件一直呈快速增长态势,造成的危害也越来越严重。


为此,我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯,分析供应链安全风险,提供缓解建议,为供应链安全保驾护航。


注:以往发布的部分供应链安全相关内容,请见文末“推荐阅读”部分。

  


它是一个比当前情况更严重的问题,有可能造成与 Equifax 以及 SolarWinds 事件规模一样大的影响。

商业 app 开发对速度和资源的追求要求开发人员必须使用开源软件库。但困难在于,开源漏洞通过库进入商业 app 成品,管理它并不容易。

Contrast Labs 发布《2021年开源安全报告》分析了这个庞大的问题,它的数据基于该公司数万个真实管理的应用程序和 API,并发现了一个严重问题。

报告指出,平均每款应用包含118个库,其中仅有38%的库是活跃的即被应用程序使用,而活跃库中仅有31%的库被既定软件调用过。虽然应用程序中库占据很高比重,但仅不到10%的代码是活跃的第三方库代码。

“传递依赖关系”更加剧了这种复杂性。传递依赖关系是指某个库所要求的函数可能实际上依赖于不同的其它库,这就不可避免也可能不知不觉地被所交付的 app 所调用和包含。


下游问题


结果,资源不足的团队需要管理可能和数百个库或者很多款 app 相关或不相关的漏洞,而且始终存在这样一种可能性:库更新可能引发更多的下游问题。

这些团队有两个选择:要么花费大量宝贵的时间判断自己的 app 中是否包含需要更新的库并进行更新;要么忽视这个问题。采用后一种做法的团队似乎更多,因为在使用状态的库版本已存在2.5年之久,6%的库版本甚至已存在5年之久。

静态代码分析 (SCA) 引擎可返回从应用程序中发现的 CVE 清单。然而,这类工具无法区分活跃库和不活跃库中的漏洞。报告显示,17%的 Java 应用中、15%的.NET应用中以及80%的 Node 应用中的“严重”和“重要”CVE漏洞位于不活跃的库或类中。SCA 在查找活跃漏洞过程中提供大量误报情况,从而加重了开发团队的负担,忽视这个问题且不进行更新。

报告警告称,已存在多时的库只会让未来的问题更加严重。

报告指出,“不更新库不仅增加了组织机构的风险,而且也使库版本在最终更新时变得更加困难和耗时。当应用程序中的库多年来一直处于休眠状态时,任何新漏洞都变得难以修复,因为基于它构建的代码实在太多了。”

Contrast 公司的联合创始人兼CTO Jeff Williams 表示,这就像“两害相权取其轻,因为你越滞后,越难跟上。因此,如果不及时修复库,则会累积技术债务。但商业公司集中火力推出新功能,不到万不得已的时候他们并不愿意更新这些库。”

他补充道,“这是一个大问题。我们现在所热爱和依赖的所有 app如网上银行、网上购物、医疗、国防、政府等等都在使用这些库。如某个库中包含一个漏洞而该app在使用,则漏洞将会成为该 app 的一部分,从而遭到攻击。”


攻击者的主要路径


2017年发生的 Equifax 数据泄露事件就是颇具讽刺意味的一个案例。攻击者通过Apache 许可库 Object Graph Navigation 语言 (OGNL) 利用和 OGNL 解析错误信息相关的一个缺陷,实现了数据泄露的目标。

开源库为攻击者提供了两个主要路径。第一个是通过已发现漏洞如Equifax 事件所示,第二个是通过在库来源中引入漏洞。第二个路径所引起的潜在危害是巨大的。

一个重大问题在于,目前并不存在针对开源的集中式规定。任何人都可以创建新库并通常从开源库发布,供任何人下载。其他编程人员也可对原始库执行增加操作。如果攻击者能够在这个阶段引入漏洞,则漏洞有可能进入使用这个库的所有 app 中。

这种库不胜枚举。在所使用 Node 的app 中,超过90%的 app 都在使用前25大 Node 库。因为这些 app 中很多库都是不活跃的,实际情况可能并没有看起来这么严重,但尽管如此,42%的 app 都在使用最常见的活跃库。漏洞被引入库中,或者仅仅是从库中发现了漏洞,都会包含在所有使用该库的 app 中,导致所有使用最终产品的企业变得易受攻击。在所有类别的库中,这种场景多多少少都在反复出现。

整体缺乏控制主体所造成的问题在于,追踪漏洞和库更新并非易事。Williams 指出,“目前并不存在正式的通知系统。必须运行某种工具才能识别处所有库,并检查数据库中是否存在已过时的库或者存在已知漏洞。这种工具相当于提供了一种需要更新的任务清单。”需要注意的是,任务清单中可能仍然含有大量误报情况,即app 和所使用的库并不受漏洞影响。


公共版权 (Copyleft) 库


加剧安全管理开源库困难的另外一个因素是“公共版权 (copyleft)”库的存在。虽然多数开源软件可免费使用,但一些开源软件中含有某种形式的“公共版权”库。Williams 解释称,“在多数情况下,这类库仅要求致谢开发人员。但一些库如使用了 GPL 许可证的库更进一步。按照GPL许可证的要求,如果使用了该库,则由该库所生成的代码也必须按照同样的条件开源。“

这就意味着我们必须将自己的代码设为免费可用,而在某种程度上,它和商业软件是不兼容的。Williams 认为,“创建 GPL 许可证的家伙有一种非常乌托邦化的理念,认为代码应该是免费的,所有人都应该分享,而如果我们协作,则代码会让人道主义受益。但多数企业对此并不认可。他们不想把自己按照合同为另一家公司所开发的代码开源。因此对于含有 GPL 许可证的代码被引入后,该组织机构的律师就会紧张起来。”

严格来说,管理开源供应链中的漏洞并没有太过于艰难。但问题在于它要求投入的时间超过当前多数企业的投入,或者所要求的自动化超过多数解决方案所交付的结果。结果就是开源供应链管理问题常被忽视或者仅部分解决。Williams 指出,解决好这个问题,“企业就能够集中火力解决最重要的事项,同时希望企业能够做出更聪明的库决策,同时让我们变得比原来更安全一点。“











推荐阅读
详细分析PHP源代码后门事件及其供应链安全启示
为增强供应链安全,美国将设立“国家供应链完整性之月”
有人滥用 GitHub Actions在 GitHub 服务器挖掘密币,且正在蔓延
微软“照片”应用Raw 格式图像编码器漏洞 (CVE-2021-24091)的技术分析
速修复!热门npm 库 netmask 被曝严重的软件供应链漏洞,已存在9年
SolarWinds 供应链事件后,美国考虑实施软件安全评级和标准机制
找到软件供应链的薄弱链条


原文链接

https://www.securityweek.com/library-dependencies-and-open-source-supply-chain-nightmare


题图:Pixabay License


本文由奇安信代码卫士编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。



奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的

产品线。

    觉得不错,就点个 “在看” 或 "” 吧~


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

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