供应链安全管理体系介绍，陈曦：信息系统供应链安全管理入门

以下为实录：

0x01 前言

随着云原生、开源中间件、应用容器化等技术的广泛应用，软件/信息系统供应链攻击开始逐步向多元化发展，并且逐步成为勒索软件和APT的最喜爱使用的攻击方式。据2021年7月发布的《2020年中国网络安全报告》称，软件供应链攻击已成为2020年最具影响力的高级威胁之一[2]。

目前，供应链攻击的频率和成熟度在不断提高。根据行业估计，供应链攻击现在占所有网络攻击的50％学什么技能好，去年同比激增了 78％。多达三分之二的公司经历了至少一次供应链攻击事件。同时，80%的IT专业人士认为软件供应链攻击将是他们的企业在未来三年面临的最大网络威胁之一。[3]

值此全国大型攻防演练之际，如何理解、应对和响应供应链攻击，提升供应链安全管理能力。无论是演练期间还是常态化运营期间，均能够对此类风险做到有效感知和控制，是摆在安全从业人员面前的一道难题。

本文作为“金融业企业安全建设实践群”（简称实践群）的一次分享，笔者尝试分享在供应链安全管理方面的学习心得，抛砖引玉，供读者参考。

成文仓促、水平有限，如果错误，欢迎随时批评指正。

0x02 供应链攻击和供应链安全管理

供应链攻击目前尚没有清晰的定义，通常可以认为指的是攻击者通过攻击或者篡改信息系统在其生产构建过程中所依赖的组件（a.k.a 构件、）、工具、服务等，对信息系统植入恶意代码或者后门，以达到进一步攻击目标的目的。

由于供应链的传递性，攻击行为将会对供应链的下游所有节点产生影响。攻击者也将利用供应链条上的信任关系逃避检测或者扩大部署范围，从而实现非常有效的攻击效果。

供应链安全管理就是对供应链条上各个环节可能出现的风险有针对性地建设能力，从发现、处置响应等方面展开工作，建设能力，降低供应链攻击发生时对组织的影响。

供应链安全的复杂度在于一旦供应链攻击实施成功，理论上攻击影响的范围是供应链条在这个节点之后的所有范围。这些范围由于企业经营活动的其他方面交织，进而造成灾难性的后果。从正向建设的角度，不仅仅需要关注软件开发过程，同时也需要关注信息系统在开发、构建、测试、发布、运维甚至售后全生命周期的完整性和第三方可信问题。

图0. 供应链安全管理的维度

0x03 软件开发完整性检测

提出了 SLSA （- for ）[4]作为检测端到端供应链完整性的框架。其中详细定义了如何减轻整个软件供应链中的威胁和提供合理的安全保证。

SLSA框架中定义了八种风险，将其作为软件开发完整性检测的抓手。并详细阐述了这些风险项是如何作用于软件产品开发过程中的三大要素，即制品（）, 流程（）和平台（）。

图1. SLSA

编号

威胁

案例

SLSA 建议

提交恶意代码

伪君子提交[5]:研究人员尝试通过邮件列表上面的补丁故意将漏洞引入内核

Tow- ：虽然不能够发现全部问题，但是能够发现大部分问题。

有缺陷的代码托管平台

PHP[6]：攻击者入侵了PHP的自托管git，进行了两个恶意提交。

加强对代码托管服务器的保护。

使用官方（正常）的构建平台进行构建，但被构建的代码脱离控制

[7]：攻击者篡改了CI/CD 流程中使用的代码源文件。

按照SLSA的构建要求，构建过程中可以追溯代码出处或者实际来源，从而能够检测到此类篡改。

有缺陷的CI/CD平台

[8]:构建平台被攻击者植入了恶意程序，使得每次构建产物带毒。

增加构建平台的安全保护

有问题的依赖

-:攻击者添加了一个无关紧要的递归依赖，并从一个非官方源更新了这个依赖。

严格控制递归依赖，依赖的来源必须是可信源。

上传恶意制品

:攻击者上传了一个恶意制品到存储桶，用户下载时下载到了恶意制品

发布使用的存储桶内的制品需要确定来源，确保是通过正常的构建过程构建出来的。

有问题的镜像源

攻击者上传有问题的制品到镜像源

相近名称的安装包投毒

安装包投毒[10]:攻击者在PyPI官方仓库上传了 恶意包，该恶意包通过伪造著名 库 包名来进行钓鱼， 攻击者可对受感染的主机进行入侵，并实施窃取用户敏感信息及数字货币密钥、种植持久化后门、命令控制等一系列活动。

注：没有使用的原版例子，个人觉得国内的这个例子更加容易理解。

SLSA 不能直接解决这个问题，但是对构建的过程中使用制品追溯其来源是十分必要的。

0x04开发、运维工具安全

在信息系统、软件的开发、构建过程中，除了代码本身，参与构建的依赖和制品之外，还有一类不容忽视的就是开发构建工具的安全。针对软件开发工具，运维工具的供应链攻击，国内早在2012年出现的 汉化版后门事件[11]可以称为运维工具供应链攻击的鼻祖，后来的[12]和 [13]都是运维工具供应链攻击的经典案例。

值得指出的是，虽然没有实际造成大规模影响的案例出现，理论上，类似VSC 这种支持插件开发工具，也存在被供应链攻击的可行性。国内有安全人员针对VSC进行了恶意插件钓鱼测试[14]。在测试过程中，研究人员构造了一个恶意的VSC插件，名字与 的插件 同名，最终获得了30多万的安装量。如果是一个真实的恶意插件，那么影响范围和效果可想而知。

企业中对于IDE 插件的管理，仍然需要寻找行之有效的解决方案。在有效方案落地之前，可以参考对于钓鱼攻击的管理方案，提醒用户在安装时仔细辨别发布方，星级和发布时间。

图2. 国内安全研究人员测试 VSC 恶意插件

0x05发布管理

这部分是大家比较常见的针对供应链安全进行的工作，各个厂商都会建立自己的App ，并对其上发布的App 进行安全检测。通过这部分工作极大程度地保障了用户使用的安全。

但是也不是完全万无一失，由于App 需要审核大量的软件，恶意软件绕过审核是常有的事情。

另外，需要关注盗版软件的问题，其发布和下载的渠道就更加五花八门。国内由于盗版软件产生的攻击也比较多，这部分比较敏感，就不展开讲了。

这属于开脑洞的部分，如果软件厂商能够做到在发布软件的同时，对于依赖的制品进行哈希或者签名，并且公布依赖的制品清单，也将能够大大地降低信息系统在发布过程中被篡改的情况。

0x06其他第三方管理

在信息系统供应链管理中，运维等其他第三方也是风险来源之一。常见的风险有：

1.供应商后门：典型的有2017年惠普笔记本音频驱动内置键盘记录后门事件。

2.供应商维护通道：供应商在维护过程中，可能会出现需要远程连接到公司网络环境中的通道，如，向日葵，甚至就是直接开放一个能够被公网访问的 。同时，可能会存在多个客户使用同一个密码的情况。这部分内容应该引起重视。

3.BYOD：BYOD 设备由于缺乏统一标准，在管控措施覆盖的有效性上需要特别考量。

4.默认口令或者默认口令重置方式：购买的设备本身可能存在默认口令或者默认带外口令，这些口令通常有固定的重置方式，需要在管理过程中留意设备是否能够远程重置，重置的方式是否已经被管控。

0x07可能有效的预防措施

这部分内容需要从软件生产厂商和用户两个不同的角度分开来看。

1.产品构建的完整信任链条：因为供应链攻击本质上是对软件依赖的完整性进行破坏，因此对于构建过程中的完整性保护是解决问题的关键。 中给出了一些缓解的思路，任何 Go 构建的每个依赖性的版本完全取决于主模块的 go.mod 文件，修改go.mod 必须通过 和 ，而这两个命令在设计中不允许在CI中自动运行。换句话说，按照设计思路，任何对go.mod 的修改必须是故意为之。

2.负责的代码检查机制：这部分指的是代码发布之前需要进行，确保发布出来的代码经过审核。

3.妥善保管软件签名key：妥善保管企业的软件发布签名证书，避免不必要的麻烦。

4.应急响应：

a. 及时下架被污染制品。

b. 发布补丁或者更新。

c. 确定影响的用户范围，按照相关法律法规要求进行披露。

1.建立企业内部软件市场：有条件的企业，可以通过建立内部软件市场的方式来管控开发，运维工具的分发渠道。确保内部使用的工具是被IT 部门或者信息安全部门检查并且审计过的。同时控制内部使用的工具版本数量，尽可能地将工具版本控制在少数几个主流版本，减少中招的可能性。同时也增强了应急响应的便利性，减少响应时间。

2.谨慎对待自动更新：被恶意控制的自动更新可能导致灾难性的后果。较好地方法是使用延迟更新策略，在企业内部充分评估和测试后再执行自动更新。

3.建立资产台账：覆盖完整，并且小颗粒度（甚至到制品）可以提升应急响应的效率和速度，当然也是十分高成本和困难的，需要跟进实际情况进行评估。

4.注重情报建设：在建立完善的软件完整性检查框架之前，供应链攻击可能难以发现。多数供应链攻击的发现主要依靠业界情报。建立完善的信息安全情报获取和响应体系，有助于在供应链攻击发生时第一时间获得消息和获取更多细节，进而采取高效的行动。

5.明确的业务切换和降级策略：针对供应链攻击的应急响应和常规漏洞的应急响应会有些不同，供应链攻击发生在更上游，影响的深度会更深，修复的难度会更大。有可能需要重新编译，构建部署。这时候如果业务能够有成熟明确的切换策略，是十分有帮助的，能够减少修复时候束缚，让修复时间更短。

6.应急响应：

a.确定影响范围。

b.收缩下一步的攻击面，或者隔离、阻断攻击者移动路径，减少损失。

c.溯源、找到并且切断传播路径。

d. 和原有应急响应流程、系统或者SOC（SOAR）对接，防止反复发生。

0x 08小结

信息系统供应链安全建设是一个广泛而又深入的话题。从攻击者的视角来看，这种攻击隐蔽性好，传播性强，响应和处置困难，是攻击的有效方式之一。从防守方的角度来看，对于资产管理，响应处置能力，溯源能力都提除了更高的要求，更致命的是它使得原有的边界和信任关系受到了挑战，更加考验防守方平时的信息安全建设能力和水平。但是笔者相信，随着广大安全工作者认识和研究的深入，随着供应链攻击事件响应的实践深入和对抗进行，攻守双方最终会达到平衡的状态，而逐步转入日常。

[1] 《供应链攻击安全启示 — 事件分析》 北京金融科技产业联盟

[2] 《供应链攻击已成全球企业的“心腹大患”》

[3] 《从 黑客入侵事件中看供应链安全》安全客

[4] 《 SLSA, an End-to-End for 》

[5]@/

[6]对Git 提交工作流程的更改

[7] 1.890 – What ?

[8]

[9]Post- / Root ( 2021)

[10]PyPI 官方仓库遭遇恶意包投毒

[11]内置后门事件发酵：已致上万账户信息泄露

[12]风波%E9%A3%8E%E6%B3%A2

[13]高级后门完整分析报告

[14] 钓鱼

[15]Go 如何减少供应链攻击？

—————————————————————-

问答环节：

Q1：我想问下陈总，对于产品化程度比较高的业务系统，是如何管理和追踪涉及供应链的风险，（刚才陈总分享的情报和应急响应策略是个很好的建议），这些系统在合作落地过程中可能涉及到的仅是一些接口对接层面的开发，业务系统本身功能都是在厂商方内部完成的，可能对其进行成分分析能发现不少带问题的组件，但是要厂商修改可能会需要繁琐的流程和很长的迭代周期，对这样的情况你们一般是如何处理的？是靠合作协议转移风险吗？

A：这个我觉得涉及几个问题：

1、对合作方的约束， 这个是一个商业问题， 要想解决可以做如下尝试：

2、应急响应能力方面的问题，当有情报说某个组件存在问题，这个组件在系统中使用的范围，版本这些基础信息就比较重要了。这个目前没有什么好办法，是一个苦功夫。但是讲道理，就算流程繁琐，可能也是需要修复的。

Q2：供应链攻击受影响范围的有效排查是个痛点，不知道有没有什么好办法

A：这个确实是一个痛点，个人认为还是功夫在平时供应链安全管理体系介绍，要用各种方法建立台账。但是这个方法成本很高，要因地制宜。另外就是多练习，多演练，也是有帮助的。还有就是和运维搞好关系，很重要的。

Q3：如果有多家乙方供应链开发商，如何高效且有效检查他们的供应链安全保障能力？

A：对供应商进行分类是必要的，比如 移动app 的供应商，web 系统的供应商，二进制制品的供应商。

Q4：问一个关于如何收集组件元数据和指纹（哈希码）的问题。两个场景。

第一，我们用 tree采集java依赖包的哈希码，依赖的依赖也采集，好处是容易得到依赖库的使用和关联信息，也能在发布包中找到无主的、既不是二方、也不是三方的依赖包。碰到的问题是， tree 很容易就产生链式反应，关联包滚雪球似的，从4万涨到10万，只要两天时间，数量涨的很快，有什么更好好的办法收集依赖包的元数据和指纹信息么？

第二，大厂说他们的恶意文件的指纹有40亿个，这个指纹信息有什么办法可以获取么？

A1：依赖清单的递归产生的 膨胀是一个比较复杂的问题。我不确定是否可以这样减轻这个问题，就是规定递归的深度。理论上供应链安全管理体系介绍，陈曦：信息系统供应链安全管理入门，根据图理论，可能可以在有限的递归深度中找到 有问题的软件包，那么也是能够解决问题的。

A2:这个问题会不会正向建设会好一点，关注自己构建中最常用的，或者更新最频繁的。

Q5：感觉供应链安全内容庞杂，用户又想做的落地，非常有挑战。仅靠制度和人力感觉困难重重，急需工具，SBOM 软件物料清单这个感觉概念不错，但真正实施起来感觉有很多阻力和困难点 陈总怎么看？或者仅仅是我看一些相关分享的感受。

A：如果要实际落地 SBOM，我的建议是需要联合开发和运维，多请这两个团队的同学吃饭。 因为他们承担了大量的工作量。

这个地方有一个难点就是 SBOM 它现实中不一定是平的，可能是一个树状，或者网状的结构，想要穷举，就会落入到刚说的困境。所以还是建议设置递归的深度

Q6：怎样建立一个可维护性比较好的台账呢？建立和维护一个台账感觉好难

A：这个问题还是同上，要关注这个台账的结构，结构适合自己的信息系统是非常重要的。有一个好的结构，台账就不需要经历颠覆性的更新，容易对帐和检索，对实际落地就比较有好处。

END.

安全的管理体系，皖通科技通过ISO27001信息安全管理体系认证

近日，皖通科技顺利通过信息安全管理体系换证审核，并领取了相关部门颁发的新证书。认证结果标志着皖通科技的的信息安全管理和信息技术服务管理水平得到了高度认可。

是目前国际公认的最权威、最严格且应用最广泛的信息安全管理体系认证标准。它从组织管理、物理和环境安全、信息系统获取、开发与维护、信息安全事故管理等方面进行全方位评估，要求企业构建高等级的信息安全管理体系，并在实操过程中确保用户信息安全及运营系统的高稳定性和可持续发展。

8月16日至19日，认证机构NSF-ISR派出专家审核组对皖通科技实施信息安全管理体系进行换证审核。本次审核覆盖了：2013的全部条款，专家审核组通过4天的严谨审核，认为皖通科技的信息安全管理体系完全符合标准要求，整体运行有效。最终，皖通科技顺利通过审核，并于近日领取了新证书。

随着网络信息技术的发展，信息安全问题越来越突出。“没有网络安全就没有国家安全”，近年来，《网络安全法》、《数据安全法》、《个人信息保护法》、《关键信息基础设施安全保护条例》陆续出台，企业有责任按照国家网络安全法律、战略和等级保护制度要求，做好网络安全保障。

作为国内领先的大交通产业智慧化解决方案及综合服务提供商，皖通科技一向注重信息安全工作安全的管理体系，皖通科技通过ISO27001信息安全管理体系认证，早在2015年，公司就开始依照的要求建立规范的信息安全管理体系，走在了国内同行业前列。经过6年的体系运行，皖通科技公司在信息安全管理上更加的成熟和规范，确保了公司、员工、客户和其他相关方的信息合理、安全、合法的使用。

获得认证后，皖通科技将持续保持对信息安全的长期投入、加强网络安全防御，并从战略层面的配套设计、人员、组织、技术和流程等方面不断完善安全管理体系，提升信息安全水平，筑牢安全防线，为客户提供更稳定、更安全、更可信赖产品服务。

近日，皖通科技顺利通过信息安全管理体系换证审核，并领取了相关部门颁发的新证书。认证结果标志着皖通科技的的信息安全管理和信息技术服务管理水平得到了高度认可。

是目前国际公认的最权威、最严格且应用最广泛的信息安全管理体系认证标准。它从组织管理、物理和环境安全、信息系统获取、开发与维护、信息安全事故管理等方面进行全方位评估，要求企业构建高等级的信息安全管理体系，并在实操过程中确保用户信息安全及运营系统的高稳定性和可持续发展。

8月16日至19日，认证机构NSF-ISR派出专家审核组对皖通科技实施信息安全管理体系进行换证审核。本次审核覆盖了：2013的全部条款，专家审核组通过4天的严谨审核考证书的正规网站，认为皖通科技的信息安全管理体系完全符合标准要求安全的管理体系，整体运行有效。最终，皖通科技顺利通过审核，并于近日领取了新证书。

随着网络信息技术的发展，信息安全问题越来越突出。“没有网络安全就没有国家安全”，近年来，《网络安全法》、《数据安全法》、《个人信息保护法》、《关键信息基础设施安全保护条例》陆续出台，企业有责任按照国家网络安全法律、战略和等级保护制度要求，做好网络安全保障。

作为国内领先的大交通产业智慧化解决方案及综合服务提供商，皖通科技一向注重信息安全工作，早在2015年，公司就开始依照的要求建立规范的信息安全管理体系，走在了国内同行业前列。经过6年的体系运行，皖通科技公司在信息安全管理上更加的成熟和规范，确保了公司、员工、客户和其他相关方的信息合理、安全、合法的使用。

获得认证后，皖通科技将持续保持对信息安全的长期投入、加强网络安全防御，并从战略层面的配套设计、人员、组织、技术和流程等方面不断完善安全管理体系，提升信息安全水平，筑牢安全防线，为客户提供更稳定、更安全、更可信赖产品服务。

加载全文