您是否将第三方软件集成到您的应用程序或产品中？
您是否知道这个第三方软件是否存在已知漏洞？
为了提高上市时间和成本限制，软件开发组织转向第三方软件来增强他们的定制开发。事实上，至少90% 的公司使用第三方软件，他们创建的专有或定制软件应用程序中有95% 包含第三方组件。今天的软件栈包括开源软件，以及专门为应用程序或商业软件(COTS)开发的购买的软件。这种购买的软件通常包含组织不知道的开源组件，因为它是以二进制形式交付的。
这个第三方软件有三个主要来源:
1.开放源代码软件(OSS):使用开放开发过程的软件，并被授权包含源代码。
2.商业软件(COTS):从供应商购买的软件。这些通常不需要定制就可以购买。如果在这个软件中使用了开放源码，被许可方可能不知道。以二进制的形式传递。
3.合同软件: 为特定应用程序或一组应用程序交付的软件，通常由合同供应商根据规范提供。开放源码的使用可以在交付时披露，也可以不披露。
根据NSA最近新公布的在ESF框架下主导的《软件供应链安全中对开发者的建议书》一文，NSA将第三方组件的验证分为以下几个关键步骤：
一、第三方二进制文件
第三方软件，有时以二进制格式交付，对工程师或工程师来说就像一个黑匣子。该软件可能没有得到积极维护，并且可能有安全弱点或漏洞。
建议措施：
①二进制扫描和软件成分分析工具（例如UniSCA、Black Duck）往往可以检测到未知文件以及二进制包中包含的开源组件，识别安全性与这些组件相关的弱点，并且这种检测无需源代码。SCA工具可以评估并提供检测到的漏洞的cvss分数。同时验证第三方软件的完整性。扫描结果可以与 SBOM 或第三方提供的源代码进行比较，以核实SBOM。
②开发团队对第三方软件进行二进制扫描，识别潜在威胁，包括未知组件、开源软件组件和漏洞。在组织的决策中应考虑组成分析的输出选择和集成软件组件。
二、选择与整合
在集成第三方组件之前，必须对每个组件进行评估可能与之相关的潜在安全风险。评估包括审查和测试软件。
建议措施：
必须执行 SAST/DAST 和其他适当的审查，例如成分分析，以确定风险是否可接受。一旦确定，源代码（不仅仅是二进制文件）应该是集成到构建环境中，允许构建的安全扫描过程组织批准的环境。只要有可能，组件应该从源代码构建或是从组织安全的制品仓中下载，而不是从互联网上下载。
三、从已知且值得信赖的供应商处获取组件
在考虑选择第三方组件时，应注意与具有安全编码实践记录的知名且值得信赖的供应商建立关系和他们的组件的质量交付。
建议措施：
当组织就其产品的第三方或开源软件的选择、使用、更改或更新做出决定时，应进行风险评估并确保剩余风险是可以接受的。
组织应验证第三方的所有权和控制权状态、他们的数据通用编号系统 (DUNS) 以及供应商的过去表现和其上游供应商（如果有此类信息）。
供应商应生产证明开发过程、质量和安全性的工件，考虑包含在组织的软件产品中的组件的各个方面。此外，组织将编制一份已知的可信赖供应商名单及其已集成到公司产品中的相关工件以及存储库已审核的第三方组件。构成产品的所有组件的记录都在 SBOM 中捕获，以隐含地帮助验证和审查整个产品。受信任的供应商通过以下方式衡量：
①第三方组件满足考虑采用的产品的所有要求。
②第三方组件的质量是经过有效测试结果验证的。
③提供的制品的质量，例如 SBOM 的验证，被验证为是正确的。
④组件的所有者有及时响应已知漏洞的历史，并在第三方组件中进行合规报告。
⑤第三方漏洞报告机制简单易用。采用的组件的所有可用更新都可以使用第三方和开发组之间定义明确且易于理解的更新程序轻松集成到开发环境中。
四、组件维护
一旦选择了第三方组件并将其集成到产品中，就必须小心用于监控供应商对组件的修改，特别是关于解决开发团队报告的已知 CVE 和漏洞，以及该组件的客户社区。
建议措施：
采用产品的组织应监控可用的 CVE 报告机制和第三方支持渠道，以确定在采用的第三方组件中发现的漏洞是否会影响产品并采取适当的措施来解决或缓解脆弱性。
与第三方的合作应解决未来的漏洞。第三方组件的所有者还必须通知产品存在的漏洞、与之相关的风险以及漏洞发生的时间范围寻址并提供给采购组织。
五、SBOM
应在产品的 SBOM 中报告集成第三方组件的详细信息。开发用于轻松验证已批准的组件并在发现缺陷时识别易受攻击的组件的存在。几个规范定义了 SBOM 的格式：
①Linux基金会 “SPDX”
②OWASP “CycloneDX”
③NIST “SWID tags”
建议措施：
第三方组件的供应商或所有者提供的 SBOM 应经过验证和根据需要更新。任何差异都应报告给供应商。为此，软件成分分析 (SCA) 工具应用于第三方可交付的软件。
第三方的 SBOM 可以与 SCA 工具生成的 SBOM 进行比较。二进制扫描SCA工具（例如UniSCA、Black Duck）可以识别来自第三方软件的最终交付内容。
如果供应商没有提供 SBOM，开发团队将获取描述 SBOM 中的第三方组件所需的信息，例如通过利用软件组成分析工具。当开发者修改第三方源代码时，初始 SBOM（如果由供应商提供）和更新的 SBOM，描述增强或原始提供的源中解决的缺陷，可以在 SBOM 的依赖项中定义基本元素。
最后，我们想提醒您一点：依赖成分分析、源代码SCA、二进制SCA都是软件成分分析的手段。依赖成分分析可以解决大部分问题，但事实告诉我们，每次那些棘手的麻烦总是出现在源代码和二进制中。关于源代码SCA和二进制SCA的异同，我们之前有一篇文章专门进行过介绍，此处只放一张对比图以避免不必要的重复。
重要的是，目前同时支持以上三种检测方式的SCA工具屈指可数，例如UniSCA、Black Duck。但显而易见的是，如果您和您的组织想要一步到位，那么选择一款多维度SCA检测能力的自动化工具才是关键。?
?