软件供应链管理公司Sonatype的最新报告显示，在过去一年中，涉及恶意第三方组件的供应链攻击增加了633%，这还只是记录在案的，目前已知的实例超过8.8万例。与此同时，供应链中软件组件传递漏洞的实例也达到了前所未有的水平，这些软件组件影响着三分之二的开源库。
Sonatype在其最新发布的“软件供应链状态”报告中表示：“软件组件依赖关系的网络化性质突出了这些供应链的可见性和对其认识的重要性。这些依赖关系影响到了我们的软件，因此了解它们的来源对漏洞响应至关重要，许多组织没有做好必要的可见性，因此在2022年夏季之后，他们仍在为Log4Shell漏洞执行事件响应程序。”
Log4Shell是2021年11月份在Log4j中发现的一个关键漏洞，而Log4j是一个流行的开源Java库，用于记录日志，其被捆绑在了数百万的企业应用程序和软件产品中，通常表现为间接依赖关系。根据Sonatype的监测，截至2022年8月，Log4j固定版本的采用率约为65%，而我们更需要注意的是，Log4Shell漏洞起源于一名为JndiManager的Java，该Java是Log4j核心中的一部分，它也同时被其他783个项目借用，我们可以在19000多个软件组件中发现它的存在。
Log4Shell可算是漏洞时代的分水岭，它突显了开源软件生态系统中本就存在的风险状况，作为现代软件开发的核心，我们需要对其进行正确的管理，并要意识到其带来风险的严重性。Log4Shell漏洞的出现迫使一些私人组织、软件存储库管理者、Linux基金会和政府机构开始落实保护软件供应链的举措，然而在开源供应链管理方面，大多数组织还远远没有达到应有的水平。
来自顶级组件存储库（Maven Central（Java）、npm（JavaScript）、PyPi（Python）和NuGet（.NET））的软件包下载量同比过去平均增长了33%。这个增长率虽然低于前几年，比如2021年的增长率为73%，但存储库组件的下载数量已经超过了2021年，具体来说是超过了3万亿，其中仅npm存储库今年的下载量就将超过2021年四个存储库的下载量之和。
开源消费率的下降并不代表用户实施了更严格的开源采购管理政策，而是由于不同编程语言的生态系统已经达到了一定的规模，包括所增加的新项目和发布速度，都意味着这样的消费率是正常的。
Sonatype总结道：“尽管增长速度正在放缓，但增长的规模将继续以过去的年增长率为基础不断上升，没有任何迹象表明开源应用的速度正在‘失去活力’。”
截至去年年底，Sonatype追踪了大约12000起已知的恶意供应链攻击事件，但这一数字现已超过了88000起，同比增长高达633%。同时，该公司还发现了97334个以各种方式到处分发的恶意软件包。
在此提说，开源依赖关系天生具有供应链风险。经由报管理器和注册表的开源组件是入侵企业供应链的绝佳途径。开发人员已经够忙碌了，没有人会有时间查看每个软件包中的每行代码，更何况程序包更新。
通常而言，项目一般都是使用最新版本的程序包，之后才逐渐落下。软件开发组织机构的 AppSec 策略必须考虑到，虽然使用开源组件拥有很多好处，但也存在风险。其中一种风险就是开源依赖关系中存在开源供应链风险。未能保护开源供应链的安全会带来诸多风险，如宕机、密币劫持、僵尸网络、数据泄露或和开源许可证以及数据丢失带来的法律风险。
恶意软件包增长的主要原因之一，是由于一种被称为依赖混淆的攻击技术在被滥用，该技术于2021年2月由安全研究人员公开披露，自那时起此技术已经很泛滥了。关于此技术的介绍：攻击者通过将配置文件中与内部包相同名称的恶意包上传到公共包管理库当中，使得当项目构建加载运行时错误引用这一恶意包，从而使得RCE攻击成为可能。
也就是说，当包名称存在于两个位置时，客户端将拉入具有较高版本号的包，而这导致了一个问题，因为许多组织更习惯使用内部开发的软件包，这些软件包只存在于内部存储库中，从未公开发布，但如果攻击者从清单文件中找到这些包的名称，他们可以在公共存储库中发布拥有这些名称的恶意包，并使用更高的版本号来欺骗系统软件构建客户端。
然而，很难说所有的依赖混淆攻击都是恶意的，因为这种技术在渗透测试人员中也很流行。另一方面，组织可以通过在公共存储库中注册其私有包的名称来保护自己，或者为其所有包使用前缀，然后可以将其注册为公共存储库上的作用域，这样攻击者就不能再发布带有这些前缀的包了。
此外，其他类型的大规模攻击包括拼写错误攻击和品牌劫持攻击。其中误植域名（Typosquatting）涉及攻击者注册恶意软件包，其名称与一些广泛使用的软件包名称相似，这是一种被动攻击，源于开发人员在构建脚本或命令途中，输入包名称时所犯的打字错误。
品牌劫持也是一样，但它的目标是其他软件包的维护者，攻击者会希望这些维护者在自己的组件中包含一个被劫持或错用的软件包作为依赖项。以及当合法软件包的维护者将所有权转移给其他人时，或者当他们停止开发该软件包并将其删除，但旧名称仍旧可用时，也会发生类似的情况。
恶意代码注入是另一种更具针对性的技术，其涉及到攻击者会破坏开发人员的系统或代码存储库，并在他们不知情的情况下将恶意代码注入到他们的包中。当包维护者允许他人对其代码存储库进行访问时，怀有恶意或受到威胁的访问者也会促使这种情况的发生。
还有一种攻击类型类似于恶意代码注入，但它由合法开发人员所实施，称为抗议软件。这通常是指开发人员将恶意代码添加到自己以前清理过的包中，以示抗议的情况。
建立、维护所有内部软件在开发工作中所使用的组件清单，同时跟踪其中所发现的漏洞，这是降低安全风险的关键，还有就是围绕组件来源制定明确的政策也同样重要。选择自己代码中漏洞发生率较低的组件并不能保证万无一失，因为许多组件、库可能会从自己的依赖关系中继承漏洞，因此对此类漏洞做出响应并更新自己依赖性所需的时间至关重要。
Sonatype分析了企业应用程序中常用的12000多个库，结果发现其中只有10%的库在代码中存在直接漏洞。然而，当组件、库从依赖关系中继承漏洞的情况发生后，漏洞发生率上升到62%。相关数据表明，平均而言，每个库都有5.7个依赖项。
此外，从长远来看，选择较低漏洞率的组件并不一定会带来更好的安全结果，因为研究人员在选择他们想要审查的项目时存在很多“偏见”。换句话说，一个受欢迎的项目可能会被挖掘出更多的漏洞，因为它受到的关注更多。
Sonatype研究人员表示：“由于大多数漏洞都是由可传递依赖引起的，因此最明确的方针是仔细考虑企业所使用的每个库。降低可传递漏洞风险有两个关键因素，一是最小化依赖项的总数，二是保持项目依赖项的较低更新时间，因此企业可以选择依赖树较小的项目，或寻找在发布新版本依赖项时能够快速更新的项目。”
有几个指标可以用来判断开源项目的安全实践，其中之一是由开源安全基金会（OpenSSF）开发的安全记分卡系统，该系统能执行一系列自动检查，以检测开源项目是否存在未修复的漏洞，包括是否使用过工具帮助其更新依赖关系，是否运行过CI测试，是否运行过自动代码模糊，是否使用过静态代码分析工具，是否避免过危险的编码实践，是否在合并新代码之前执行过代码审查，等等。
Sonatype使用自己的数据来评估其中的一些实践，看哪些实践对降低项目漏洞可能性的作用最大，结果发现影响最大的操作是代码审查，其中不包括二进制工件，避免危险的编码实践（分支保护），固定依赖项，以及审查代码提交。
Sonatype研究人员表示：“我们建议开发人员需按顺序选择MTTU、安全记分卡、OpenSSF关键性和SourceRank最高的组件。汇总、权衡各种分数可能会很困难，因此我们将新的Sonatype安全评级添加到了公共漏洞数据库OSS指数中，这样就会变得容易。”
Sonatype对各企业662名工程专业人员进行了调查，并就他们在使用开源组件、依赖管理、治理、审批流程和工具方面提出了40个问题。从所得到的大多数答复中可以看到，大部分企业的供应链管理水平低于Sonatype从研究中得出的合格线。
得分最高的是补救和应用程序清单方面。比如68%的受访者表示，他们确信自己的应用程序没有使用已知的那些易受攻击的库。而84%的人表示，他们仔细检查过自己所使用的开源组件，并这些组件的安全历史。然而，这些数据与Sonatype在实践中所发现的不符，在实践中，Sonatype对随机选择的55000个企业应用程序进行扫描后，发现其中68%的应用程序存在已知漏洞。
研究人员表示：“我们使用了调查期间所收集到的人口统计数据，并按职称对其结果进行了细分。可以说，这调查结果很有启发性。人们一直倾向于以更好的视角看待事物，就是所谓的管理者报告成熟度要高于其他角色的成熟度。在整个调查范围内，当我们比较IT经理和信息安全人员时，这种差异在统计上是显著的。”
对于该如何防范、管理供应链攻击，国内安全专家如此建议。
某互联网企业安全专家赖东方从管理和技术两个方面提出建议。
在管理上，他认为要先收集信息，加强这类资产的检测、登记、整理，让安全团队知道用了哪些类型和版本的系统，方便第一时间响应漏洞和事件，也方便长期的风险关注、升级、替换。对于风险较高/出现问题较多的应该尽量淘汰。
在技术上，除了管理上的技术手段，剩下就是要考虑存在风险之后的二层防御问题。例如新出现了漏洞或相关的攻击事件，要有这种异常的检测手段或拦截手段来防治损失。例如在请求数据和前端代码层面的动态防护技术就是一种拦截手段。如果企业在SDL的投入上比较重视的话，可以在开发层面做到更加严谨的防护，尤其是那些关键业务功能/涉及风险组件的业务，加强前面的校验/过滤机制，可以降低0day的攻击面。要假设自己用的某些组件就是存在漏洞的，想想攻击的入口能有哪些，从利用途径去下手。
“开发人员选择组件的时候，往往会优先考虑熟悉的、好用的组件。安全看得不重，有部分原因是因为对这些风险不了解，不直观。供应链也终究会出现安全方面的优胜劣汰，现在我们把它放大了是好事情。我们可以聚焦起来，把供应链的风险更直观的曝光出去，多宣传，让业内都知道，谁的风险比较高，谁经常出漏洞，谁的口碑比较好。让大家选择这些开源供应链的时候能看到它在安全方面的优缺点。”
某互联网企业安全专家白玉堂指出，由于用户对开源供应链软件具有依赖性，所以往往很少会去关注。其常见的攻击场景有：
1、当我们决定对某一目标进行渗透测试，他们通用的一些开源软件就可以成为一个很好的突破口。许多开源软件，都是源于作者的无私奉献，我们如果还要苛求他们懂安全、主动且及时的修复漏洞，这是不太可能的。
2、如果我们针对某公司的特权账号，有针对性的进行了信息搜集，那么就能发现这些公司会使用略显小众的开源软件，这也是一个常见的突破口。
因此，从防范角度考虑，白玉堂认为需要关注的有：
1、做好内部特殊账号的安全监控
2、对公司通用的开源软件，在能力允许的条件下，做一些安全审计工作，选择成熟稳定的版本。
3、做好针对开源软件的漏洞情报收集
4、建立安全应急流程
5、提高员工安全意识、特别是运维、财务、人力、客服、CXO等权限较大、安全意识薄弱的群体，要特别重视。
某互联网公司安全总监程明从四个方面提出了该如何防范供应链安全：
1、看得见——知己知彼
能够精准掌握内网软件资产信息，让安全策略、安全基线有的放矢。
2、防得住——严控通道
下载安全软件：构建企业软件下载平台，降低员工从第三方平台或者论坛下载各种工具的风险，既能确保应用的丰富性，又能保障软件安全性。从根源上提升软件供应链的安全水平。
3、查得清——准确定位
当出现新型软件供应链攻击事件时，能够根据问题软件的问题版本，第一时间找出高危终端，并准确评估受影响的终端范围，以便采取更有效的响应措施。
4、搞得定——协同防御
为避免软件供应链攻击在内网爆发，可以终端边界双管齐下
“对于其他方面的供应链管理工作，我建议提升人员对供应链安全、供应链管理的意识，并做好供应链相关的应急预案，定期开展应急演练工作，除此之外，在发生供应链安全事件后还要总结复盘。”
《Supply chain attacks increased over 600% this year and companies are falling behind》
齐心抗疫 与你同在 
原文始发于微信公众号（安在）：增长超600%！企业该如何应对开源供应链攻击？
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论