供应链安全事件的频频爆发，使得供应链安全管理越来越被政府和企业重视。企业供应链中可能导致安全风险的因素非常复杂，如果没有良好的供应链安全管理和风险控制，由于供应链导致的安全风险会急剧增加，企业甚至难以了解攻击是如何发生，这样就难以避免和防范下一次类似的攻击。

　　供应链系统安全概述

　　与企业信息安全管理类似，供应链安全管理并不是纯粹的IT问题，而是人、流程和知识的综合因素。在供应链庞杂的环境中，需要从攻击者的角度进行安全防御建设。与传统的信息安全不同的是，供应链安全涉及到物理世界与信息世界的交互，两者之间并无间隙，且相互影响。

　　其中，供应链系统安全涉及到的方面包括企业供应链管理中的：

　　从与供应商的商务关系到供应商的技术管理和实践，相关的风险又依次包括：

　　第三方供应商：供应商企业健康状况和企业实力

　　供应商安全实践：供应商内部安全管理和安全实践

　　被攻陷的软件、硬件：供应商提供的产品可能被攻击者掌握

　　软件、硬件的安全漏洞：供应商提供的产品本身存在安全漏洞

　　软件、硬件的恶意代码：供应商提供的产品被植入了后门、木马

　　第三方数据泄露或数据聚合：供应商存储的客户数据泄露或供应商通过数据分析获取客户机密/秘密

　　除此之外，还包括企业自身在技术活动中引入的第三方技术，比如开发人员在编程中引用的第三方开源或商业组件、调用的SDK（Software Development Kit）、使用的开发工具或运维工具（IDE、IDE插件、数据库连接管理工具、服务器连接管理工具）等。

　　当下很多企业在从事诸如驻场服务、驻场咨询、现场交付等等活动的过程中，还会涉及到与供应商或供应商人员的身份认证、授权、权限管理以及数据分享的问题，比如企业在财务审计中需要将财报信息同步给事务所人员、安全公司驻场为企业提供渗透测试服务、供应商交付人员在企业办公场所进行产品交付、配置工作。

　　所以供应链安全本质上是企业管理自身管理范围之外的一系列相关企业、产品、技术、人员、流程，并期望相关企业和人员具备不低于企业自身安全水平的安全成熟度。

　　从技术供应的角度，企业供应链系统安全的风险来源如下图：

　　供应商管理和采购

　　当前，每家企业都需要借助其他供应商的能力完善自身的生产能力，在选择供应商和进行采购活动之前，企业自身需要完善相关的供应商管理制度或机制。

　　根据ISO27002（信息安全控制实用规则），涉及到供应商安全的规范包括：

　　供应商关系的信息安全：供应商遵守的信息安全策略、供应商协议的安全问题、信息和通信技术供应链；

　　供应商服务交付管理：监视和评审、变更管理。

　　供应商关系的信息安全是指企业应当与供应商就供应产品或服务过程中，供应商人员应当遵守的最低安全要求和安全策略，确保供应商对于企业信息资产的访问是安全可控的，并明确双方合作中安全风险的处置原则和要求。供应商服务交付管理是为保障供应商的交付物保持一定的安全和质量水准，并确保交付变更不会带来新的安全风险。

　　根据SOC2（美国注册会计师协会开发的针对行业服务的审计标准）的合规要求，企业在供应商管理中需要具备：

　　在选择和评估供应商时，需要评估供应商的商务信息和技术能力，商务信息包括：法人、注册地、员工规模、注册资本、股权结构、融资信息、企业资质、过去三年工商变更信息或工商处罚信息，技术能力包括：安全资质、安全白皮书、安全实践描述（基础安全、数据安全、漏洞管理、人员管理等）、开发实践描述（开发团队、开发流程等）。

　　商务信息可以通过被动调查的方式从诸如天眼查、企查查获取供应商的相关信息，技术能力可以通过问卷调查的方式由供应商主动提供，调查的方式除供应商自述之外，还可要求提供相关的系统截图或代码截图证明相关的能力。

　　更进一步，可以在供应商的授权下，采用穿行测试、漏洞测试的方法，对于供应商系统进行安全审查和评估，范围包括安全合规、安全要求、安全设计、安全漏洞，确保供应商的提供的产品符合企业的安全要求。

　　供应商评估的目的是为了让企业了解供应商的以下信息：

　　供应商的软件/硬件研发过程是否有文档、可复制、可衡量；

　　产品研发过程中是否有缓解漏洞的措施和手段；

　　供应商的漏洞管理能力是怎样的，是否有发现、跟踪、验证、关闭漏洞能力；

　　供应商的配置管理和质量管理是怎样的，如何确保不会因配置导致安全风险，以及确保质量符合要求；

　　恶意软件/后门是如何检测、防护、清理的；

　　数据管理生命周期中数据采集、存储、使用、销毁是如何的，包括保护、加密、留存、销毁；

　　人员安全是如何实践的，包括人员背景审查和审计、关键岗位保密协议和能力验证等等；

　　产品发布过程是如何保障安全的，是否有发布审核、批准和验证流程。

　　在设定供应商的准入门槛，评估供应商符合要求之后，相关的供应商应当进入企业的供应商名单。在与供应商进行合同签约过程中，依然要考虑合同内容中的安全要求、责权信息，明确双方的义务与权利，以及SLA中的产品、服务等级、质量以及赔偿方式和赔偿内容。

　　供应商连续性管理

　　供应链中相同的第三方产品或服务不应当只有当前已采购的，还应当维护一定量的备用供应商和后备产品服务。这需要企业在供应链管理中考虑以下三点：

　　供应商的合作等级：取决于供应商的实力，比如钻石级、白金级、白银级；

　　供应链的安全风险等级：供应商提供的产品或服务在保密性、完整性、可用性方面对企业造成的风险级别；

　　安全风险的缓解措施：包括企业自身的替代能力，和其他供应商的替代能力；

　　企业自身供应链风险的评估内容包括：

　　在风险识别过程中，有很大的机会能够发现企业内部的重复采购或无效采购，尤其是没有统一的采购部门，或采购部门没有记录和管理采购内容的情况。在没有统一采购部门的情况下，安全部门可以和财务部门进行协作，安全部门的供应链风险评估结果与财务部门进行同步，前者把握风险关，后者把控资金关，避免无效采购或重复采购。

　　供应商质量管理

　　对于已经合作的供应商，企业应当每年进行一次供应商评估，定期评估可以让企业掌握供应商的企业风险和产品/服务风险，避免由于供应商风险造成的企业自身风险。定期评估的内容可参考上文供应商管理和采购部分的内容。

　　对于在产品使用和服务过程中出现的安全事件，企业应当进行验证、记录、反馈，并督促供应商整改，对于事件的严重等级按照风险进行划分，并基于供应商准入门槛以及合同中的要求评估是否继续采用该供应商的产品或服务。对于发生严重事件并影响到企业安全的供应商，或持续不符合供应要求的供应商，企业可以采用供应商降级或解约的方式将供应商从供应商名单中剔除。

　　质量不佳的供应商不仅无法维持企业供应链安全的质量和要求，而且会消耗企业大量的管理成本、运营成本与供应商进行反复沟通、整改、验证工作，最终的结果可能依然不符合要求，勉强的合作让企业的采购得不偿失。

　　第三方技术管理

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

　　技术工具

　　技术工具在企业采购中属于小众需求，或不被企业重视的采购需求，在国内多数企业依靠员工自行解决相关的工具需要，除了供应链的安全风险，技术工具还会引起知识产权纠纷。对于技术工具带来的供应链风险和影响，常见的方案有三种：

　　终端管控

　　企业通过采购终端管控系统来实现对于所有员工电脑终端的管理，需要在员工电脑端安装管控软件（员工无法自行卸载，需要管理员密码），管控系统通常还带有网络准入功能，与企业内部的员工账户体系打通可以实现电脑终端的身份认证，同时通过管理端可以检查、限制甚至操作电脑终端的软件运行情况，从而可以对员工使用的应用情况进行统一检查和管理。但该方案需要专门的岗位对终端管控系统进行管理和运营，人员的疏忽和运营的疏忽都会造成该方案形同虚设。

　　软件白名单

　　通过设立软件白名单库，结合企业内网的限制（无法从外网下载软件安装包），可以实现软件来源的限制，确保员工使用的软件都是来自白名单库。但白名单库中软件更新后，员工电脑的软件迟迟未更新同样会带来风险，因此也可以采取终端管控+软件白名单的方式，保障软件白名单库提供安全可靠的软件。

　　云桌面

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

　　技术接口

　　无论是企业自研的软件，还是采购的第三方软件或硬件，都可能会存在和需要调用第三方技术接口或使用第三方SDK的情况，由于接口或SDK可能是个人开发，或接口服务提供，因此很难对供应商进行评估和管理。因此，企业应当对于技术接口和SDK的调用进行梳理和安全评估，确保即便接口提供方出现的安全风险，也在企业可承受范围之内。对于不得不用的接口调用，可以通过网络边界的流量限制和流量监测确保接口不会被滥用。

　　技术组件

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

　　因此SCA（Software Composition Analysis）工具应运而生，SCA是一类工具的统称，可以通过分析源代码识别其中引用的开源组件信息（名称、版本、校验值）、组件漏洞、开源协议等信息，从而帮助开发人员和安全人员快速对于企业代码中的开源风险进行识别。全面、清晰、深入地掌握软件成分和物料清单，有助于在出现新的安全漏洞时进行快速响应和排查。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：所有变更均有双人评审，且有封闭的、可重复的构建过程；

　　在SLSA框架中，应用系统的发布流程会存在以下安全风险：

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

　　可验证的版本控制

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

　　双人评审

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

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

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

　　可重复构建的流程

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

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

　　附、供应链安全最佳实践

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

　　理解风险（Understand the risks）

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

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

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

　　建立控制（Establish Control）

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

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

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

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

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

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

　　检查安排（Check your arrangements）

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

　　持续改进（Continuous improvement）

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

　　与供应商建立互信关系

更多信息可以来这里获取==>>电子技术应用-AET<<