导语：2023年正在如火如荼地进行着。但在进入新的一年之前，我们决定退后一步，反思一下与软件供应链安全有关的开源管理在过去几个月中的变化——以及它将如何在未来几年继续发展。
2023年正在如火如荼地进行着。但在进入新的一年之前，我们决定退后一步，反思一下与软件供应链安全有关的开源管理在过去几个月中的变化——以及它将如何在未来几年继续发展。
软件供应链安全是指识别和解决作为软件开发一部分的技术和流程中的风险的做法。软件供应链中的链接从开发延伸到部署，包括开源依赖项、构建工具、包管理器、测试工具以及介于两者之间的大量内容。 供应链威胁不同于经典攻击（并且可能比传统攻击更具破坏性），因为单个漏洞可能会影响数百甚至数千个不同的目标，并且很难在下游检测问题。 值得注意的软件供应链攻击包括：
事件流
当项目维护者添加并使用恶意代码修改依赖项（flatMap Stream）时，npm 包事件流遭到破坏。如果您更新了事件流包或任何依赖项，并且为 flatMap 流定义了版本范围，则会把存在恶意代码版本拉入代码仓库中。
SolarWinds Orion
黑客获得了对 SolarWinds Orion 平台的访问权限，许多大型组织都使用它进行基础设施监控。Orion 平台被认为是一个单一的、受信任的资源——如果用户从 SolarWinds 下载，他们希望有效载荷来自 SolarWinds。但是，一旦有效载荷被恶意更新，许多SolarWinds用户，包括英特尔，微软，思科和联邦政府机构，都受到了影响。
Codecov Bash 上传器
Codecov 是一种集成到您的 CI 环境中的代码覆盖率工具，当攻击者在公司的 Docker 镜像创建过程出现问题后访问凭据时，它受到了损害。然后，攻击者能够更改Codecov文档并修改用于在CI环境中安装该工具的脚本（包含在文档中）。Twilio，GoDaddy和许多其他Codecov用户都受到了影响。
这些供应链攻击的细节各不相同——一个针对的是开发人员工具，另一个针对开源软件包，还有第三个针对的是专有软件。但共同点是，攻击者通过破坏单个共享资源来攻击多个目标。 鉴于现代软件供应链中存在大量的组件，没有单一的、万无一失的解决方案来应对所有供应链威胁。但是有各种各样的策略和工具可以提供帮助。
软件物料清单 （SBOM）
软件物料清单 （SBOM） 是组件（及其元数据）的列表以及组成软件应用程序的组件之间的关系。SBOM 可用于多种目的，例如满足客户请求、满足政府行政命令带来的监管要求以及支持开源许可证合规性。 另一个越来越重要的用例是软件供应链安全。现代应用程序通常由数十个单独的软件组件构建（这些组件会引入更多的传递依赖关系），这可能使涉及产品的实体（制造商、运营商、买家）难以了解潜在的供应链问题。SBOM 在为组织提供降低风险所需的信息方面发挥着重要作用。生产和使用 SBOM 都有一系列安全优势。
生产 SBOM
使组织能够更轻松地监视其应用程序中的组件是否存在漏
支持为软件组件创建已批准/未批准的列表
帮助组织识别和更换即将报废的组件
节省工程和安全团队识别和审查代码的时间
使用 SBOM
使组织能够快速确定他们是否受到新报告的漏洞的影响帮助团队主动解决可能由报废组件引起的问题支持对组织风险状况的准确评估，并允许更明智地缓解风险
软件组合分析 （SCA）
软件组合分析 （SCA） 已成为帮助组织控制因使用开源软件而产生的风险的日益必要的工具。现代应用程序中OSS的庞大数量 - 平均应用程序使用147个不同的开源组件（这些组件涉及更多的依赖关系） - 使组织难以掌握以下领域的问题：
安全
许可证合规性
代码质量
长期项目可行性
软件组合分析通过自动发现漏洞、许可证和潜在质量问题，然后提供可操作的见解来为补救提供信息，从而帮助团队降低这些风险。最后，SCA 工具通常还包括使团队能够大规模应用安全和许可证合规性策略的功能。（例如，一个组织可能会使用此功能在所有构建中标记具有 GPL 许可组件的任何内容。 许多组织将软件组合分析（只能与开源代码一起使用）与专有代码工具（如 SAST、DAST、IAST 和 RASP）相结合，形成一套完整的应用程序安全测试产品。
就像今天的开源软件世界看起来与十年前大不相同一样，软件组合分析工具自早期以来已经有了很大的发展。虽然SCA最初用于执行手动和定期扫描（通常在IPO等特定事件之前），但今天的工具在确保整个软件开发生命周期中的OSS合规性和安全性方面发挥着不可或缺的作用。 沿着这些思路，我们期望下一代 SCA 工具能够在多个前沿领域提供更丰富的功能集。
策略引擎
下一代策略引擎将使不同的利益相关者能够将审批和自动化作为其日常工作流程的一部分。
开发人员友好
今天的一些 SCA 工具确实集成到 CI/CD 管道和开发人员的本机工作流中。但是，我们越是将SCA构建到开发人员的工作流程中，他们就越容易将风险管理融入到他们的日常生活中。下一代 SCA 解决方案不需要开发人员使用新工具或超越他们以前的经验，这将有助于组织内的整体接受度和效率。代码质量和来源
与提供有关代码来源和质量的指导相比，当今的 SCA 工具在清点依赖项和许可证（以及标记安全问题）方面做得更好。我们预计这种情况将在未来几年有所改变。下一代SCA解决方案将在代码来源（是否来自安全和可信的来源？）和质量（企业可以长期依赖库吗？）方面提供更多实际指导。
下一代报告
今天的 SCA 工具确实提供了一系列报告选项，但未来十年将看到更丰富的功能。我们希望报告以技术和非技术利益相关者都易于理解的格式包含更全面的见解。例如，向销售和客户支持团队近乎实时地提供合规性数据的 SCA 平台可以帮助他们及时解决客户和潜在客户提出的问题。
开源合规风险管理
在下文中，我们将探讨与任务关键型开源管理过程相关的趋势、预测和观察结果。其中包括使用 SBOM 数据、自动执行开源许可证合规性、保持对软件组合的可见性等。
本博客基于两个主要数据点：
对约 100 名知识产权顾问和开源许可合规专业人士开展的小型调查
与客户成功和产品团队进行对话，包括高级产品经理Cortez Frazier Jr.
1. SBOM 将继续成为优先事项，但将更加关注理解和操作 SBOM 数据
我们的知识产权顾问调查问卷的结果以及和大量客户对话都得出了明确的结论，即各行各业的组织都在优先考虑 SBOM。这并不奇怪 - SBOM 有几个重要的用例，包括软件供应链安全、法规遵从性和销售支持等。
但对于 2023 年，我们听到越来越多的组织表示，他们将优先采取更好的措施来操作 SBOM 数据——这在历史上有些困难，原因如下：
现代应用程序由数十种不同的软件组件构建而成，这意味着 SBOM 往往很复杂且难以破译，尤其是在没有正确工具的情况下。
机器可读格式的日益标准化（以及 SBOM 工具的兴起）可以使引入 SBOM 数据变得更加容易。但是，即便如此，解释某些 SBOM 元素（例如不同依赖项之间的关系）仍然很困难。
并非所有 SBOM 工具都具有足够的编程语言覆盖范围，并且某些工具无法与开发管道很好地集成。
某些 SBOM 格式比其他格式更好地支持漏洞数据。
我们预计组织将在 2023 年优先应对这些挑战。这包括围绕在哪里添加 SBOM 工具（例如，添加到集中式 VCS 或中央 CI 系统）、SDLC 工具的哪个部分应该运行（例如构建过程）以及如何为第三方应用程序导入（和使用）SBOM 进行更多讨论（并且更加紧迫）。
知名安全产品经理Cortez Frazier Jr.补充说：“一致的SBOM生成与使用漏洞或可利用性数据丰富SBOM之间的交集是组织开始从SBOM中获得实际价值的地方。”
2. 当前的许可证合规流程是手动且耗时的——这将继续鼓励逐步转向自动化
我们的知识产权顾问调查问卷的一个更令人大开眼界的结果是，许多组织仍然致力于开源许可证合规性管理的大量手动工作。
例如，58%的受访者表示他们仍在手动生成归属通知。而且，只有 26% 的受访者拥有完全自动化的许可证合规性策略实施。
通常，这项工作落在内部法律顾问身上。大多数（73%）的受访者表示，法律团队最终负责生成归属通知。
从历史上看，主流的主要用例之一是帮助组织从手动运行提升到自动运行开源许可证合规性检查。而且，尽管出于预算考虑可能会减缓某些公司向自动化合规的过渡，但我们确实不断听到，这是许多公司的优先事项，无论在任何行业或地区都是如此。
“考虑到在直接和传递依赖关系中发现的许可证合规风险，手动方法不仅耗时，而且可能不准确，因为它与组件使用总量有关，”Frazier Jr.说。
3. 软件组成成分的可见性仍然是一个挑战
SBOM 采用率的增加并没有解决与理解软件组成成分相关的所有挑战。其中最大的两个挑战是：
代码扫描工具（和相关流程）面向直接依赖关系。例如，我们调查中58%的受访者表示，他们的组织将开源许可证合规性限制为直接依赖关系。
代码扫描工具（和相关流程）并不总是使组织能够轻松快速识别他们是否以及在何处使用特定的开源包。
也许由于缺乏可见性而产生的最大的实际问题与组织如何应对零日漏洞有关。当披露严重性漏洞（如 Log4Shell）时，组织必须快速确定他们在哪里使用某个软件包的易受攻击版本（然后成功升级到下一个安全版本）。
但这说起来容易做起来难，特别是对于拥有广泛产品线的大型企业。而且，如果攻击者成功破坏您的环境并引入新的恶意软件包，则可能会特别棘手。
“包管理器依赖项冲突解决只会加剧可见性的缺乏，因为清单文件中定义的包可能与构建时包含的包相对不同，”Frazier Jr. 说。
4. 持续监控您的意愿变得更加重要——即使它以牺牲限制性的早期执行为代价
在任何风险专业人士的工具中，最重要的工具永远是一份准确和最新的资产清单，无论是实物资产，还是我们的数字资产。
这很重要，原因有很多，包括最新的清单使组织能够持续监测其环境。在这种情况下，我们将持续监测定义为在组织 SDLC 的每个构建或源头阶段进行实时软件组件成分分析 （SCA）。随着影响现有开源软件包的新漏洞的出现，组织准确评估总攻击面的能力对于任何威胁建模或缓解活动都至关重要。
沿着这些思路，我们预计团队将越来越多地采取预防措施，以避免可能妨碍持续监测的流程或活动。这方面的一个例子是，在使用新的软件组成成分分析工具时，倾向于实施限制性策略。尽管这些策略的目标令人钦佩，但在实践中，这种方法可能会激励开发团队延迟加入其存储库，直到这些高风险组件被预先消除。而且，这可能会产生隐藏而不是减少风险的意想不到的后果。
相反，为了实现持续监控，我们希望风险专业人员优先考虑：
全面覆盖目标风险状况中的所有代码存储库（例如分布式软件、面向外部的应用程序或具有关键 IP 的应用程序），以构建准确的资产清单
大规模应用规范化的风险识别策略来暴露现有的软件供应链风险
根据组织的内部策略定义，管理与高风险组件相关联的元数据（例如，分布式项目的直接依赖项中的许可证被拒绝，或具有可用修补程序的直接依赖项中的关键漏洞）
除了避免可能妨碍精确组件库存的过程之外，应该考虑使用工具来促进持续监控。“通过将组件覆盖范围优先于限制性执行，风险专业人员将减少内部工具实施摩擦，同时为任何缓解或取证事件定义准确的基础，”Frazier Jr.说。
本文翻译自：https://fossa.com/blog/2023-open-source-management-trends-predictions-observations/如若转载，请注明原文地址
