大多数企业在其组织内都有某种二进制或工件库，以便更好地管理开源软件包的导入和使用。例如，在填充存储库之前，大多数组织都会进行一些传统的检查，以验证进入的软件包是。
- 维护良好
- 有适当的商业使用许可
- 无漏洞（至少在导入时）。
等等。虽然这些检查可以帮助管理传统的治理、合规和安全风险，但它们忽略了与软件供应链相关的新兴风险。开放源代码供应链的威胁远远超出了识别和管理漏洞的范围，包括。
- 开源软件库的威胁，如排版错误、依赖性混乱、含有恶意软件的软件包等。
- 开源构建威胁，如被黑客攻击的构建脚本、被破坏的构建环境、远程包含意外的软件包等。
虽然漏洞威胁已经伴随我们几十年了，但自2020年以来，供应链威胁一直在成倍增长，原因很简单，不良行为者已经发现了规模经济。以前，他们必须单独针对数百家公司。现在，他们已经意识到，他们可以针对一个单一的软件供应商，而这个软件供应商的成千上万的客户会安装一个被破坏的更新，为他们提供一个潜在的进入点。换句话说，一个单一的攻击可以影响到数千甚至数万家企业。
供应链攻击的这种明显增加反映在Anchore最近的一项研究中，该研究显示超过70%的软件组织在2021年期间的开发工作受到了直接影响。更重要的是，他们遭受重大影响的可能性要大5倍。
因此，拜登总统 呼吁从根本上改变 我们构建和保护用开源组件创建的软件的方式，包括需要。
- 软件材料清单 （SBOM），它提供了一个应用程序中所有软件成分的清单。
- 自动（而不是手动）的 漏洞修复 以减少平均补救时间（MTTR）。
- 建立 源代码出处的能力 ，这样问题就可以被追踪到最终的来源。
虽然这些举措很重要，但软件供应商应该了解其他一些最佳做法，这些做法可以帮助更好地保护他们的开源供应链，首先是他们导入工件库（如JFrog Artifactory）的内容。
你就是你输入的东西**。** 安全地导入开源包
大多数组织已经有了一个开源漏洞程序，通常是由软件组成分析（SCA）工具等自动化。但是，虽然漏洞跟踪很重要，但这只是冰山一角。
为了更好地建立对你导入的开源组件的信任，考虑采用额外的最佳做法，包括。
- 一系列的检查和控制，如验证每个软件包的URL、时间戳、作者、审查者等。
- 一个隔离区来隔离可疑的软件包，因为公共资源库一旦接到通知，就会迅速删除被破坏的软件包。
举个例子，考虑一下我们的 ActiveState平台，它包含了一个开放源码导入管道。这个自动化系统定期检查上游的开源语言库，如PyPI、CPAN、RubyGems等。当我们发现ActiveState平台的目录中还没有的资源时，我们会。
- 下载源代码和相关元数据。
- 对代码进行静态分析，以确保我们的数据是完整的，然后再将其插入我们的目录中。
- 检查流行的漏洞数据库，这样我们就可以用CVE信息增强我们的软件包元数据。
- 定期监测我们摄入的源代码，如果发现它包含木马、恶意软件等，就将其从目录/管道中删除。
但这些控制措施需要大量的时间和资源来实施和维护。作为一个替代方案，你可能想考虑从一个可信的供应商那里导入你的开发人员所需要的软件包。只要记住，这种解决方案不一定是银弹。
信任受信任的供应商。 安全的开放源码构建？
现在，人们已经习惯性地拿出 SolarWinds的例子 来证明一个观点：你的软件构建过程不仅可能被黑客攻击，而且你还可能签署被破坏的输出，并将其作为一个受信任的供应商的安全更新分发到你的客户手中。
不会发生在你身上吧？也许吧，但我们从我们的 软件供应链调查中得知 ，虽然80%的组织至少从源代码中构建了一些他们使用的开源包，但很少有组织实施了安全和完整性控制（见下图），以确保他们构建的工件没有被破坏。更糟糕的是，其中只有22%的人能够创建可复制的构建，这使得我们很难确定原始组件本身是否安全。
相比之下，ActiveState平台提供了一个 安全的构建服务 ，可以按需从源代码和功能中自动构建用户要求的包 。
- 大量使用 缓存 ，以确保可靠、一致和高性能的结果。
- 源代码的离线缓存，以确保 持续的可用性，防止出现诸如 NPM模块被 从存储库中 删除时的问题 。
- 构建脚本，由内部 "配方 "自动生成，并被视为不可改变的资源，防止篡改。
- 容器化构建 ，其中每个容器只由基本资源组成，以减少攻击面（即裸露的操作系统，以及所需的构建工具）。
- 每个构建步骤都在自己的容器中进行， 将构建工作相互隔离 ，防止一个构建工作主动修改另一个。
- 密封的和短暂的容器，这意味着它们不受外部影响，在步骤完成后被丢弃。换句话说，它们不依赖于对互联网的访问或容器中不存在的资源。
- 深度的依赖性解决 ，超出了上游资源库中可能记录的内容。例如，如果一个Python模块依赖于一个PyPI一无所知的C库，我们仍然会从源头上构建它，并在运行时中运送它，所以你不需要从其他地方安装第三方包。
- 依赖关系图的 Merkle树哈希值 ，用于识别我们构建后的所有工件。如果一个依赖关系发生了任何变化（比如新版本的发布），ActiveState平台将重建所有依赖关系，以确保我们发布的东西是一致的，不太可能出现不兼容的情况。
- 可验证的工件， 这意味着平台输出的每一个工件都有安全的校验和以及完整的构建过程日志。
- 所有工件 的来源 ，也就是能够追溯到创建工件的成分，回到它们的来源。这使用户能够验证他们的软件包是以最安全的方式生产的。构建系统应该输出这些信息，作为从源代码导入到依赖关系解决再到产生可安装二进制文件的所有事情的文档。
- ActiveState平台目前遵循这些准则，并将在不久之后为我们的安全构建服务的所有步骤输出来源证明。
通过这种方式，ActiveState平台产生了可验证的可重复的构建，不仅相同的输入总是产生相同的输出，而且产生的工件可以追溯到它们的来源。
结论 - 开源工件的可信存储库
你的应用程序只有在由其构成的模块中才是安全的。这似乎是一句陈词滥调，但令人惊讶的是，有多少组织故意忽略了这句话的后果，宁愿把头埋在沙子里，也不愿意实施有效的解决方案。为什么？这不是他们的核心业务。花费在保障不产生收入的软件供应链上的时间和资源，就是没有花费在编码软件解决方案上的时间和资源。
但是，供应链安全不一定是一个零和游戏。
确保你的软件供应链安全的最简单的方法是，在开始时只从一个值得信赖的合作伙伴那里导入软件包，这些软件包是通过安全构建服务构建的，并且经过了可维护性、安全性和商业应用的审查。这就是ActiveState的可信工件订阅旨在通过ActiveState平台提供的，同时还有。
- 漏洞警报和自动漏洞修复，使您可以更快地解决安全问题。
- 一个机器可读的软件材料清单，其中包括瞬时依赖关系（即依赖关系的依赖）和操作系统级依赖关系，以及。
以类似的方式，我们可以安全地构建您的开发人员所需要的Java、JavaScript、.Net和其他开源语言包，然后定期在您的JFrog Artifactory实例中填充和维护它们。
最重要的是，你的开发人员可以继续使用Artifactory，与现在的工作方式完全一样。考虑到 80%的项目 在将第三方库 纳入代码库后从未更新 ，确保你的团队在编写第一行代码前就开始安全，这比以往任何时候都更重要。
接下来的步骤。
了解ActiveState 如何帮助你降低在JFrog Artifactory中管理开源语言包的风险和开销。 让我们带领你了解该解决方案如何满足你的团队（或团队）的需求。
需要与你团队中的其他人分享这些信息吗？下载我们的解决方案表，其中列出了ActiveState的可信工件订阅带来的好处和功能。
想了解更多？请阅读我们如何帮助您。
