国内企业要想快速、安全地构建、管理和发布软件，就得构建一个从开发人员到设备一体化的安全、无阻碍的软件流程。开发人员创建的代码只是软件开发的起始，如今，开发人员管理着整个软件供应链。一家企业的软件供应链由许多部分组成，包含各种来源：开源包、商业软件、基础设施即代码（IaC）文件、容器、操作系统镜像等。这种多样性意味着企业的软件供应链存在很多风险点，而且由于错误、疏忽、质量差或恶意攻击，安全威胁涉及面非常广泛。

软件供应链风险趋势

了解易受攻击的风险点位置，对于保障软件供应链安全非常重要。但是，利用单点解决方案来逐一应对的做法，就如同打地鼠游戏，被击碎的威胁可能在未注意的其他地方再次出现。

为全面保护供应链免受威胁，要从头到尾始终保持警惕，甚至在开发者调用外部软件包之前就要开始注意。不论是在专有代码开发、代码编译和临时构建环节，还是在整体运算流水线中进行发布和分发，直到生产，乃至部署后，都要事无巨细地关注。除了揭示漏洞和其他安全问题，还需要知道具体场景，以便判断出真正的风险。

软件供应链威胁两大主要途径

第一种是利用供应链的“开放性”来获取攻击者计划攻击的软件信息。一个常见的例子是，攻击者试图远程映射一个网络服务，或者释放一个面向物联网设备的软件，从而熟悉其使用的开源包。然后，他们就能轻松地找到与这些软件包相关的通用漏洞披露（CVE）信息，了解软件包的安全配置，甚至尝试寻找未知的漏洞（又称零日漏洞）。当充分掌握有关漏洞利用路径的信息后，攻击者就可以进入第二阶段了。

第二种是攻击者会利用供应链，将恶意软件包和恶意代码注入公共或私人资源库，或改变现有的代码并将恶意部分纳入其中。

四大突出风险威胁软件供应链安全

1. 已知漏洞

第三方组件（如开源和商业软件）可能带有非故意性质的漏洞，其中许多是已知的，并已在NVD和VulnDB的漏洞数据库中被公开追踪。

可以通过软件组件分析（SCA）解决方案来揭露这种风险，该解决方案可以识别特定代码或制品的软件物料清单（SBOM），并将其与已知的CVE联系起来，主要是将已识别的软件元数据与公共CVE数据库进行交叉引用。

但是，还需要获得足够多的信息以便制定基于风险的决策，并使之自动化。一个可扩展的数据库是必须的，不仅可以追踪更多风险，还包括进行深入地安全研究，有助于了解能够降低这些风险的所有方式，从而选择最实用且最具成本效益的方法。

同样重要的还有场景分析，以此确定漏洞被利用的可能性。例如，组件中易受攻击的功能可能不会被应用程序使用，或者易受攻击的程序从未在生产版本中运行，或者特定的配置会导致给定的CVE失效。

也可以从看似安全的组件中识别出可能的运行风险。例如，一个很久没有维护的开源包可能未针对安全问题进行充分监控。在此情况下，漏洞是不确定的，但潜在的威胁是可预见的。

这些已知的和可预期的风险能够而且应该在以下几个方面发现：

源代码：将安全警惕性左移到代码创建之时，可以节省后期修复的成本。安全团队可以构建一个获批第三方组件的内部资源库，开发人员可以通过对其集成开发环境（IDE）的扩展来获得对薄弱依赖项的警报。虽然本质上是不完整的，但这种方法有助于避免已知的风险。需注意的是，它不可能是详尽的，因为左移的安全工具通常会让开发者承担成百上千的工作任务，而这些工作任务从安全的角度来看不一定有影响，因为它们会忽略漏洞或安全问题的完整场景。二进制文件：对关键二进制存储库（包括第一和第三方组件）中的所有软件包、构建和图像进行自动软件成分分析（SCA）扫描，确保整个软件供应链受到保护，免受已知漏洞和运营风险的影响。作为应用程序生产阶段状态的最准确的代表，二进制文件能够对风险进行最高质量的真实分析，并提供更准确的场景。借助二进制文件，还能分析对左移工具和生产中安全解决方案来说是“盲点”的问题。

2. 未知漏洞（零日漏洞）

编码中的错误很常见。逻辑缺陷、不良加密和潜在的内存损坏都会无意中导致应用程序易受恶意攻击，如远程代码执行（RCE）和拒绝服务（DoS）。这些错误可能潜伏在第一和第三方代码中而不被发现，甚至在被识别前已潜伏数年。

这些问题被称为“零日”问题，部分原因在于其存在时间长，但也因其紧迫性，而意味着团队能够在已部署软件中对其进行修复的时间为零。

为捕捉和防止潜在的零日问题，必须将不同二进制文件、进程和服务之间的流通性纳入考量，对每个组件与应用程序进行测试。静态代码分析（审查代码源）和动态代码审查（测试运行中的代码）工具通常各自能够识别约85%的缺陷，但他们通常会在每个版本中产生成千上万的条目，并且需要专业知识来阐释结果并确定优先次序。不过，一个可能存在的漏洞，但并不意味着它一定可以会被攻击。

更先进的技术结合了符号执行、数据流分析和自动模糊测试，可以显着降低误报率，并识别典型 SAST/DAST 无法发现的漏洞。结合对源代码和二进制文件的分析，也可以产出更完善的结果，并帮助开发者、安全团队和生产经理专注于修复重要问题。

纵然竭尽所能，但还是可能会发现新的漏洞并影响到已部署的软件。持续的SCA扫描有助于确保迅速获得任何会影响生产阶段软件的最新CVE通知。丰富的SBOM元数据有助于迅速了解漏洞对机构的全部影响，并在整体应用程序库存中应对或补救。将代码和制品库适当进行整合，可以在整个机构内迅速采取行动，应对已发现的威胁。

3.  非代码问题

并非所有的漏洞都存在于代码之中，还可能存在于二进制文件（如EPMs）、jar文件容器、固件以及支持性制品（如配置文件或IaC文件）中。错误配置、不良加密、秘钥和私钥的暴露，或操作系统问题都会导致受攻击面出现。

这些人为错误的副作用通常是由于缺乏关注而造成，并不是恶意为之，而且通常是在主要开发的热点之外引入的。用于测试的配置可能被不经意地推广到生产阶段。这些风险通常易于解决，但难于被发现，也更难于恢复。

即使是良好的意图也可能导致恶意的后果，例如，在公共服务器上暴露密码，就可能招致恶意代码注入，从而暴露敏感数据。类似名称的软件包之间的依赖项混淆也可能在非30恶意的情况下发生，特别是当软件包库解析配置不良的情况下。

在这些问题发展到生产阶段之前，及早发现是至关重要的。需要像对待代码中的漏洞一样认真对待这些潜在风险，并将这种警惕性纳入流水线端到端安全态势中。

4.  恶意代码

故意的威胁（无论是来自外部注入攻击还是恶意的内部人员）往往是最难发现的，因其经常被掩盖，而显示为已经验证的组件。特洛伊木马、机器人程序、勒索软件、加密软件和间谍软件的传播通常是以较为良性的漏洞类型作为有效载体。利用有害的软件包来植入常用存储库，入侵维护员账户以改变现有软件包，或将代码注入被破坏的源存储库，都是后门访问攻击的常用方法。

在部署后发现上述攻击，通常为时已晚，损害已经造成，而且可能代价非常高昂。这就是为什么应该在整体流水线中对其进行保护：

访问控制：内部软件包库必须通过整个机构内始终一致的权限和安全认证（包括多因素认证），将写入权限限制为关键角色和团队成员。代理存储库：缓存外部存储库（如Maven Central和npm）可提供不可篡改的第三方资源快照，因此任何后续的恶意覆盖都会立即显现出来。测试和分析：先进的静态和动态分析工具可以检测和标记恶意代码和有问题的软件包。JFrog安全研究团队已经通过自身开发的工具，在公共软件包库中发现并披露了1300多个恶意软件包。 

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

虽然这些风险趋势中的一些问题能够一次性解决，但单点解决方案只能作为警报系统，而且只在需要之处才能起到帮助。

鉴于同样的原因，单独的安全解决方案能够起到的帮助也是有限的，因其能力范围有限，因此无法帮助分析和判断整个软件供应链中风险的完整场景。当与存储库和软件管理解决方案脱节时，即使安全单点解决方案非常准确，也很难针对所发现的问题采取有效的行动来进行补救和应对。

全面的安全态势不能只关注流水线中孤立的各个点，必须能够将不同问题和安全方面的发现这些众多点联系起来，而这是单独的小众解决方案所无法做到的。

为维护软件安全，就需要做到端到端的警惕，从开发者的IDE一直到生产阶段，在开发和生产环境中执行一致的风险监督并落实应对措施。安全解决方案必须应用于整个软件供应链，并能够大规模采取行动。为确保整个机构内的一致性，其运营必须围绕所有二进制文件的单一可信来源，并与开发运维工具深度集成。