解读即将实施的 GB/T 43698-2024 《网络安全技术 软件供应链安全要求》（中篇）

继续解读即将实施的 GB/T 43698-2024 《网络安全技术 软件供应链安全要求》[1]（以下主要简称为“标准”或“GB/T 43698”）。

中篇聚焦在标准中的第7章，即需方安全要求，同时解读附录A、附录B和附录C。

未读过上篇的读者点这里：

点赞和转发都是免费的↓ 

鉴于 GB/T 43698 复杂性较高，如有认为笔者理解不到位或者遗漏了关键要点的，欢迎留言指出。

软件需方主要是软件的用户，一般意义上的“甲方”。虽然软件需方也包括同为软件供方的软件开发商，但很显然用户会比开发商多得多，所以对软件需方的安全要求，影响面远比软件供方要大。

在解读第7章之前，先解读在第5章开头引出的附录A 软件供应链安全概述，包含了软件供应链模型、软件供应链实体角色和软件供应链安全构成的关系和定义。

附录A.1 的内容是定义软件供应链模型，通过标准图 A.1 概括表达包含了供应链从上游到下游的各级供需节点，以及供应链管理过程对应开发、交付和使用三个环节的关系。

但这个图，笔者认为应拆分开两个，而不应该挤在一个图里面表现。另外就是供应链上下游各环节的关系表示方式，对于不太熟悉软件供应链的读者来说比较容易误解。

于是我用 LibreOffice Draw 自己画了一个示意图如图1：

图1 软件供应链节点关系示意图

结合标准图A.1，读者对软件供应链的理解应放在：1）最终需方是不产生软件的最终用户；2）除最终需方外，构成供应链的各方实际上必然同时为供需两方，且构成嵌套关系，但标准图A.1对此的表现不够清晰。

附录A.2 是软件供应链实体角色，通过标准图A.2 表达了供需双方与第三方机构的三角关系。此图把第三方机构相对地独立在供需关系之外，但读者也应同时理解第三方机构很可能与需方存在同质的情况。

举个例子是，比如软件供方向软件需方提供某品牌操作系统，在供需关系中提供供应链安全服务的第三方机构刚好也同为该品牌操作系统的用户，那么在“用户”这个性质上，第三方机构和需方就是同质的。

同质有可能构成对第三方机构独立性的影响，软件需方对此应有一定的预期。

附录A.3 是软件供应链安全构成，标准以图A.3 进行表示，读者应基于中间层的开发、交付和使用三个环节和其中的供应活动的定义（即附录A.3.2 和表A.1 的内容），延伸理解下层的“安全风险”（即附录A.3.3 的内容）。

在附录A.3.3.1，定义了供应链风险主要包括供应关系风险、技术风险和知识产权风险3类。这3类风险中，技术风险是最为网络安全人员所熟知的，而供应关系风险、知识产权风险则超出了常规网络安全领域，涉及且可能深入到软件需方的生产经营管理活动。

笔者的观点是，软件供应链风险管理，不能局限在“网络安全技术”去理解。GB/T 43698 归口在全国网络安全标准化技术委员会（TC260）会导致产生限制，影响到软件需方高级管理层对软件供应链安全的理解被降级，以为“这就只是个技术问题”。

笔者亲历原话如此。上位者总存在有无知且不学习的人。

附录A.3.3 的其他部分基本上把所有可能的软件供应链安全风险情况都概括定义了一遍。标准使用人即使不从事软件供应链安全管理，把附录A.3.3 作为知识性了解都是很有用的。

纯为用户的软件需方应重点关注附录A.3.3.9 知识产权非法使用。这在第7章的 7.1.2 条第f)项，以及在 7.1.5 条提出了具体要求，下文再分析。

在此先行提醒的是，除了使用盗版软件的风险之外，如果软件开发商因为知识产权非法使用而引发法律纠纷，其开发的软件的用户也可能会被连带成为被告，被版权方要求停用涉嫌侵权的软件开发商开发的软件。

因此，在软件的采购合同中应强调因软件供应链知识产权诱发的相关法律责任由软件开发商承担。

附录A.3.3.10 关于开源许可证违规使用的风险主要适用于软件开发商。这种情况也并不少见，笔者在下篇再探讨。

在上篇提到，软件供应链安全管理需要对业务场景进行分类分级，且还要先进行软件资产分类，需要参照附录B和附录C进行。

附录B 关键软件资产，是软件在业务中的重要程度分类，包含了对软件需方和软件供方的要求，软件需方因业务和软件的依赖关系而承担了安全责任，而软件供方应按要求提供真实、必要的软件信息，

附录B.1 概述，面向软件需方给出了关键软件资产的说明：“关键软件资产主要指具有或直接依赖包含至少一项特定关键功能属性的软件”，并举例是“处理重要数据、涉及特权操作等”。

在笔者看来，这种描述只是模糊概括。在实践中，首先应关联到数据分类分级，按数据分类分级的结果，确定软件是否处理重要数据，进而确定软件是否属于关键软件资产。

至于从是否涉及特权操作方面进行判断，这隐含了要求软件需方具备规范的IT治理架构，信息化管理层级条块完善，良好地遵循了岗位职责不相容原则，能按人员层级、角色、功能权限及数据访问权限等因素形成授权矩阵从而进行确定。

可能需要提醒部分读者，软件供应链安全要求需要考虑信息系统的整体，数据库、操作系统等基础软件只是其中一部分，切勿见到“特权操作”就理解为数据库管理员账户、操作系统管理员账户等。

附录B.2 关键软件资产清单，需要注意其中的“将关键软件资产所依赖的其他软件纳人关键软件资产清单”。此条也是面向需方的。

也就是说，基于依赖关系，只要软件需方存在关键软件资产，则基本上需方使用的全部软件尤其是基础软件都要纳入到关键软件资产清单范围。

简单举个例子：在OA系统定性为关键软件资产时，如果把考勤打卡机与OA系统相连，使OA系统能获取打卡记录计算上下班情况等人事管理要素，那么考勤打卡机的相关软件基于这个依赖关系也要纳入到关键软件资产清单中。

附录B.3 关键软件资产供应链梳理，此条同时面向供需双方，软件需方应要求软件供方按附录B.3 的要求提供真实、必要的软件信息从a)到j)共10项。

这10项信息相当详细。尤其是第i)项关于产品激活版权控制措施的介绍，真是值得表扬。

不是见多识广的人概括不出来。

笔者建议是在软件采购或信息系统建设合同中，把需要软件供方提供的软件信息明确到合同需求中，尤其是上面提及关于产品激活的版权控制措施情况是纳入到合同的重点，未按合同要求有效激活的软件产品不应视为已经完成交付，不应进行验收。

软件需方需要注意，比较容易忽视的是第j)项要求明确的产品交付过程保护措施。也就是交付物会被篡改破坏其完整性的问题。

笔者在标准解读上篇中，已经设想了在信息系统的部署操作中处于疏忽破坏信息系统合规性的可能情况，合规性也可以视作完整性的一方面。

同样地，不能排除存在故意篡改、破坏信息系统完整性从而实现盗取数据，破坏数据机密性的可能性。尤其是现在都是电子交付，没有光盘之类的可追溯的载体了，所以这个问题值得展开说说。

由于附录B并没有给出如何实现完整性保护的具体措施，需要读者自己斟酌。笔者基于信息系统审计的常规做法，建议软件需方执行如下校验措施：

1）要求软件供方设计软件交付物和校验措施能分离到达软件需方的交付方式，校验措施应包括软件部署前和部署后，也就是不仅需要对软件交付物本身，还需要对构成软件运行整体的每一个文件进行校验；

2）收到软件交付物和校验措施后，首先确认校验措施的完整性；

3）在执行软件部署前，以校验措施对交付物进行校验；

4）在执行软件部署后，以校验措施对部署后的软件进行校验，校验不仅检查是否存在校验值不符的情况，还应找出是否存在不在清单中、额外部署的文件，并将这些情况向软件供方反馈。

具体例子：1）软件需方在软件供方的网站下载软件；2）软件供方确定软件的校验方法是SHA256；3）软件供方以清单给出软件安装包和安装后的每一个单独文件的校验值；4）软件供方向软件需方通过具有法律效力的数字签名进行加密的电子邮件提供校验值清单。

由于国内能提供有法律效力的加密电子邮件的软件供方并不多，一种比较野路子但还能保持一定可靠性的做法是，把校验清单用压缩软件加密打包后通过电子邮件附件提供，该压缩包的密码再通过其他途径（比如打电话）提供。

附录B还要注意的是最后一句，关于核心外部组件的供应链信息。这也是很容易被软件需方忽略的对软件开发商的要求。该要求其实相当高，因为软件开发商需要实现了完整的软件供应链管理才能正确地提供信息。

组织业务场景分类的方法是按软件需方是否关键信息基础设施、按附录B确定的软件资产分类情况和业务场景的价值3个要素划分。

表C.1的阅读顺序有点特别，因此笔者按给出的说明，画出判定过程逻辑图如图2：

图2 组织业务场景分类判定逻辑图

需要注意的是，按表C.1的场景说明内容，判定过程实际还包括了软件需方必须先实施数据分类分级，否则无从判断。所以数据安全是软件供应链安全的前置基础。

以上的判定过程，如果需方是关基设施，那么最低也要归类为“重要”，这没什么争议。但如果需方不是关基设施，是否确定为重要，按场景说明确定的场景价值就可能会存在争议。

一般来说，需方单位都有想尽量把分类分级往低处靠拢的心态，生怕定级定高了就惹上事。

笔者对这个问题的看法是应该实事求是，结合可以投入的资源情况，抓住关键点去确定合适的分类。

比如在场景说明（重要）中指出的，“受到破坏后损害组织、公共利益或社会安全”，此条就可以结合到数据安全的分类分级要求，按受影响数量确定是否符合此条。

最后要注意到表C.1的最右边是软件供应链安全图谱的分级，它和业务场景分类是一一对应关系，简化为下表1：

表1 业务场景分类对应软件供应链安全图谱分级

说完了附录ABC，回到中篇的主要内容即第7章上来。

第7章 需方安全要求，是按在第5章中给出的”软件供应链安全保护框架“的需求管理要求编排组织的，分为组织管理和供应活动管理两大类要求，每类之下再细分为5小类要求。笔者选取每一小类中的重点进行解读。

首先是大类 7.1 组织管理，包含了 7.1.1 ~ 7.1.5 的机构管理、制度管理、人员管理、供应商管理和知识产权管理的要求。

这些内容从结构上理解，和其它方面的风险管理体系的结构是一致的。如果软件需方已经建立起良好的IT治理架构了，那么软件供应链安全管理就是在已有的IT治理架构基础上增加新的治理内容和管理职能、角色等管理要素。

在 7.1.1 机构管理 的内容中，要求明确组织机构或人员的职责范围，提供工作资源和预算，制定和执行安全管理制度，宜设立专职管理机构等，远的不说，和读者应该非常熟悉的 GB/T 22239-2019 《信息安全技术 网络安全等级保护基本要求》[2]的要求是相似的。

具体工作要增加不少。比较典型的，例如 7.1.1 的第b项要求，软件需方“应组织构建并管理软件供应链安全图谱，定期(至少每年一次)开展软件供应链安全检测、风险评估等软件供应链安全风险管理工作，包括但不限于软件成分分析，源代码和二进制代码安全漏洞分析和 6.3 等”。

此条把软件供应链安全图谱与具体管理工作联系起来，构成了关键的工作要求并随之而产生了工作量。

要实现 6.3 软件供应链安全风险评估的工作内容，需要进行如下的技术工作：

1）软件成分分析：这是和SBOM相关联的事情。就如笔者之前曾经提出的，SBOM现在是静态的、在CI/CD期间产生，并随同交付物一起交付给需方的。

随着信息系统投入使用，功能上持续更新或者漏洞持续获得修补，信息系统的SBOM清单就有可能脱离软件本身的实际而落后。这要么是定期核查更新SBOM，要么信息系统自己就能持续更新SBOM。

2）源代码和二进制代码安全漏洞分析：这句话比较容易理解为获得源代码的基于源代码，不获得的基于二进制代码进行漏洞分析。

但实际上，应该从“同时进行”这两者来思考。因为供应链安全需要考虑软件在构建期间会否被植入恶意代码的可能性，读者可参考经典的太阳风公司事件[3]，笔者也撰文讨论过：

因此，即使获得源代码，也应同时对二进制代码进行漏洞分析。

和 7.1.1 的要求相似，软件需方需要在现有的安全管理基础上增加制定针对软件供应链安全的专门制度文件。具体要求执行的工作也比较清晰。

需要注意的是 7.1.2 在第d)项定义了一些相关人员岗位，细分了岗位职责。

现实中大多数软件需方是难以安排如此多岗位人员的，需要在有效的职责分离原则上重组安排人员岗位职责。

另外要注意的是，标准要求制定的制度是涉及多领域的，比如采购管理、供应商管理和知识产权管理等，这些都不是纯粹的网络安全部门甚至信息化部门的自主范畴。

因此，在软件需方内部，需要横向协调调动相关职能的管理部门参与共同制定制度。这就需要需方内部具备比较良好的IT治理架构和沟通协作机制才能实现。

如果软件需方内部法人治理不清晰，层级错位，IT治理缺失，管理空泛（多见于没有按现代企业制度要求改革的国有企业），则不仅软件供应链安全管理，包括网络安全、数据安全管理都会被卡在制度建设无法落实和推行，后续的安全管理实务均无从谈起。

以上情况，笔者也是亲历。

对于需方的要求和网络安全等级保护的人员要求相似，读者也可以参考笔者之前对 GB／T 42446-2023 《信息安全技术 网络安全从业人员能力基本要求》[4] 的解读，按该标准的要求招募人员，或培训提升人员的管理和技术水平：

在笔者看来，标准这里的人员能力要求对于大部分仅为用户的软件需方来说要求实在太高。即使是同为供需双方的软件开发商，对其内部人员而言也显得很高。

由于现在信息技术领域分工已经很细，软件开发人员和网络安全人员之间的鸿沟比较宽广。比如 7.1.3 第 a) 项中列出的几种能力要求，仅具备网络安全渗透测试能力还不足够，还需要有一定的软件工程、系统分析和软件开发能力。能横跨这些领域的人太少（笔者或者算一个），况且需方也基本不可能有能力配置这样的人。

再结合到第e)和f)两项要求内容，软件需方必然是需要通过外部服务才能支撑实现，但由于工作量大，外部服务力量很难同时支撑多个软件需方，因此实施起来的成本和复杂度都相当大。

供应商管理的管理难度和复杂度也都颇高。简单概括，要么软件需方具备对软件供应商开展信息系统审计的能力，要么寻求第三方信息系统审计服务机构对软件供应商开展审计。

需要注意此条的“供应商”大致等同于软件供方，但不一定是开发商。

具体首先要注意的是 7.1.4 的第c项，要求软件供应商应符合 8.2 的要求，标准对软件需方的要求笔者放到下篇再具体解读，读者可以自己先行理解。

然后是第d)项，要对供应商进行背景、资质、能力以及能否持续安全提供产品或服务的风险分析。如前所述，仅此一项，软件需方就要有信息系统审计能力的人，又或者委托具备该能力的服务机构对供应商开展全面审计。

提醒一下读者，需要区分网络安全审计和信息系统审计，后者的审计范围比前者大得多。

再如第g)项，软件需方需要能有效跟踪软件供应商发生的重大经营情况变更，这对于一般的网络安全或信息化部门来说明显是能力超越。

因为按职责分离的一般设计，网络安全和信息化部门都不负责采购，IT资产的管理性质是协助资产管理部门管理。问题在于负责采购或负责资产管理的部门不太可能具备此类主动跟踪收集情报的能力。

其实可以说白一点：情报收集、风险评估、风险控制，这一套标准组合拳，大量的软件需方是不具备的。

最难在于第h)项，要求建立供应商替代方案或具备相应软件的自主维护能力。这一项比较理想化，需要非常高的人员技术水平和成本投入才能实现。

这条和后面 7.2.2 的第e)项大致上是同一件事，后面会详细说说。

在笔者的经验中，对于财税软件比较容易实现这一项要求。此类软件共性明显，具备大量第三方运维服务机构，可以外包实现维护。

至于其他难以寻找到第三方服务机构的软件，简单描述一下就是要基于对软件开发商的审计评估结果，由软件开发商提供详细技术资料、维护指南甚至源代码，软件需方自己具备开发人员，吸收掌握后实现能自主维护。

各位读者可以自己评估一下可行性。

7.1.5 并不是提出知识产权的具体管理要求，而是知识产权管理实务中的侵权风险控制要求。

这是因为国家版权局早已经发布了《正版软件管理工作指南》，所以标准不需要多说。只是该工作指南不是标准，所以不能直接引用。

笔者的建议是联合法务部门、资产管理责任部门并咨询外部法律顾问开展知识产权风险评估和设计控制措施。

接下来是大类 7.2 供应活动管理，包含了 7.2.1 ~ 7.2.5 基本流程、软件采购、软件获取、软件运维和软件废止的要求。供应活动管理是整个软件供应链管理具体过程的安全要求。

7.2.1 基本流程是关于采购活动中合同内容和合同执行的要求，没有什么特别，笔者就跳过不说了。

标准对软件采购活动过程中的安全要求列出了a)~k)共11项，内容全面且细致，甚至在内容上显得实施指南比要求还多。

内容越全面越细致，执行的难度和资源需求就越高。几乎每个小项都可以对应细化为若干条制度要求外加一或多份SOP，并产生相关的执行记录。

所以管理工作量也就相当大。

先说说第d)项内容关于软件激活的选择方法。该项内容更多地属于教程而不是要求。对不那么熟悉软件许可和激活的软件需方来说帮助很大。

只是笔者觉得标准对此写得那么具体，一定程度上等于认可了那些在笔者看来是挖空心思想出来目的只是厂商利益最大化的激活措施。不过这也是无可奈何的了。

再看看笔者认为最难实现的第e)项，“应制定从多个源厂商获得兼容的产品和服务的方案，确保软件来源的多样性。对于单一来源的软件，应制定风险消减措施。”。

难实现是因为该条和 7.1.4 的第h)项是同一件事的不同表述，要求的理想化程度很高。

从实践上看，此条只可能对基础软件或商品化的软件标准版有意义，可定制的软件难以满足此项要求。

但是，在实践中，不同厂商之间号称相互兼容的基础软件的真实兼容性，即使放在 X86 这个单一运行环境也不能100%保证。

开发商必然想和客户深度绑定，于是就会添加专属的扩展，只要客户的信息系统依赖于这些扩展，绑定就完成了，兼容性就成了纸上谈兵。

在信创领域情况更加复杂。信息系统要做基础软件的适配，基础软件要做信创硬件的适配，这一连串的适配结果，对同类基础软件之间的兼容是巨大的挑战，可以说在现阶段就是个问号。

因此，要实现第e)项的要求，最大的前提就是如何尽可能地提高信息化环境的兼容性。笔者之前专门对国产化替代如何选择操作系统简单谈了一下自己的方法，供读者参考：

面向定制软件的第f)项，实质是对软件供方中的开发商的要求，软件需方需要按要求对软件开发商进行符合性的核查或审计。

定制软件的关键特性在于一旦投入使用后就与开发商形成或深或浅的绑定关系，所以软件开发商的安全情况务必要在开始建设之前做好摸查考核。

后面第h、i、j三项的要求共同特点是需要比较大的资源投入。第h)项是对人的要求，第i)项是对运维环境的要求，第j)项是对软件需方要掂量一下自己斤两以及兜里有多少钱的要求......说笑的。

但确实是只有极少的一部分需方（典型如关基设施）才可能具备和必须具备应对外部不可抗力的能力。

最后的第k)项为典型的需要寻求外部服务实现的要求。

标准在本条给出了5项在软件获取过程中应实现的安全要求。主要目的就是在前面附录B.3第j)项说过的，要确保软件的完整性不被破坏。整条内容偏技术性，笔者认为可以转化为1个制度再加上若干SOP而实现。

除了确保完整性外，读者应关注其中的第c)项，该项的目的是避免软件在安装后的默认状态下就存在安全漏洞。熟悉网络安全管理的读者应该对这种风险和相应的控制措施并不陌生。

第d)、e)两项，要求软件需方对定制软件需要掌握其技术，获得完整的技术资料，在需要后续开发时获得必要的知识产权授权等，这依然是对前面 7.1.4 条第 h) 项 和 7.2.2 条第 e) 项在不同角度的重复强调，此处更为具体。

对于确实不具备这些开发能力的需方而言，有一种解决办法就是寻求软件源代码托管服务：通过合同约定，在原软件开发商不能为软件提供后续维护时，由软件需方确定的第三方服务机构接管软件源代码继续提供维护。只是此类服务国内没怎么听说过有。

但即使如此，在实践中还需要对原软件开发商的情况和软件代码的可持续开发属性进行跟踪，否则到了若干年后才突然发现源代码已经远远脱离IT环境实际，无法继续维护，也是有可能的。

软件运维的安全要求不少，共a)~l)12项要求。一些比较清晰的要求只需要补充一下具体细节就可以转化为制度和SOP等内控文件。但要完整地执行这些要求，依然需要投入大量资源才能完成增加的工作量。

比如第c)项，建立可追溯台账并及时维护更新软件供应链安全图谱和第i)项，收集软件供应链的安全风险信息并进行相应处置，这些情报收集工作不仅需要人力投入还不容易见效，在前面 7.1.4 第g)项已经说过。

又如第d)项，如果对标等保要求的软件补丁管理和记录的要求，可见软件供应链安全管理的要求更为细致和复杂。比如要求从安全可控的渠道获取软件软件补丁，安装补丁前要进行CIA三性检测分析等。

再如第f)项，对运维人员要明确访问权限，区分访问范围和期限等，转化到实践中就是不仅管理上，在技术上也要实现职责分离。这对人员队伍的数量和能力水平都会提出要求。尤其是人员数量是硬成本。

软件废止需要联系到软件生命周期，是软件生命周期结束时的安全要求。

第a)~f)的6项要求中，第d)项要求把旧软件的数据迁移到新软件，是比较难实现的一条。

要做到这一条，前面 7.2.3 的第d)、e)项，软件需方都要能做到。

这是因为，绝对不能指望旧软件的开发商能主动、完整地把和有关数据迁移的所有信息告诉新软件的开发商。

要注意第e)项关于数据销毁的要求，需要参考 GB/T 37988-2019 《信息安全技术 数据安全能力成熟度模型》[5]实施。

另外，软件需方在软件废止的具体实践中，还需要结合无形资产管理，同步做好摊销减值等相关工作。

标准行文可以理想化和前瞻，但作为软件需方要面对如何执行实现的问题。

要么因地制宜对标准要求进行裁剪，但可能会造成合规偏离问题。尤其是信创政策导致的产业技术碎片化，实际最终都还是要靠时间来解决。

本篇解读洋洋洒洒9千余字，可能在用词上会有校对不到位不够统一的情况。至于标准第8章及附录D，笔者就留到下篇解读啦。

参考资料：

[1] GB/T 43698-2024 《网络安全技术 软件供应链安全要求》

https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=94FEB278E715BD48566C48804F1A56EC

[2] GB/T 22239-2019 《信息安全技术 网络安全等级保护基本要求》

https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF

[3] 专题·供应链安全 | 对“太阳风”网络攻击事件的深度剖析

https://mp.weixin.qq.com/s/DRUrS6sfFHIWXISWAKMpUQ

[4] GB／T 42446-2023 《信息安全技术 网络安全从业人员能力基本要求》

https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=AD7E0F02219B63653BF850759A1030C4

[5] GB/T 37988-2019 《信息安全技术 数据安全能力成熟度模型》

https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=3CFD5E5A14C24D303EA1E139E6EB75C8

还可以看看这些内容：