解读即将实施的 GB/T 43698-2024 《网络安全技术 软件供应链安全要求》（上篇）
国家标准 GB/T 43698-2024 《网络安全技术 软件供应链安全要求》已经发布并即将实施。
标准全文共23页，泛读可以选择一图流[1]，但精读的话一次解读完就太长了，计划分开上中下三篇结合自己在网络安全和软件工程的实践进行解读。
笔者：国际认证信息系统审计师、软考系统分析师、软件工程硕士
在上一篇信息系统能否原生带有网络安全功能的随想中，笔者简单地提到了软件供应链安全管理应该在信息系统中以面向安全的功能出现，而不只是通过诸如SBOM之类的外部的信息载体出现。
（未看过上一篇的读者可以点这里：从攻防演练想到的：如果信息系统原生就有网络安全功能）
这是因为SBOM只是对最终成品的构成部分的说明清单，既然是清单，那就有可能和最终成品是分离割裂的。但笔者这个设想要实现起来还有相当一段距离。
最近，全国网络安全标准化技术委员会[2]发布了推荐性国家标准 GB/T 43698-2024 《网络安全技术 软件供应链安全要求》[3]（以下简称 GB/T 43698），将于2024年11月1日起实施。
虽然是推荐性标准，但和等级保护的相关国家标准如 GB/T 20269、GB/T 22239 等同理，同样是有可能因为监管要求而成为实质上的强制性标准。
而且，全国网络安全标准化技术委员会也正在就软件物料清单数据格式的国家标准征求意见稿征求意见[4]。显然，GB/T 43698 将会成为软件供应链安全后续系列相关标准被引用的对象。
所以，无论是作为网络安全从业人员或是软件开发者，都理应对 GB/T 43698 给予足够的关注，精读学习。
在笔者个人，是把该标准提出的要求和软件工程实践相结合，以自己的认识谈谈看法。
简单概括适用范围，包括：确定软件供应链安全目标、风险管理要求和供需双方的安全要求，指导供需双方开展管理活动，为第三方机构开展测评活动提供依据，以及供监管部门参考使用。
笔者认为，这里的重点词是“供需双方”，也就是说，供应链风险管理是甲乙双方共同面对的事，不是乙方全责，如果甲方单位总是抱着甩锅给乙方的心态是行不通的。
后面的内容也充分表达了供需双方共同构成软件供应链，安全风险需要双方共同治理的要求。
术语和定义很重要，是标准的核心内容，决定了标准内容的方向。笔者选取认为值得关注的内容进行解读。
1、在 3.1 的注1指出：“软件产品包含计算机程序代码、规程、相关数据、文档和相关服务”。
这一注解，把软件产品的外沿从计算机软件本身扩大了。其中指出包括“规程”是比较特别的。
从管理角度看，软件产品的规程是由软件产品的使用者也就是需方制订和执行的，在软件开发者一侧也就是供方，需要制定的是例如软件开发、测试期间的规程，都不是面向软件最终产品的。
但是在实践中，需方大部分均不具备制订软件产品使用规程的能力，通常是由供方提供蓝本，需方再按自身情况直接采用或修改后采用。可能是因为这种情况，所以 GB/T 43698 明确了规程也在软件供应链范围内。
注解中的“相关服务”，既可以指 SAAS 模式的软件服务，也可以指围绕软件进行的运维服务。对于前者，必然应纳入供应链安全范畴，对于后者，适宜和前述的“规程”共同规范。
2、在 3.2 中指出，软件产品信息是“软件产品版本、标识、来源、授权以及关联软件等信息的总称”。
可以注意此处包含的“授权”。软件的授权，或称为许可证，是软件知识产权领域的长期话题。授权不清晰、不明确以及违反授权要求使用软件，对软件使用者带来的侵权风险不比网络攻击风险低。
曾经收到版权声索函件的单位都应该很清楚。
因此，软件供应链安全要求的实质，超出了一般意义上的网络安全范畴。
3、在 3.4 的注1中指出，“本文件中供方指需方的第一级(直接)供应商；此外,还包括软件产品的开发商、各级销售和代理商、系统集成商，也包括软件或应用商店、代码托管平台、第三方下载站点以及基于开源代码提供软件产品的组织等”。
对此条的理解重点在于，软件在供应链传递过程中涉及的每个单位都会分摊到一定的供应链安全责任。
4、在 3.4 的注2中指出，“开放源代码社区本身不是供方”。同时，在 3.10 指出，开放源代码社区是“用于开源代码和数据开发、维护的一种工程组织和运作方式”。
在笔者理解，这是因为社区的实质是松散聚合，没有固定结构的组织，基于 GPL 等许可证发布的软件代码业已声明不承担任何责任（详见 GPLv3，15. Disclaimer of Warranty.[5]），难以将其纳入供方范围承担供应链安全责任。
对开源社区了解不深的读者，可以读一下 Eric Steven Raymond 的《大教堂与集市》。这书还挺贵，网上貌似曾经有全文。
5、在 3.4 的注3中指出，“供方与需方共同决定软件产品的生命周期结束时间”。
此条对于合同定制软件比较容易明确，但对于商品化的标准化软件产品，尤其是基础软件，一般都只是供方单方面决定，需方并无太大的议价能力，实施起来存在不确定性。
例如，之前 Windows 7 生命周期终止停止更新，即使是监管部门过问也没有产生多少积极的影响。
在笔者角度认为，需方应在供需关系建立时，对由供方单方面决定的软件产品生命周期结束时间，提前做好应对措施（更新换代）和预算。
6、在 3.5 中指出，供应关系是“需方和供方之间为开展业务、提供软件产品而建立的协议、合同等契约关系”。
按此理解，仅当软件源代码按“释放到公共领域”的方式开放时不构成供应关系，除此之外的各种授权协议以至采购合同等，均属于建立供应关系。但还需要排除掉直接从开源社区获得软件（源代码）的情况。
说到底还是谁担责的问题。
7、在 3.11 中指出，外部组件是“由供方以外的组织或人员开发的程序代码、文档或数据，通常是由二进制程序文件或者源代码程序文件构成”，包括软件中使用的开源组件和第三方组件。
外部组件的供方实质上是软件供应活动中供方的供方（参见 3.5 的注：上游的需方同时也是下游的供方），虽然可能不直接出现在构成供应关系的协议和合同中，但依然还是共同构成软件供应链。
在基于信息系统审计角度和实践经验，笔者建议对于合同定制软件，在采购时应把外部组件情况纳入合同范围管理，这样才能降低软件供应链交付风险，保持软件的可用性。
除以上内容外，读者还应能注意到，在 3.8 中提出了软件物料清单的术语和定义。
解析软件供应链安全目标，关键点是建立安全风险管理能力体系。既然是要建立管理体系，读者就应该能理解到 GB/T 43698 这标准为何有23页内容之多了。
1、在安全目标中提到了三种典型的风险情况：软件供应中断、软件功能受限和软件服务降级。其中较少获得关注的是软件服务降级。
服务降级的一种具体但不明显的情况是供方不再发布功能更新而只发布漏洞更新。这与生命周期终止相比，风险相对没那么高，但因为可能影响软件的可用性（此时应默念保密性完整性可用性的信息安全CIA三大特性）而需要慎重对待。
2、安全目标中还列举了一些技术安全风险和知识产权风险。网络安全人员对软件漏洞、后门、篡改伪造这些一般都比较熟悉，但对许可协议不合规这一点由于是涉及到法律层面的风险，即使是软件工程领域的人，懂的人也不多。
笔者建议是如果不懂，就应该引入法务部门或外部专业法律顾问参与进行软件供应链风险评估、软件供需合同评审等事务中。同时还应该参考现有的其他相关标准，比如也是即将实施的 GB/T 43848-2024 《网络安全技术 软件产品开源代码安全评价方法》[6]。
安全风险管理要求是从对供需双方进行规范。
管理体系和安全保护框架是共生的。GB/T 43698 在此处给出了一张3D结构图，描述了软件供应链安全保护框架从组织管理和供应活动两个方面规定了供需双方在基本流程、软件供应链安全图谱、软件供应链安全风险评估、软件供应链安全风险处置四方面的安全要求，具体还需要参见标准的附录A。
为免侵权，下图是我用 LibreOffice + GIMP 对照重绘的：
图1 软件供应链安全保护框架3D结构图
供需双方的要求比对列举如下：
| 组织管理要求 | |
| 需方 | 供方 |
| 机构管理 | 机构管理 |
| 制度管理 | 制度管理 |
| 人员管理 | 人员管理 |
| 供应商管理 | ---- |
| 知识产权管理 | 知识产权管理 |
表1 供需双方组织管理要求比对表
从表1可见，组织管理要求中，供需关系决定了需方要对供方进行供应商管理（供方对需方不存在管理的可能）。
| 供应活动管理 | |
| 需方 | 供方 |
| 基本流程 | 基本流程 |
| 软件采购 | 软件开发 |
| 软件获取 | 软件交付 |
| 软件运维 | 软件运维 |
| 软件废止 | 软件废止 |
表2 供需双方供应活动管理要求比对表
从表2可见，在供应活动管理要求中，供需双方是对等往来的关系。
1、从 6.1 开始，标准从基本流程、软件供应链安全图谱、软件供应链安全风险评估、软件供应链安全风险处置四方面提出了具体的要求。
对于这些要求，笔者就自己的网络安全和软件工程实践提炼出若干影响较大、实施较难的要点。首先是对 6.1 条 基本流程，它包含了a)~f)共6个细项，笔者认为要点包括：
1）软件资产区分为一般软件和关键软件两类资产，按资产性质区别构建软件供应链安全图谱。
分类分级是信息技术领域处理问题的必然方法。标准在此处把软件资产区分为两类，附录B给出的界定依据是“具有或直接依赖包含至少一项特定关键功能属性的软件”，这其实比较模糊。
不过这里先跳过，附录的内容留到下篇。
2）软件供应链要确定对象范围和边界。软件供应链往上游延伸虽然不是无穷无尽，但真要深挖起来，链条长度是蔚为可观。
比如各位读者有没有尝试把计算机设备的固件纳入到软件供应链范围？
管理是需要投入成本的，所以不能无限溯源，要合理界定供应链管理的界限。
换个角度说，就是任何事情都不可能无本生利，虽然笔者就亲历过有人想无本生利。
确定对象、范围和边界，就需要基于正确分类分级的基础，把软件供应链上的各种软件归入合适的分类分级范围，确定管理的边界，避免过度管理而产生成本无底洞。
3）建立和维护供应链安全图谱。这项工作是难度和工作量都兼而有之，比如信息采集和跟踪，执行人员少点专业能力都难以胜任。
而且麻烦在于，需方试图把该项工作转移给供方是不切实际的，除非是需方有且只有一个供方。
4）安全检测、风险评估、风险处置、监督检查，这属于是信息系统审计师已经耳熟能详的，企业信息化治理在风险应对方面的基本工作内容。
但有能力自主实施的需方，即使是同时成为供需双方、有专业底蕴的软件开发企业也不会有很多。
综上，笔者认为对于大多数只是最终用户的软件需方，与其自己努力还做不好，还不如寻求专业且可靠的第三方，外包软件供应链安全管理服务，让更专业的人协助软件需方执行全面的软件资产梳理，建立和维护软件供应链安全图谱。
目前这块服务大致还是网络安全服务市场上的空白，但实现起来难度非常大，具体不展开了，有兴趣可以留言探讨。
2、接下来是对 6.2 软件供应链安全图谱的要求，共有 abc 三项。关键点是需方要先对业务场景进行分类分级，然后安全图谱要基于业务场景的分类分级而同步分类分级建立，定期或按需更新，并按重要资产的级别严格保护。
可以说，分类分级的要求贯穿网络安全的所有细分领域。
另外这里比较绝妙的是，需方的业务上可能本来是没有重要资产的（姑且这样假设），因为建立了软件供应链安全图谱而产生了重要资产。
所以数据分类分级工作不是想省事就能随便地全部定为“一般”的。
3、然后是 6.3 软件供应链安全风险评估的要求。
需要注意的是，这里引用了 GB/T 36637-2018 《信息安全技术 ICT供应链安全风险管理指南》中的风险评估流程的要求，规范软件供应链安全风险评估的过程。
标准条文中指出了需要重点关注的安全风险，并要求风险评估需要对一些比较重要的问题给出是否造成影响的结论。
需要注意到，重点关注的4点安全风险本质既可能是技术原因，也可能是商业、政治等其他原因。而且从大环境来看，政治因素已经成为第一位的软件供应链安全风险。
安全风险的前3点也值得在此处引用一下：“1)发行版本或升级补丁停止交付或部署；2)供方提供的服务部分或完全中断；3)激活等软件授权措施受影响导致软件功能降级或服务能力受限”。
这3点读者应该都不会陌生，对策也应已有所了解。
比较特别的在于安全风险的第4点提到，“供应活动在软件中引入的安全风险破坏发行版本或升级补丁的完整性、安全性和合规性”。其中的“合规性被破坏”，值得发散思考。
笔者设想了一个场景。
需方采购某个已经通过了安全可靠测评认证的软件产品，在供方把软件产品部署到需方 IT 环境时，现场人员擅自在软件产品上加装了来自外部未认证来源的软件组件包：
此时，该软件产品的合规性即被破坏。
读者可以沿着笔者的思路自行设想其它类似性质的场景。
风险因素构成的影响方面，标准也给出了3条典型问题，摘录如下：“1)是否会影响到现有系统的正常安全运行，以及影响范围的大小；2)是否会影响到现有系统的日常维护工作，如：故障排查、故障部件更换、安全事件处置等；3)是否会影响到系统的重新部署、备份、迁移、升级、扩容等工作”。
以上典型问题已经比较全面地概括了信息系统运维的基础工作，对需方给出了足够的提示。
4、最后是 6.4 软件供应链安全风险处置，此条内容作用是引出后面的第7、8章内容。留在下一篇再解读。
就这样，就已经5千多字了，但大头还在后面。
[1] 全国网安标委会 一图读懂国家标准 GB/T 43698-2024《网络安全技术 软件供应链安全要求》
https://mp.weixin.qq.com/s/Huwd2LV33V7UlM4Wwlcgzg
[2] 全国网络安全标准化技术委员会
[3] 国家标准全文公开系统 GB/T 43698-2024 《网络安全技术 软件供应链安全要求》
https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=94FEB278E715BD48566C48804F1A56EC
[4] 关于国家标准《网络安全技术 软件物料清单数据格式》征求意见稿征求意见的通知
[5] GNU General Public License Version 3, 29 June 2007
https://www.gnu.org/licenses/gpl-3.0.en.html
[6] 国家标准全文公开系统 GB/T 43848-2024 《网络安全技术 软件产品开源代码安全评价方法》
https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=CC2F9496C58572E21E60A58F149F294C
本站微信订阅号：
本页网址二维码：