软件供应链安全的现代化挑战

关键要点

近90的公司在过去12个月内发现了软件供应链的安全问题。开发团队成为攻击者的主要目标，许多企业未能理解软件供应链安全的实践。传统的安全工具无法有效识别恶意软件和故意篡改。需要转变思维，采用整体性的方法审视软件供应链及其风险。关注恶意软件的行为特征，而不是仅仅依赖传统的漏洞检测。

近90的公司报告称，在过去的12个月中他们在软件供应链中发现了安全问题。这或许让许多人感到意外，但对于那些在软件供应链工作多年的我们来说，这种情况并不意外。

我提到这一点有两个原因：首先，开发者和开发团队现在直接成为了攻击者的目标，且这是他们从未面对过的挑战。其次，企业往往无法理解软件供应链安全的实际内容，也不知道哪些攻击是重要的，以及如何进行防御。

没有正式化的计划，安全团队试图用传统的老旧流程和应用安全工具来应对这一现代问题。实际情况是，安全团队部署内部的软件组成分析SCA工具，检查开源代码，并审视他们的DevOps工具能力。一旦这些步骤完成，他们就认为自己完成了工作。可以说，在过去的确是如此。

但要应对现代问题，我们需要从现代的角度来看待。我们必须思考这些步骤如何提供必要的保证，确保在最终解决方案中没有恶意软件被植入。

加速器外网梯子

提示：传统的应用安全工具如SCA和应用安全测试AST，虽然擅长查找代码中的漏洞，但在识别恶意软件或故意篡改方面却显得无能为力。这部分是因为它们缺乏一个包含已识别恶意软件库的声誉数据库，这是识别恶意软件存在的关键。

想要进一歩验证吗？请看一下目前部署的AST工具的产品描述，告诉我哪些工具提到了恶意软件。我敢打赌，答案是“没有”。传统应用安全工具未能识别恶意软件的缺失正是ReversingLabs的软件供应链风险调查的重要发现之一。根据研究，74的从业者认为这些传统产品在保护公司免受供应链威胁方面效果不佳。

放眼未来，验证与重复！

为了解决软件供应链安全问题，团队必须阻止恶意软件渗入他们用于开发软件的供应链。这要求团队从整体上审视产品，而非仅仅关注细节。无论是云端、容器还是数据中心，都需要采取整体思维。

除了关注宏观视角，团队还需停止将软件供应链风险视为信任的考验。我们不能仅仅依靠信任来判断一个可部署包是否不含恶意软件，而应该依靠验证。要在持续集成和持续交付CI/CD管道中实施包验证，并确保这一过程是一致和可重复的。

成功转变为这种方法，团队需要改变审查软件的方式。停止逐日检查源代码、开源代码、第三方包和构建系统。是时候通过审视供应链所创造的结果来放眼未来。

接下来，要评估公司的完整应用包，而不仅仅是检查其中的单个组成部分。该过程最关键的阶段是在编译后、部署前此阶段，团队在此阶段需要对分析进行审查，以确保程序的设计行为与实际行为一致。

进行这样的评估，要求开发组织和应用安全团队从运行时分析扩展到反向工程过程，以便团队能够提出这样的问题：“这个应用程序做了什么？这是否是预期的行为？”

关注恶意软件

安全团队还需要将焦点从漏洞转向恶意软件。恶意软件的检测可能非常困难。如果组织缺乏能够监测行为的产品，这一挑战将会加大。然而，就像优秀的扑克玩家般，即使是最有效的恶意软件也会露出马脚：某些行为可能会引发红旗。这可能是特权提升、打开端口或套接字连接等行为。一旦发现其中一种或多种行为，检查这些行为是否属于应用程序的