你需要知道的软件供应链风险

一个组织的开发人员创建的代码只是现代软件开发的开始。事实上，第一方代码可能只占应用程序的一小部分——有时只占应用程序的10%工件的生态系统．

企业的软件供应链由许多部分组成，从许多来源积累起来:开源包、商业软件、基础设施即代码(IaC)文件、容器、操作系统映像等等。这种多样性意味着你需要保护的供应链有很多很多风险点，以及由于错误、疏忽、质量差或恶意攻击而造成的安全威胁的广泛范围。

4个关键的软件供应链风险趋势

理解这些风险易发点是保护软件供应链的重要手段。但是，用单点解决方案逐个解决它们就像玩打地鼠游戏——一个被粉碎的威胁可能会出现在你没有寻找它的地方。

充分保护供应链免受威胁需要从头到尾保持警惕。这甚至在开发人员调用外部包之前就开始了，经过专有代码开发、代码编译和临时构建，以及整个发布和分发的管道，一直到生产，甚至在部署之后。除了仅仅揭示漏洞和其他安全问题之外，您还需要了解它们的上下文，以便能够判断真正的风险。

软件供应链威胁可以(大致)分为两个主要路径。

首先利用供应链的“开放性”来实现获取有关软件的信息攻击者的目标。一个常见的例子是，对手试图远程映射web服务或为物联网设备提供软件，以熟悉其使用的开源包。然后，他们可以轻松地找到与此类包相关的cve信息，了解包的安全配置，甚至查找未知漏洞(又名零日漏洞)。当攻击者获得充分的利用路径知识后，就可以进入第二阶段。

二是利用供应链来实现注入恶意包和恶意代码到公共或私有存储库，或修改现有代码并在其中添加恶意代码。

软件供应链攻击:两种主要途径

让我们来看看威胁软件供应链并使其容易受到攻击的四个突出风险:

1.已知的漏洞

来自第三方的组件(如开源软件和商业软件)可能会带来意想不到的漏洞，其中许多漏洞是已知的，并在数据库中被公开跟踪常见漏洞及暴露情况(CVE)列表。

你可以用软件组件分析(SCA)解决方案识别给定代码或工件的SBOM，并将其与已知的CVE相关联，主要是通过交叉引用已识别软件的元数据到公共CVE数据库。

但是，你还需要有足够的信息来制定并自动化基于风险的决策．一个扩展的数据库是必须的-一个不仅跟踪更多的风险，而且包括深入安全研究这可以帮助您了解降低风险的所有选项，使您能够选择最实用和最具成本效益的方法。

同样重要的是语境分析这可以确定漏洞被利用的可能性有多大。例如，组件中的易受攻击的函数可能不被应用程序使用，或者易受攻击的进程永远不会在生产版本中运行，或者特定的配置使给定的CVE无用。

你也可以识别可能性操作风险从看起来安全的部件上。例如，有一段时间没有维护的开放源码包可能没有对安全问题进行充分的监控。在这些情况下，漏洞是不确定的，但可以预测潜在的威胁。

这些已知的和预期的风险可以并且应该在以下方面发现:

• 源代码-将安全警戒左移至代码创建时，可节省后续补救的成本。安全团队可以管理已批准的第三方组件的内部存储库，并且/或开发人员可以通过扩展IDE获得易受攻击的依赖项警报。虽然这种方法本身就不完整，但可以帮助避免已知的风险。但是，它永远不可能是详尽的，因为左移安全工具通常会让开发人员超载数百或数千个任务，从安全角度来看，这些任务不一定有影响，因为它们错过了漏洞或安全问题的完整上下文。
• 二进制文件-自动SCA扫描关键二进制存储库(第一个和第三方组件)中的所有包、构建和映像，确保您的整个软件供应链免受已知漏洞和操作风险的影响。作为应用程序生产状态的最准确表示，二进制文件支持最高质量的真实风险分析和更准确的上下文。它还允许分析左移工具和生产安全解决方案的“盲点”问题。

2.未知漏洞(“零日漏洞”)

错误是日常编程的一部分。逻辑缺陷、糟糕的加密和潜在的内存损坏无意中使应用程序容易受到恶意攻击，如远程代码执行(RCE)和拒绝服务(DoS)。有时，这些错误可能潜伏在第一个代码和第三方代码中而未被发现多年后才被认出来．

这些问题被称为“零日”问题，部分原因是已知它们的时间长度，但也因为它们的紧迫性意味着团队没有零日时间在已经部署的软件中修复它们。

为了捕捉和防止潜在的零日问题，必须测试每个组件和/或应用程序，同时考虑不同二进制文件、进程和服务之间的流。静态代码分析(用于审查代码源)和动态代码审查(用于测试运行的代码)工具通常都可以识别大约85%的缺陷，但它们通常在每个版本中生成数千个条目，需要专业知识来解释结果并确定它们的优先级。就像已知的问题一样，漏洞可能存在，但这并不意味着它一定是可以利用的。

结合符号执行、数据流分析和自动化模糊分析的更先进技术可以显著降低误报率，并识别典型SAST/DAST无法发现的漏洞。同时分析源代码和二进制文件还可以产生更好的结果，并帮助开发人员、安全团队和生产经理集中精力解决问题。

尽管尽了最大努力，但总有可能发现新的漏洞并影响已部署的软件。持续SCA扫描可以帮助确保快速通知任何影响生产软件的最新cve。一个富有的软件物料清单元数据使您能够快速了解漏洞对您的组织的全部影响，并减轻或在整个应用程序目录中进行补救．与代码和工件存储库的适当集成可以在整个组织中快速采取行动，并减轻已识别的威胁。

3.非代码问题

并不是所有的漏洞都存在于代码中——它们可以在二进制文件(如epm)、jar文件容器、固件以及支持构件(如配置文件或IaC文件)中找到。错误的配置、糟糕的加密、秘密和私钥的暴露或操作系统问题都可能打开攻击面。

这些人为错误的副hth华体会最新官方网站产品通常是由于缺乏关注而不是恶意，并且通常是在重大开发的热点聚光灯之外引入的。为测试而组合在一起的配置可以不加思索地推广到生产中。这些风险往往很容易解决，但很难捕捉，也更难从中恢复。

即使是善意的意图也可能导致恶意的后果。最臭名昭著的是SolarWinds违反开始于暴露在公共GitHub服务器上的密码这使得恶意代码注入得以实施，最终暴露了敏感的政府数据。依赖关系混乱名称相似的包之间也可能发生无恶意的情况，特别是当包存储库解析配置很差。

在这些问题进入生产环境之前，尽早发现它们是至关重要的。您至少需要像对待代码中的漏洞一样认真对待这些潜在风险，并将这种警惕性集成到管道的端到端安全态势中。

4.恶意代码

有意的威胁，无论是来自外部注入攻击还是恶意的内部人员，都可能是最难发现的，因为它们通常被掩盖为已经验证过的组件。特洛伊木马、机器人、勒索软件、密码挖掘者和间谍软件通常通过我们已经讨论过的更友好的漏洞类型作为有效载荷传递。在流行的存储库中植入有害的软件包，侵入维护者的帐户以更改现有软件包，或向受损的源存储库中注入代码，这些都是启用后门访问攻击的常用方法。

在部署之后发现这些攻击通常已经太迟了——损害已经造成，而且代价非常非常高。这就是为什么你应该在整个流程中防范它们:

• 访问控制-内部包存储库必须通过跨组织一致的权限和安全身份验证(包括多因素身份验证)限制对关键角色和团队成员的写访问。
• 代理库-缓存外部存储库(如Maven Central和npm)可以提供第三方资源的不可变快照，因此任何后续恶意覆盖将立即显现。2022世界杯阿根廷预选赛赛程
• 测试和分析-先进的静态和动态分析工具可以检测和标记恶意代码和可疑包的恶意行为。JFrog安全研究团队已经通过其开发的工具在公共包存储库中发现和披露了1300多个恶意包。

软件供应链风险管理的端到端警戒

虽然其中一些风险趋势可以一次解决一个，但点解决方案只是警报系统，而且只在你认为应该放置它们的地方有用。

出于同样的原因，单独的仅安全解决方案的帮助也很有限，因为它们有限的范围不能帮助您分析和判断整个软件供应链中的风险的完整上下文。当与存储库和软件管理解决方案断开连接时，即使安全点解决方案非常准确，也很难采取有效的行动来补救和减轻已确定的问题。

全面的安全状态不能只关注管道中的孤立点，它必须使您能够将不同问题和安全发现之间的点连接起来——这是单独的小众解决方案无法做到的。

软件安全需要端到端的警惕，从开发人员的IDE一直到生产环境，执行一致的风险监督，并在开发和生产环境中实现风险缓解。您的安全解决方案必须对您的软件供应链采取整体行动，并使您能够采取大规模的行动。为了在整个组织中始终保持安全，它必须针对你所有二进制文件的唯一真相来源，并与您的DevOps工具深度集成。

想从JFrog了解“下一步是什么”，这将有助于满足这些需求?注册一个swampUP城市旅游事件即将在你身边到来!