问基本上只有两种方式的npm供应链攻击？

EN

几乎每周你都能读到通过妥协的npm库执行的攻击。国家预防机制的生态系统是广阔的和无法管理的，对它来说，处理所有使用npm可能带来的威胁是令人沮丧的。

在一般情况下，有很多最佳实践来处理第三方库，但老实说，在我看来，这还不够。其中大多数解释了如何避免违约，但实际上，讨论一种假设-违约-方法似乎更为现实。

关于npm供应链攻击，我的印象是，它们可以由

• 在机器上执行脚本

或

• 从应用程序内部进行通信

现在人们可能会说，等待等待--有大量的攻击可以通过妥协的npm包发生，比如远程代码执行、敏感数据窃取、加密/ransomware等等(1、2)。您是对的，但要使这些工作正常进行，您必须在计算机上运行脚本，或者在应用程序中与外部威胁参与者控制的命令和控制服务器进行通信，例如：

• 执行数据导出->从应用程序内部进行通信
• 生成反向shell ->执行脚本
• 密码器->执行脚本
• Ransomware ->执行脚本
• RCE ->执行脚本
• 窃取敏感应用程序数据->从应用程序内部进行通信

因此，底线是，将运行中的应用程序(例如，通过使用带有连接白名单的防火墙)和在安装过程中阻止任何脚本执行(3.)就足够了？

在(非常短的)场景中，开发人员下载一个任意妥协的npm库，并将其安装在他的计算机上。然后，将该库集成到开发的软件中，然后在CI/CD中构建并最终部署。

在这种情况下，我有三个层，需要阻止脚本和沙箱我的应用程序。在我看来最困难的部分是沙箱，在开发人员的机器上运行的应用程序，因为你需要考虑生产力，以安全为基础，限制互联网访问。

我知道所有与第三方库一起工作的最佳实践：

• 使用私有存储库
• 扫描图书馆
• 不要自动更新库
• 当包含新的lib时使用四眼原则。
• 诸若此类

您还可以监视(您的)包，寻找可能的漏洞信号(4.)。但仍然有可能是一个妥协的图书馆溜进了公司。错误总会发生。但在这种情况下，人们想要确保不会发生任何损害，对吗？

虽然这张照片有点肤浅，但我错过了一件事吗？我只想了解一下这个令人沮丧的话题。

1

2

3.

4.