2.3 验证第三方组件
-
二进制扫描和软件成分分析工具经常可以检测到二进制包中含有的开源组件和未知文件,不需要源代码的情况下,发现与这些组件相关的安全弱点。工具可以对检测到的漏洞进行评估并打分。高度建议这些活动以验证第三方软件的完整性。输出可以和SBOM对比,或和第三方提供的源代码对比,验证SBOM。 -
开发团队扫描第三方软件二进制软件,识别潜在的威胁,包括未知组件、开源软件组件和漏洞。组织的决策应考虑成分分析的结果,选择和集成软件组件。请参第2.3.2节“选择和集成”,2.3.3节“从知名和信任的供应商获取组件”,寻找更多的信息。
-
第三方组件满足考虑采用的产品的所有要求。 -
软件采用组织根据检测结果验证第三方部件的质量。 -
所提供制品的质量,例如SBOM的验证,被验证为是正确的。 -
组件的所有者报告对第三方组件内已知漏洞及时响应的历史记录。 -
第三方漏洞上报机制使用方便。采用的组件所有可用更新易于很好地集成到开发环境中,第三方和开发小组之间,使用良好定义和容易理解的更新流程。
-
Linux基金会项目的“软件包数据交换(SPDX)。” -
OWASP “CycloneDX。” -
NIST“软件识别(SWID)标签。”
-
持续集成/持续部署。在这种情况下,软件安装在云中,进行即时反馈和A/B测试, -
构建软件作为快速迭代循环的一部分,例如使用敏捷开发方法。生成的软件可以分发给客户,也可以用于测试,并不分发, -
构建软件为开源项目的一部分,其中可执行文件没有作为项目的一个输出来分发。在这种情况下,由构建产生的软件旨在作为测试的基线,并在开发周期的早期识别问题。
-
渗透开发网络。 -
执行扫描以定位代码库和构建系统,并识别漏洞。 -
设计一个漏洞来破坏构建系统或代码库(或两者都有)。 -
部署攻击。
-
编译后的源代码, -
包含库, -
当库恢复到有漏洞的旧第三方库时重新引入, -
常驻内存,它在编译时通过rootkit嵌入到源代码中-源代码在代码库中没有被修改, -
网络中间人(MITM)攻击,它在被拉取时修改源代码来构建系统。
-
完全锁定, -
免受外部和非局域网(LAN)活动的影响, -
监控数据泄漏,特别是源代码库和工程工作站, -
配置以防止渗透和泄露。
-
将构建脚本和配置文件置于相同的代码审查过程中,如第2.2.1节“内部人员修改或利用源代码”中所列, -
对管道配置使用版本控制, -
确保每个系统都要求多因素认证, -
将工程网络与公司网络分离, -
减少并定期审计服务账户, -
记录所有对构建管道的访问, -
保护与构建管道相关的任何机密凭证。
-
必须在可信的控制平面中获取所有制品, -
不允许可变引用, -
必须验证每个制品的完整性, -
在运行构建步骤时必须阻止网络访问。
-
建立和维护一个权威的数据源和代码库,对已批准和实施的系统组件,提供一个可信的源代码和问责制,参见NIST SP800-172第3.4节定义, -
使用自动化机制来检测配置错误或未经授权的系统组件;检测后,采用打补丁、重新配置或移除已识别的组件等手段进行修复, -
使用自动发现和管理工具来维护系统组件最新的、完整的、准确的、现成的目录, -
在建立网络连接之前,使用基于密码学和防重放的双向认证。根据NIST SP800-172第3.5节[任务:组织已定义的系统和系统组件]的说明进行识别和认证, -
采用自动化机制来生成、保护、轮换和管理不支持多因素认证和复杂帐户管理的系统和系统组件的密码, -
使用自动或手动/程序机制来禁止系统组件连接到组织系统,除非组件是已知的、经过验证的、处于正确配置状态,或在可信的配置文件中, -
使用一种方法来允许对比从两个或多个不同的、隔离的、受保护和安全的环境中构建出的二进制文件,
-
SSDF PO.3(实施支持工具链),特别是PO.3.2和PO.3.3,因为工具链在构建过程中使用。 -
SSDF PO.4(软件安全检查定义标准),特别是PO.4.2,收集构建信息,支持安全标准。 -
SSDF PS.1(保护所有形式的代码免受未经授权的访问),特别是PS.1.1,生成PS.2.1中的信息,并实施PS.3.1。 -
SSDF PW.6(配置编译和构建流程)。 -
SSDF PW.8(测试可执行代码),如果测试被设计和作为构建过程一部分运行和验证。 -
SSDF PW.9(将软件配置为默认的安全设置),特别是作为架构一部分、实现和维护构建过程。 -
SSDF RV.1(持续识别和确认漏洞),特别是RV.1.2,自动代码扫描可能是构建过程的一部分。
-
实现强身份验证方法,如强壮密码、证书、双因素身份验证(MFA),以及保护签名基础设施的物理访问控制。 -
控制用户对签名基础设施的访问,使用最小权限,用户离开或终止后撤销凭证,用于代码提交的MFA,以及使用行为分析的持续身份验证。 -
在物理上隔离的网段进行代码签名。 -
在代码签名环境中使用入侵检测和防御系统保护所使用的代码签名资源、机器和过程。 -
部署和使用安全信息和事件管理(SIEM)系统。 -
在传输和存储时使用密码。 -
加固签名环境系统,允许客户部署和安装经过签名和验证的发布包及产品。 -
使用集中的日志服务器(只能追加、加密等) -
确保签名系统符合基本安全标准。 -
物理和远程访问需要多方批准,并记录所有访问。 -
只向少数签名系统管理员授予超级用户访问权限。 -
实施以下间接控制:
-
定期进行漏洞扫描(网络和web应用程序), -
定期进行渗透测试(网络、web、无线和红队), -
对文件进行适当分类(机密、绝密等), -
在文件上使用水印, -
使用数据防泄密(DLP)工具, -
通过销毁方法来适当地处理物理介质, -
通过擦除的方式妥善处理数字媒体, -
监控/执行可执行文件、库、配置文件等的完整性检查。
-
二进制软件组成分析工具可以调查最终可交付成果到底包含了什么,并在成品包中识别上面描述的潜在的问题。开发人员应该运行二进制扫描或组成分析工具,并确保产品交付前的完整性。该工具可以检测潜在的漏洞和威胁—包括来源不明的软件(SOUP)和无意包括在最终包中的机密凭证,并为客户生成成品包的SBOM。 -
组织可以比较二进制分析输出和其他构建过程产生的制品,以确保成品包只包含预期的软件组件。收到后,在部署之前,客户可以运行二进制软件组成工具来评估风险,通过验证交付代码的内容。客户可以继续使用该工具对后期部署进行持续监控漏洞。 -
供应商和客户运行二进制扫描或成分分析工具来验证开发人员提供的最终软件包或更新的完整性。开发者可以将SBOM包含在最终的包中。这可能取决于在开发人员和客户之间合同或安排。SBOM应该包含最终产品所有主要的(顶层)的组件,列出了它们所有的传递依赖项。根据与客户、供应商或开发人员的合同提供了进一步的细节。
-
产品级:
-
产品分发包哈希/数字签名, -
产品更新的哈希/数字签名, -
产品升级的哈希/数字签名。
-
分发包中产品组件的哈希/数字签名。
-
保护所有形式的代码免受未经授权的访问(SSDF PS.1)。正如前一节描述,开发人员可采取下列缓解措施:
-
成品库:应用信息安全管理标准或指南保护成品库, -
包管理器:应用安全的开发过程,给客户提供安全和最新包管理器, -
分发系统传输层安全:选择、配置和使用NIST SP 800-52 rev.2推荐的传输层安全实现。
原文始发于微信公众号(安全行者老霍):保护软件供应链:开发人员实践指南(下)
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论