第三方技术管理

第三方技术指的是围绕技术引用和实现的技术工具、接口和组件，由于更偏向技术应用，因此往往不在企业的采购清单和计划中，由部门或员工自行进行选择和使用，如上期文章中提到的XCodeGhost事件。

技术工具

技术工具在企业采购中属于小众需求，或不被企业重视的采购需求，在国内多数企业依靠员工自行解决相关的工具需要，除了供应链的安全风险，技术工具还会引起知识产权纠纷，比如：企业收到某某产品公司发来的律师函，称企业内部有使用盗版产品。随着知识产权意识的提高以及相关法律风险的提高，越来越多企业开始统一采购技术工具或产品，比如IDA Pro、Burp Suite、XShell、Windows、Office等等。

对于技术工具带来的供应链风险和影响，常见的方案有三种：

· 终端管控

企业通过采购终端管控系统来实现对于所有员工电脑终端的管理，需要在员工电脑端安装管控软件（员工无法自行卸载，需要管理员密码），管控系统通常还带有网络准入功能，与企业内部的员工账户体系打通可以实现电脑终端的身份认证，同时通过管理端可以检查、限制甚至操作电脑终端的软件运行情况，从而可以对员工使用的应用情况进行统一检查和管理，这也是企业统一采购办公电脑的原因（不会因为人员入职和离职引入终端安全风险或造成终端管理密码泄露，如果是个人电脑，则面临离职后不知道管理员密码，需要重装系统才能卸载管控软件的问题）。在面临知识产权纠纷时，这种方式可以快速对涉及的应用进行排查，同时有利于终端设备统一管理。但该方案需要专门的岗位对终端管控系统进行管理和运营，人员的疏忽和运营的疏忽都会造成该方案形同虚设。

·软件白名单

通过设立软件白名单库，结合企业内网的限制（无法从外网下载软件安装包），可以实现软件来源的限制，确保员工使用的软件都是来自白名单库。白名单库提供日常办公中不同岗位常用的软件，且每款软件都经过安全部门或相关部门的检查和评估，确保每个软件使用的是稳定版本和安全版本。但可能存在，白名单库中软件更新后，员工电脑的软件迟迟未更新所带来的风险，或者员工私自安装其他版本软件造成的安全风险，因此也可以采取终端管控+软件白名单的方式，通过终端监控软件的使用，通过软件白名单库提供安全可靠的软件。

· 云桌面

目前越来越多企业开始采用云桌面的方式来彻底解决终端工具风险的问题，即轻终端、重云端。企业员工通过身份验证访问云端桌面进行日常办公，包括研发工作，可以确保所有的软件在云端都是可控且安全的，但缺陷是会由于网络不稳定或网络延迟造成办公效率降低。

技术接口

无论是企业自研的软件，还是采购的第三方软件或硬件，都可能会存在和需要调用第三方技术接口或使用第三方SDK的情况，由于接口或SDK可能是个人开发，或接口服务提供，因此很难对供应商进行评估和管理。对于接口和SDK的安全评估除了安全检测之外，无法更进一步对接口实现、处理、分析、存储、传输做更多评估，比如：调用物流接口查询快递单号的物流信息，物流接口提供方可能泄露相关的快递单号和物流信息；调用文档格式转换接口，接口提供方可能存储原始文档并泄露相关信息。因此，企业应当对于技术接口和SDK的调用进行梳理和安全评估，确保即便接口提供方出现的安全风险，也在企业可承受范围之内。

对于不得不用的接口调用，可以通过网络边界的流量限制和流量监测确保接口不会被滥用。比如：限制网络出口，或仅允许必要的接口出网，并监测接口调用记录。上文中提到的SolarWinds事件发生后，采取的应急处理办法就是限制Orion软件（后门采用DGA算法生成与C2连接的域名）部署环境的出口，或限制出口访问。

技术组件

开发过程中必不可少的会用到不同开发语言的组件或库，这些组件大多是由个人开发者开发并开源的，虽然方便了开发过程，加速了开发进度，但个人维护的组件常常因为种种原因无法及时更新或升级，以至于一旦被人发现存在某种漏洞，使用组件的企业便需要快速响应和处理，如上文中提到的Log4j的例子。

因此SCA（Software Composition Analysis）工具应运而生，SCA是一类工具的统称，可以通过分析源代码识别其中引用的开源组件信息（名称、版本、校验值）、组件漏洞、开源协议等信息，从而帮助开发人员和安全人员快速对于企业代码中的开源风险进行识别，本质上是对源代码庖丁解牛，现如今的SCA工具能够根据源代码、二进制文件、镜像文件生成SBOM（Software Bill Of Materials）清单，更全面和深入地分析软件构成，比如供应商信息、作者信息、间接引入的组件信息等等，就像食品袋上的配料表，对于软件构成一目了然。上文中提到的Log4j组件漏洞被曝出后，国内的SCA厂商也很快跟进更新了组件漏洞数据，客户可以在短时间内快速排查涉及相关组件的项目、代码以及对应的部门，而在之前安全部门在应急响应中最花费时间的是排查漏洞涉及的项目、部门和人员，而负责项目的研发人员自身也未必全面了解组件的构成情况，因而容易有漏网之鱼。

全面、清晰、深入地掌握软件成分和物料清单，有助于在出现新的安全漏洞时进行快速响应和排查，实际开发过程中，企业常常需要花很长时间排查漏洞影响的组件涉及的业务、部门、项目、代码、人员，并协同相关人员进行漏洞修复或组件升级，而实际上开发人员自己也不见得能够全面了解软件的构成，尤其是组件引用的组件或更深层次的组件。

SCA工具从开发阶段到部署阶段都可以运用，典型的应用场景如下图：

· 企业私服安全管控

私服仓库中的组件安全是开源治理中重要一个环节，只有从源头来杜绝安全问题才能从后期的开源治理中有更好的收获。SCA工具支持多种类型的私服防火墙功能，根据配置的安全策略，实现对私服引入外部组件的实时检测，一旦发现存在风险的组件被引入则执行阻断，做到私服仓库中组件的安全可控。

· 研发流程

研发人员在编码过程中，可以从企业私服仓库调用安全组件，也支持从中央仓库调用开源组件，编码完成后，代码提交至软件版本库，之后通过Jenkins构建持续集成，并将软件制品存入制品库中，等待上线发布。

· SCA开源组件检测

安全人员可以使用SCA工具对软件版本库中的源码和Jenkins构建中生成的二进制文件和容器镜像对软件成分进行检测，发现漏洞组件和不合规组件后，告知开发人员修复至与当前版本差异最小的无漏洞版本。

· 新漏洞预警

SCA工具通过不断更新组件漏洞信息获取新的组件漏洞情报，发现新漏洞后可以及时预警，定位影响的组件、项目等信息，帮助企业在最短时间内掌握信息系统中的开源组件资产和漏洞情报信息。

软件供应链框架

上文提到，供应链安全问题是人、流程和知识的问题，而非纯粹的技术问题。在解决软件研发过程的供应链安全问题时，需要贴合SDLC（软件开发生命周期）考虑供应链安全风险。为此，Goolge提出了SLSA（Supply-chain Levels for Software Artifacts）框架，微软提出了SCIM（Supply Chain Integrity Model）框架以及CNCF（云原生计算基金会）的软件供应链最佳实践，三种框架都强调对于源代码、第三方依赖、构建系统、制品、发布、部署的安全性。

以SLSA框架为例，SLSA是一个标准清单和控制框架，用于缓解软件项目中的代码和软件包的供应链风险。SLSA框架从三个方面评估软件供应链的安全等级，分别是源码、构建和依赖，等级分为4个级别：

· Level 1：构建过程是完全脚本化或自动化，且能够基于结果识别来源源码；

· Level 2：使用有身份认证能力的版本控制和托管服务，确保构建来源是可信的；

· Level 3：源码和构建平台符合可审计标准，且有成品完整性保证；

· Level 4：所有变更均有双人评审，且有封闭的、可重复的构建过程。

典型的软件发布流程如下：

开发者提交代码变更到源码控制管理仓库（SCM），提交动作触发构建流程，构建服务接收源代码并进行编译，之后编译打包的软件包分发到最终用户进行使用，或者进入到私服仓库作为其他项目的依赖包使用。

在SLSA框架中，上图中的发布流程对应的安全风险如下：

以Level 4为例，在软件构建过程中需要实践以下4点：

· 可验证的版本控制

开发人员提交代码变更需要多因子身份认证（如用GPG签名commit）及提交时间戳，必须采用类似GitLab或GitHub的版本控制系统，确保能够跟踪每次变更、代码分支/标签/Ref或提交人；

· 双人评审

每一个进入最终版本的提交都必须经过至少一个其他合格的审查员的评审，确保代码的正确性、安全性、需求吻合和代码质量等等；

· 安全的自动化构建流程/环境

构建流程应当是完全自动化的，且构建环境应该具有隔离性（构建过程不受其他构建影响）、封闭性（构建过程应包含所有依赖关系）、无参化（构建结果只受源代码影响）和短暂性（每次构建都在专门的容器或虚拟机中进行）。

· 可重复构建的流程

相同的源代码构建每次构建的结果总是相同的，并且构建流程是可以验证的。

不足的是，对于最终用户而言，虽然可以使用哈希值对软件包来源进行校验，但无法确保软件包的构建来源是可靠的，仅仅通过校验哈希值无法解决这个问题。因此，构建安全的软件供应链构建流程便尤为重要。

附供应链安全最佳实践

1. 英国国家网络安全中心（NCSC）提出了供应链安全管理准则，分为4个部分的12条：

   · 理解风险（Understand the risks）

2. 理解哪些需要被保护以及为什么；

3. 知道你的供应商是谁，并了解它们的安全状况；

4. 了解供应链带来的安全风险；

   · 建立控制（Establish Control）

5. 和供应商沟通你的安全需求

6. 为供应商设立和沟通最低安全要求

7. 将安全考虑纳入合同流程，并要求供应商也如此

8. 履行你作为供应商和客户的安全责任

9. 在供应链内部提升安全意识

10. 为供应链提供安全事件支持

    · 检查安排（Check your arrangements）

11. 建立保障措施确保供应链管理能够实现

    · 持续改进（Continuous improvement）

12. 鼓励供应链持续改进和提升安全能力

13. 与供应商建立互信关系