Language
Country/Area
No result found
开源软体的隐藏危机：你的程式码是否已经受到威胁？
在当前软体开发的环境中，开源软体（OSS）已经成为许多企业和开发者的首选。然而，您是否知道使用开源软体也带来潜在的风险？软体组成分析（SCA）是一个帮助开发者检视其程式码中嵌入的开源组件的方法，它能够检查这些组件是否更新、是否存在安全漏洞或是否符合授权要求。
开源软体正是因为灵活性和降低开发成本，而受到广泛青睐，但背后的风险却被忽视。
风险的背景
自1990年代末期以来，随着开源软体的兴起，这种透过不同组件开发软体的方式变得越来越普遍。这种方式将大型程式码的复杂性划分为更小的部分，以提高灵活性并加速开发过程。然而，随着更多组件的使用，开源软体所带来的风险显然也随之增长，这些风险可以归类为五大类别：
- 版本控制：新版本带来的风险
- 安全性：组件中的漏洞风险 - 常见漏洞与曝光（CVE）
- 授权：知识产权的法律要求风险
- 开发：现有程式码基础与开源软体的相容性风险
- 支援：文档不全和过时组件的风险
对于广泛使用开源组件的组织而言，自动化分析与风险管理正成为必要需求。
SCA的操作原理
SCA产品通常的运作方式如下：首先，扫描引擎会检查软体原始码及其编译所用的相关工件，识别出使用的开源组件及其版本。接着，这些信息会储存于资料库中，形成一个使用的开源组件目录。这个目录接着会与已知安全漏洞、授权要求及历史版本的资料库进行比对。
例如，在进行安全漏洞检测时，这项比对通常是针对在国家漏洞数据库（NVD）中追踪的已知安全漏洞。某些产品可能会使用额外的专有漏洞数据库来进行检查。对于知识产权及法律合规性，SCA产品会提取并评估开源组件使用的授权类型。这些结果通常会以不同的数位格式提供使用者，并会根据不同产品的需求，包含风险评估及法律要求的建议，特别是针对强或弱共享授权的要求。
结果可能还包含服务组件清单（SBOM），详细说明在软体应用中使用的开源组件及其属性。
SCA的使用
随着SCA对不同组织功能的影响，不同团队各自利用这些数据，这通常取决于组织的规模与结构。 IT部门会使用SCA来实施与运营技术，相关的主要利害关系人包括首席信息官（CIO）、首席技术官（CTO）及首席企业架构师（EA）。安全及授权数据通常被首席信息安全官（CISO）用于管理安全风险，而首席IP/合规官则专注于知识产权风险。根据SCA产品的能力，这些工具可以直接在开发者的集成开发环境（IDE）中使用，或者可以作为软体质量控制过程中的一个必要步骤。
在某些国家，像美国等，SBOM的生成需求被规定为强制，以确保供应商交付给政府机构的软体安全。
SCA的优势与劣势
自动化是SCA产品的主要优势。当开发者使用和整合开源组件时，无需手动进行额外工作。这也包括对于间接引用其他开源组件的自动化处理。然而，当前SCA产品也存在一些关键的弱点，例如：部署过程复杂且耗时，可能需要数月才能完全投入运作；每个产品使用自己的专有OSS组件资料库，这些资料库的大小及覆盖率可能差异甚大；而且漏洞数据的限制往往仅报告已在NVD中正式通报的漏洞。
此外，SCA产品常缺乏自动化指导，对报告中的数据行动建议也不足，并且对于检测到的OSS授权的法律要求缺乏指导。
在这样的背景下，您是否也在思考如何更有效地管理开源软体的潜在风险，并保护您的程式码不受威胁？
