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

继续解读即将实施的 GB/T 43698-2024 《网络安全技术软件供应链安全要求》[1]（以下简称为“标准”或“GB/T 43698”）。本篇聚焦在标准中的第8章，即供方安全要求，以及与供方关系紧密的附录D。

本篇近万字。笔者从自己系统分析师、信息系统审计师的视角，结合工作实践中的软件供应链管理、无形资产管理等领域的经验对标准条文进行分析。

点赞和转发都是免费的↓

笔者：	国际认证信息系统审计师（CISA）软考系统分析师软件工程硕士

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

笔者所写的标准解读上篇和中篇在此：

软件供方通常会被理解为软件的开发商。但除了不生产软件的最终用户之外，软件供应链上的所有供方都必然同时为需方，需要由其它供方向其提供生产软件所需要的其它软件组件、软件工具等软件产品。

读者可以先回顾标准图1 软件供应链安全保护框架（标准正文第5章），或者参考笔者自绘的图（实话说，标准图1太难看了）：

图1 软件供应链安全保护框架示意图

一	附录D 软件供应链安全图谱

在解读第8章之前，先解读附录D。笔者在中篇提到，附录D适合和对供方的要求一起解读。因为软件供应链安全图谱（以下或简称“安全图谱”）主要产生来源必然是由供方产生而不是需方产生。

这里有个隐含点就是大部分需方不仅没有能力产生软件供应链安全图谱，还很有可能根本读不懂供方提供的安全图谱。

因此，可预见的是如果要实施监督机制，那必然首先是对软件供方实施软件供应链安全图谱质量的监督。

所以就作为软件供方来说，对附录D的理解，是理解好标准第7、8两章尤其是第8章的重要前提。

1、D.1 图谱构成

附录D.1指出，“软件供应链安全图谱包含软件产品信息、软件物料清单和安全信息3方面内容”，并特地解释了安全信息是技术安全和合规安全两类信息的总和。

技术安全容易理解，合规安全这个词仅从网络安全技术角度看会理解得很狭窄，所以值得展开说说。

合规安全重点是“规”的范围，这必然是从国家法律、行政性法规开始，到强制性标准或者事实上强制性的推荐性标准，再到软件供需双方自行制定的制度和操作规程，最后是供需双方就软件供应所签订的采购合同和授权协议。

所以合规安全是超出网络安全技术范畴的。

附录D.1还指出，软件供应链安全图谱可由软件需方、软件供方或者第三方机构构建或生成。就如笔者在本篇前面就说了，软件需方自行产生图谱基本上是不可能的事，第三方服务机构有可能具备这个能力，但并不能100%保证生成的图谱正确。

具体地，如果第三方机构未能从软件开发商处获取软件的源代码，仅凭逆向技术是难以准确地描绘出软件的供应链安全图谱中的物料清单的。

而且，软件供应链安全并不完全体现在最终交付的软件产品的源代码。CI/CD环节所依赖的各种软件工具是软件供应链安全的关键因素，但无法从最终交付的软件产品或软件产品的源代码获知和CI/CD环节相关的供应链信息。

所以软件供应链安全图谱的生成，首要责任是在作为软件开发商的软件供方。软件需方或者为软件需方服务的第三方机构，基于软件开发商提供的软件产品的供应链安全图谱，添加补充需方IT环境的软件供应链要素，最终形成完整的软件供应链安全图谱。

2、D.2 实体要素

实体要素分两级，第一级3个分类，第二级8个分类。具体通过表D.1软件供应链安全图谱实体要素清单列出。

要素清单对每一个分类项目都给出了分类名称、实体要素名称、要素的说明、和对应到三种不同级别图谱的指引也就是打钩标记，并建议凡是打钩项都是必选。

清单对实体要素的说明内容，不知道是否为了排版美观而显得比较简单，而且有些内容在标准正文没有出现，读者需要有一定背景知识或者自主学习能力。

要正确建立软件供应链安全图谱，就必须正确理解标准表D.1的分类和要素之间的关系。

1）首先是把标准表D.1三个大类之间的关系转化为数据库表关系理解。

一级分类的软件产品信息实际是主表，一级分类的软件物料清单、安全信息是两个子表。三者构成的关系，如下图2。

图2 软件供应链安全图谱一级分类关系示意图

安全信息是子表比较容易理解。而软件物料清单也是子表，需要从软件发生变更会导致软件物料清单也发生变更，从而需要保留历史清单去理解。

软件开发商在对待组件变更导致软件变更的具体措施上，一般有两种情况：

第一种是尽可能维持软件与其依赖的组件版本关系不变。这种做法对开发商的好处和复杂性不在这里讨论，显然是这种情况下软件物料清单会很少甚至完全不发生变化。

这种做法的负面是组件的安全漏洞除非开发商自己有能力修补（类似于Linux 发行版的向后移植（backport）操作[2]，否则就永远有漏洞。

顺带说一句对于等保测评现场测评工程师，必须正确理解向后移植，否则在客户现场都是闹笑话。

第二种是软件产品跟随其依赖的组件版本变更而变更。这种情况其实更适合现在快速变化的软件供应链环境，尤其是漏洞层出不穷的时候紧跟组件版本变更会更容易完成漏洞修补。

但这种做法就会导致软件物料清单频繁变化，并带来新版本的组件可能会和原有代码、运行环境不兼容而导致要全面升级的不稳定因素。

所以并没有哪种方法是一劳永逸的。

2）其次是确定二级分类哪些要素是原子性的。

一级分类（主表）包含的4个二级分类及其下的要素，存在两种情况。

第一种情况是该要素的信息是原子性的（不可细分的），可以将其等同于表中的单个字段理解，典型如要素“软件名称”。

第二种是非原子性的，应按管理需要对其进行解析和拆分为多个字段的信息，典型如要素“完整性验证”。

3）再次是分析哪些非原子性的要素应细化展开为子表。

如前所述，不具备原子性的要素不仅要细分，还可能要展开为子表。

比如“软件来源”的“供方”要素。虽然在说明中指出仅是“直接供应商”，但来源链条上可能会出现开发商、总代理商、代理商、集成商等多种角色（参见标准附录A 软件供应链安全概述，或笔者写的标准解读的中篇），从精细化管理角度，就应完整地记录，那就必然要展开为子表。

又如“源开发商”要素。由于软件工程也存在分包的情况，所以软件可能是多个开发商合作开发的。同样是基于精细化管理，就应该记录到具体分包是哪个软件开发商负责开发了什么。如果只记录总包开发商，在发生安全事件时应急处置是会掉链子的。

再如“软件授权”要素。有信息化管理实践经验的读者就知道，同一种商品软件可能会多次、分别采购不同的授权方式、授权时长和授权数量，管理起来是很头痛的事，所以该分类必然是个子表，要扩充增加更多的信息项。

4）对非原子性的要素进行扩充。

有些非原子性的要素不一定需要细化展开为子表，但肯定要拆分增加字段才能完整。

比如“完整性标识”，应拆分为“完整性校验方法”和“完整性校验值”，笔者在标准解读的中篇已经探讨过了。

又如“引入组件数量”，虽然要素名称是“数量”，但结合说明内容“开源、第三方、自主研制”这寥寥数字，起码应理解为“引入组件分类情况”而不仅仅是数量。再结合区别于一级分类的软件物料清单，笔者认为在此处应包括有：

组件总数量、三种不同来源的组件数量、与第二部分软件物料清单每个组件的关联编号。

也就是“引入组件数量”要拆分为多个字段，其中“每个组件的关联编号”既可聚合在一个字段内记录，也可进一步分解为子表。

5）最后是哪些要素是隐含外联要求的。

信息化治理不能出现数据孤岛，网络安全也包括在内。

例如上面已经举过例子的二级分类中的软件授权。授权信息可以是无形资产，应和无形资产管理实现关联。

比较关键的是属于一级分类的安全信息。因为软件图谱不可能无穷无尽地把信息都聚合进去，安全信息是需要适度外联以丰富其信息量的，比如外联到 CVE、CNVD 等漏洞详细信息的公告说明页等。

还有值得细究的是，一级分类软件产品信息的最后一项二级分类“关联软件”。表格中简单地把该分类的要素表述为软件1，软件2，......的“软件产品信息”。这样的表述会导致疑问：究竟是否需要把关联软件按一级分类的全部要素要求收集其信息纳入图谱，这会不会导致图谱无穷无尽？

在笔者理解，此处应该首先保证属于软件需方无形资产范围内的关联软件都建立图谱和关联；其次是对不属于无形资产范围但确有必要的，经过管理程序确认后建立图谱和关联，由此还需要外联到该软件图谱的有效来源。

经过如此细分关联后的示意图如图3：

图3 软件供应链安全图谱分类及要素关系示意图

理解完整体后，再详细说一下局部。除了刚才举例子说明的要素之外，很多要素都必然是需要调整和扩充的，举例如下：

1）需要补充关联的，比如第二大类软件物料清单中的“组件来源”要素。

说明中列出的三种来源，实质是把更多的实际来源情况抽象为了三种情况（暂称为抽象来源）。第二大类的软件物料清单作为第一大类软件产品信息的子表，其中的“组件来源”不仅需要在说明给出的“组件提供商”和“源供应商”的基础上进一步细化，还需要补充和抽象来源的关系。

2）需要格式化内容的，比如第二大类软件物料清单中的“生成阶段”、“许可协议”等要素。

“生成阶段”是增强级图谱的内容，但说明文字只表述为“软件供应活动”是没说清楚的，应该进行格式化定义，具体比如“源代码阶段”、“构建阶段”、“运行阶段”等。

笔者认为如果该项只是普通的文本描述，那对于软件物料清单信息的后续利用是没有帮助的。“许可协议”同理，但比较清晰，已经有公共认可的定义，直接使用就行。

3）需要支持富文本的，比如漏洞修复、漏洞利用这些涉及处置过程的，要能支持富文本才能比较完整地表示。

3、D.3 软件供应链安全图谱元素关系

标准通过图D.1表示的软件供应链安全图谱元素关系，实质是多种关系的总和。

其中，调用关系是软件在运行上的动态关系；引用关系无论是直接抑或是间接，都既可能是动态运行关系也可能是静态依赖关系；存在关系......好吧，哲学概念都用上了。

笔者补充一点：其中属于属性关系的线条没有做说明，比如软件和软件产品信息的要素、组件和软件物料清单的要素，这些都是属性关系。

二	8 供方安全要求、8.1 组织管理

理解好、理解透附录D，就可以回头具体看看第8章供方安全要求的内容了。

第8章共有9条要求，框架上相对需方安全要求基本上是对等平衡的。可以参考标准的第5章图1，或者笔者在标准解读上篇中给出的表格。具体不同只是供方安全要求少了一条供应商管理，但读者应该已经掌握到软件供方基本上同时也是软件需方。

在内容上，笔者认为供方安全要求比需方安全要求明显更技术性，执行起来的复杂性更高。

先看看 8.1 组织管理，包含有 8.1.1~8.1.5 共5条要求。

1、 8.1.1. 机构管理

机构管理共3项要求，第a)项提出要明确专门的职责机构和人员，资源要匹配保障，预算要有所体现。

等级保护标准 GB/T 20269-2006 《信息安全技术信息系统安全管理要求》中也有相似的要求（4.1 信息系统安全管理的内容 ......落实安全管理机构及安全管理人员，明确角色与职责......）[3]。

但等级保护标准内容没有明确地涉及到“预算”，等保测评也不会去评审被评审单位为了实施网络安全所编制的预算计划的真实性和有效性。

但 8.1.1 第a)项要求，“在预算管理过程中予以重点考虑”，这就是采纳了信息系统审计的概念。

在信息系统审计中，对资源和预算的计划和执行情况是审计的重点。因为不可能无中生有，不可能无本生利，我在标准解读的中篇已经明确了这个观点。

如果做了预算但不予执行，这实际就是没有履行合规要求。

8.1.1的b)项提出了对图谱和安全风险两者的相关执行要求，具体到要求进行何种检测。

值得注意的是该项要求在表述上先于制度流程机制即第c)项的要求。笔者理解认为，软件供应链安全要充分强调实践的重要性，制度等管理要求是围绕和支撑安全实践而建立的。

2、8.1.2 制度管理

制度管理具体共5项要求，涉及制度框架、风险管理、供应活动管理、人员管理和知识产权管理。标准这5项要求和后面各条都有关联性，此处的表述是高度概括。读者在理解标准后面各条要求时要回溯到此条。

软件供方需要将这些要求转换为具体的制度和规程，转换后的文字量一点也不少。

3、8.1.3 人员管理

人员管理在制度管理的第d)项有表述，在此处提出了5项具体要求，这些要求和等级保护对人员管理的要求有相似之处，比如职责、权限、授权、培训、离职交接等。

在笔者看来，这5项要求大多数软件供方目前是不满足的。人员管理相对容易实现，但因职责分工而产生的人员数量要求，以及因软件供应链风险管理具体工作而产生人员能力要求，就不容易满足。

从现有人员中选拔合适的人，加大培训力度是目前软件供方最现实的解决办法。

4、8.1.4 知识产权管理

这一条包括两项要求，内容比较精简。但这并不代表对知识产权管理的要求就可以松懈。

笔者在标准解读中篇就明确表达了软件供应链安全不仅仅是网络安全，所以在网络安全标准中不好表述跨界的非技术性因素的观点。同时在标准解读中篇对附录A.3.3.1的解读也清晰地说明了，知识产权风险因素导致的软件供应链安全风险一点都不比技术性的风险因素低。

但软件的知识产权管理核心在于法律框架的遵循与运用、通过法律事务活动保护知识产权合法权益、避免出现法律问题，这些显然是超出了本标准的范畴。所以标准精简表述了安全要求而没有具体展开，是可以理解的。

三	8.2 供应活动管理

接下来是 8.2 供应活动管理，包含了 8.1.1~8.1.5 共5条要求。

5、8.2.1 基本流程

基本流程也就是关于采购活动中合同内容和合同执行的要求，和 7.2.1 的内容基本一致，就是供需双方换了个位置，其内容只要是采购或销售相关岗位的人员都不应该陌生。

6、8.2.2 软件开发

很明显这一条对属于软件开发商的供方必然是重头戏。

标准给出的从a)到l)共有12项要求。这12项中，笔者认为一些正常的软件开发商会主动去做的事情，就不解读了。重点放在比较关键的要求项上。

首先，8.2.2 第a)项是门槛性质的要求，其指出，软件开发的供方要达到2个门槛任一，分别是：

1）按GB/T 30998-2014 《信息技术软件安全保障规范》[4]的第6章，开展软件开发的安全保障分析。

GB/T 30998-2014 标准的内容也是很多的，全文共有28页。第6章标题是“软件开发的安全保障分析”，是对从软件的需求分析开始，包括设计、实现和测试在内的软件生命周期全过程每个阶段应执行的软件安全任务的描述。

也就是软件供应链上属于软件开发商的环节的内部安全要求。

相比下一个门槛的资质要求，因为资质的获取需要过程还不一定能拿得到，所以这个开展安全保障分析的门槛等于是最低要求。

2）具备安全开发资质比如信息安全服务资质(安全开发类)、软件安全开发服务资质等。

这两个资质，前者是中国信息安全测评中心提出的，后者是中国网络安全审查认证和市场监管大数据中心提出的，软件供方按需要提出申请，在通过评审后便可获取。

第b)项是软件供方对软件产品的资产管理和版权保护的要求，其中提到对开发过程要实施安全机制。这里要和后面的第h)项联系起来看。

第c)项要求建立安全图谱，保障完备性和准确性。这两个属性是评判安全图谱是否有效的因素。

第d)项提出的“可追溯性的策略和程序”等等内容，是对软件供方提出的情报收集和情报管理的能力要求，也是第h)项的前置要求。该要求不容易满足，需要具备此类能力的人员。理论上可以通过外部信息服务实现支撑，但笔者目前未见有此类专项信息服务。

第e)项提出软件供方需要确定软件的安全需求基线和防护架构。这一点是从软件的外围角度提出的保护要求，软件供方可以联系网络安全和数据安全的相关要求进行设计。

比较重要的是第f)项，要求软件供方对外部组件进行承诺。笔者认为该项的表述是把安全责任前移固化在供应链最接近软件需方的软件开发商供方一级上，但该项的内在非常复杂。

笔者认为，该项的复杂性在于，由于漏洞的发掘是动态发生的，软件开发商作为外部组件的使用方只可能承诺在某个时间点之前的已公开漏洞已修复，不可能无限期地承诺。但即使如此，依然可能不能及时修复漏洞，因为这取决于该外部组件的开发商，也就是供应链的上游。

而对于已公开未修复的漏洞，最低要求是提供漏洞分析和处置报告。处置报告并不等于消除风险，在外部组件的开发商未能修复漏洞时，处置报告就只能是未能消除风险。这样的处置报告软件需方肯定不接受。

第g)项是第f)项的延续，外部组件的安全管理要求。由于第f)项确定了责任归属，相应地软件供方就应执行必要的安全管理工作确保能履行第f)项的要求。需要注意的是该项会产生较多的工作量和成本支出。

第h)项、第i)项均为第d)项的具体工作要求，难点也就是在前面提出的软件供应需要具备情报收集和管理能力。对于第i)项所指难以验证来源的工具、外部组件，笔者认为解决方法是软件供方应在学习、吸收的基础上自行重写。

第j)项、第k)项是开发环境的安全要求，都需要软件供方具备足够的资源才能满足，尤其是多个开发环境的逻辑隔离并不比物理隔离容易，甚至物理隔离可能还简单直接一些。

最后是第l)项，属于兜底性质概括供需双方应共同开展软件供应链安全检测和风险评估工作，不需要展开讲了。

7、8.2.3 软件交付

软件交付环节的安全风险和控制措施是最少被软件需方关注的。但行内专家对此都知道该环节的风险一点不少。比如曾经发生的 XCodeGhost 事件[5]，实质就是在交付环节出现问题。

在 8.2.3 条，标准对软件供方如何做好交付环节的供应链安全也给出了12项要求。一点不比对软件需方的要求少。所以读者应再次巩固在供应链安全管理上，供需双方是对等的关系这个知识点。

第a)项是关于软件在交付过程中的完整性保护的要求。读者可以对应笔者在标准解读的中篇，关于附录B.3 第j)项，就供方如何控制该环节的风险所提出的实践措施。

第b)项明确提出，由软件供方提供软件供应链安全图谱，并提供和执行软件的安全部署和安全配置。

现在的情况往往是软件开发商完全不管安全，扔给软件需方的网络安全运维人员，但网络安全运维人员对软件的内在情况并不熟悉。因此，两方之间对软件了解程度的差距就会产生安全漏洞。所以标准此项要求是要消除这种情况。

软件供应商对此条要求的执行，等于需要对现有的交付过程实现两次交付，也就是在初始化部署之后再进行一次安全配置部署，然后转入同步验收。

但安全部署所需要的安全配置基线制定和配置的能力，超出了大多数软件开发商现场部署人员的能力，因为现场情况不一定是软件开发商所能提前预见的，所以安全配置基线是有可能在部署同期需要适配调整的。

要应对这项要求，软件供方除了人员招聘或加强培训外，还有一种可能的解决办法是寻求专业外包服务，也即是结合接下来的第c)、d)两项要求。

在第c)项中，要求供方要承诺不存在已公开漏洞未修复的情况。但供方的承诺对软件需方而言是说服力不足的，且承诺内容对供方自己会产生新的风险。

结合到第d)项，供方应进行各种安全检测，那么b)、c)、d)三项就可以合并在一起，委托第三方服务机构进行这些现场安全配置和安全检测验证作为风险缓解措施，从而在满足的标准要求的同时能把风险转移出去。

对于第e)项，除了供方要自主声明外，关键在于供方要采取有效的技术措施约束自身人员滥用远程访问手段，从软件需方获得非法利益。此项和8.2.4 第h)项其实是一致的，无论是交付过程抑或运维过程，供方都需要自我约束。由于问题在运维过程更普遍出现，所以笔者在 8.2.4 的第h)项再详细讨论。

第f)项比较特别，要求提供交付环节变化的通报、交付途径安全性分析报告以及补救措施。

对于提供定制开发软件产品的供方，此项要求大致上不涉及，因为交付过程通常都是一次性，后续功能或漏洞修补的交付途径通常是人和人的对接，结合有效的完整性验证措施后可控性、可追溯性都很高。

所以该项主要影响的是以商品形式、通过公共途径比如网络下载方式交付软件的供方。因为这种交付方式的风险因素相对较高，且在发生变化时，有可能造成现存用户中断获得更新。

最典型的例子就是网站SSL证书过期没有续期，导致用户无法获得更新，这事情即使是大厂也发生过。

第g)、h)、i)项是对交付物的安全相关要求，内容比较容易理解，但供方要能提供符合该要求的交付物，会导致新增了责任、工作量和工作的复杂性。例如h)项所要求的，软件供方要保障外部组件的安全性和提供与交付的软件相同的质量、安全、服务承诺。

第k)项是标准对分包集成的软件项目把软件供应链安全的责任明确在总包。这看上去也就是一句话的事，但总包的安全责任就无法往分包方推了，要把分包方的软件供应链安全管起来。

第l)项列举了安全检测的具体细分方式，不需要展开。

8、8.2.4 软件运维

软件运维在软件供需双方之间的关系，笔者所见有些情况真是一言难尽，甚至是典型的相爱相杀。

标准对软件供方的运维提出的安全要求共8项。略过易懂的第a)项不提，笔者认为应该重点关注的包括：

第b)项中需要负责进行协调的供方，理解上首先是总集成商或者总包开发商，其次包括使用了第三方组件的开发商。

第c)项要求建立“可追溯台账”实现软件供应链安全图谱的更新和维持。这就对应上了笔者对附录D的解读，需要对软件的物料清单和安全信息从保留历史记录的角度去理解和建立安全图谱。

第d)项和第e)项是相关的。因为第e)项的内容中就提到了“停止授权”这种情况，所以笔者认为在行文上应调整，在第d)项提出要求定期开展软件供应链安全检测和风险评估，然后在第e)项要求把授权风险纳入到整体风险作为其中一种。

第f)项完全是非技术性的要求，对于供方是进口软件代理商的，需要认真考虑如何做好相应的准备应对可能出现的不可抗力因素。

第g)项涉及到数据安全，实质是软件供方要能有效约束软件运维人员。

在这里笔者确实要说一下。软件运维和数据安全必然是紧密关联的，但现实中软件供方的运维人员漠视数据安全是常态。无论大小开发商都是动不动就要“复制全套数据进行测试”。国内数一数二的ERP供应商派出的运维人员连最起码要具备的数据脱敏工具都没有，扯皮到最后是笔者亲身上阵直接DELETE记录和把敏感数据字段UPDATE为NULL。

第h)项实际是重复了 8.2.3 第e)项的要求。这两项要求要联系起来执行，笔者在上面也指出了这一点。但这一项的描述简明扼要显得有点空泛，笔者认为可以补充，应参考等保中的人员角色定义，按职责不相容的要求安排人员担任不同的角色，分工开展软件运维。

其实如果真正参与过软件运维工作，这一项是可以直接细分列出应区分哪些权限而定义角色，安排角色负责执行哪些运维内容，以及哪些工作在角色之间是可以临时转办。

笔者还见识过软件开发商派出的现场运维人员，私自在服务器上设置远程访问手段，被甲方网络安全及信息化部门发现后阻止，现场运维人员还认为甲方是在制造障碍。

所以，软件供方的自律，包括对人员的教育和约束的重要性可见一斑。

9、8.2.5 软件废止

最后也是软件废止，对应软件需方要求的 7.2.5 软件废止。共有3项具体要求。

由于物权（无形资产的使用授权）已经归属软件需方，这三项要求对软件供方主要体现的是工作协助、技术支持和保障的作用。

回到标准本身。笔者注意到标准的第c)项“新软件应采取如下措施”，这里明显是漏了字，应该是“新软件的供方”。

按 8.2.5 第c)项的表述，其实隐含就是指同一个供方。因为从运维要求角度，需要废止的旧软件，其供方只应运维旧软件，对不是自己开发的新软件不具备运维能力，也不应该去运维。

其实，就如笔者在中篇对 7.2.5 的解读中指出的，冀望旧软件供方协助软件需方从旧软件转移数据到新软件，是不太现实的事情。除非新旧软件都是同一个软件供方提供。

软件需方并不能仅凭一份推荐性标准实现对软件供方的制约，关键还是要纳入到合同，通过法律实现约束。

至于现实中经常碰到的不同供应商之间的软件数据迁移，笔者认为旧供方应该本着钱财身外物，山水有相逢而帮人帮到底，送佛送到西。