软件供应链安全：等两周再更新 - 网安 - 专业的网络安全产业、社区、知识平台

通过在开源软件包中插入恶意代码来迅速将恶意软件传播到整个软件供应链中是恶意分子常用的攻击手段。然而，最新的研究发现，如果用户等待大约14天后再将这些软件包更新到最新版本，就可以避免受到软件包劫持攻击的不良影响。

JFrog的研究人员对各种开源软件包的受攻击情况进行了调查，发现其中一些软件包的下载量多达数亿次。此外，他们还分析了攻击被发现所需的时间跨度，以及在不良影响得以解决之前该软件包被下载的次数。

最终结果表明，在发现恶意代码并制定解决问题的更新方案时，项目的开发人员或维护者可能需要花费不同的时间，这个时间范围从数小时到超过一周不等。因此，在通常情况下，等待大约两周的时间再进行开源软件包的更新是一个相对安全的选择。

对于那些在最新版本发布后等待大约14天再进行软件包更新的用户来说，他们大概率可以避免遭受软件包劫持攻击的影响。因为在这两周的时间内，软件包劫持攻击通常会被察觉到，恶意版本的软件包也会被移除或修复，从而降低了用户受到攻击的风险。

软件包劫持的激增

软件包劫持是指外部威胁者或项目开发者与维护者本人在软件包的更新中插入恶意代码的情况。此类事件一旦发生，用户察觉到异常也只是时间问题。要么是由于劫持的恶意负载，要么是因为用户仔细检查了软件包代码的变化。对于攻击者来说，相比于发现并利用关键的零日漏洞，入侵代码库网站上的开发者账户往往更加简单。所以说，软件包劫持比传统的漏洞攻击更容易实施，并且能够造成更为广泛的影响。

发现问题所需时间

JFrog的研究人员旨在找出从一个软件包被劫持（被黑客篡改或植入恶意代码）开始，到软件包的用户意识到存在问题，并与项目的开发人员合作发布修复更新所需的时间。这个特定的时间段非常重要，因为在这段时间内，使用该软件包的用户更容易成为攻击的目标。

为了确定一个确切的检测时间范围，他们从两个角度来对多种软件包劫持示例进行评估：外部软件包劫持和内部软件包劫持。

前者是指第三方攻击者将恶意代码注入到软件包中。这可以通过劫持代码维护者的账户或将恶意代码伪装成合法的项目贡献来实现。而后者则是指合法的开发人员或维护者故意将恶意代码注入到软件包中，这通常是作为一种抗议行为。

外部软件包劫持

典型的外部软件包劫持案例包括去年12月针对机器学习开发人员的恶意代码依赖劫持，其目标是PyTorch Python库，以及分别在2021年10月和2021年11月，对"ua-parser-js"和"coa"软件包的独立攻击，其中涉及一个加密货币挖矿程序。

这些劫持行为对开发者社区来说可能会带来严重的潜在影响。PyTorch是一个被广泛使用的库，当前下载量已超过1.8亿次。ua-parser-js接近10亿次，而coa是GitHub上超过500万个开源仓库的基石，每周下载约900万次。

就PyTorch软件包劫持而言，用户花了五天的时间才发现有问题，在这期间该软件包就被下载了超过3,000次；而研究人员发现，parser和coa的用户仅花了几小时就检测到了软件包中的恶意软件。

内部软件包劫持

JFrog团队还调查了三个内部人员发起软件包劫持攻击的例子，其中两个发生在2022年1月，分别是备受Node.js开发人员欢迎的"colors"和"faker" npm两个软件包。在这两个软件包中，作者通过添加一个无限循环来破坏软件包，以抗议大公司不为开源社区做贡献的情况。

这种劫持对依赖这些软件包的软件项目造成了严重的损害，并且研究人员发现，在这些恶意版本发布后的两天内就被发现了。

另外，在2022年3月，一名开发人员向node-ipc软件包中添加了一段恶意代码，用于破坏俄罗斯和白俄罗斯的计算机文件系统，以抗议俄罗斯对乌克兰的入侵。在这种情况下，根据JFrog的说法，从发布恶意版本的软件包后，开发人员花了相当长的时间（大约8天）才察觉到该问题。

进一步的补救措施

除了等待大约两周时间再更新软件包到最新版本以外，开发人员和组织还可以事先对这些软件包进行严格地审核，再将软件包引入到其应用之中，来应对软件供应链攻击的威胁。可用的策展工具可以帮助组织定义一组规则，以确定开发人员可以访问哪些软件包，或者阻止下载那些14天内发布的第三方软件包。这有助于避免从公共存储库下载存在潜在安全风险的软件包。

此外，开发人员和组织还需要学会识别可能包含恶意代码的软件包，从而避免在自己的项目中使用这些受感染的软件包。

数世咨询点评

等待两周再更新软件包的行为是一种权衡安全性和便利性的做法。该策略的优点在于能够确保新版本相对稳定和安全，以降低用户受到恶意软件包或供应链攻击的风险。

但同时，该行为也会带来一定的麻烦，例如增加项目复杂性、延迟安全补丁以及降低开发速度等，其适用性存在一定的限制。

因此，决策是否采用此策略应该基于具体情况、风险评估以及项目需求来进行权衡。此外，组织还可以通过使用数字签名来验证软件包的完整性，以及定期审查代码和依赖项等方式来提高项目的供应链安全性。