【分享人简介】
陈曦，某科技公司运维负责人。蓝星群非著名群友，“金融业企业安全建设实践群” 非著名群友。曾先后从事DDoS攻击防护，企业内部安全，海外SRC运营等安全领域，目前从事云原生、自动化运维、企业数字化转型、研发安全、效能提升等领域。
【分享内容梗概】
信息系统供应链安全是近几年一个很热的话题，利用供应链攻击得手的案例也层出不穷。此类攻击的特点在于对信息系统各个组件之间的完整性和信任链条提出了巨大的挑战，这部分有别于传统的攻击防护和运营响应体系。本次分享尝试分享一些学习心得，供大家讨论。
关注本公众号，实践出真知。
以下为实录：
0x01 前言
随着云原生、开源中间件、应用容器化等技术的广泛应用，软件/信息系统供应链攻击开始逐步向多元化发展，并且逐步成为勒索软件和APT的最喜爱使用的攻击方式。据2021年7月发布的《2020年中国网络安全报告》称，软件供应链攻击已成为2020年最具影响力的高级威胁之一 [2]。
目前，供应链攻击的频率和成熟度在不断提高。根据行业估计，供应链攻击现在占所有网络攻击的50％，去年同比激增了 78％。多达三分之二的公司经历了至少一次供应链攻击事件。同时，80%的IT专业人士认为软件供应链攻击将是他们的企业在未来三年面临的最大网络威胁之一。[3]
值此全国大型攻防演练之际，如何理解、应对和响应供应链攻击，提升供应链安全管理能力。无论是演练期间还是常态化运营期间，均能够对此类风险做到有效感知和控制，是摆在安全从业人员面前的一道难题。
本文作为“金融业企业安全建设实践群”（简称实践群）的一次分享，笔者尝试分享在供应链安全管理方面的学习心得，抛砖引玉，供读者参考。
成文仓促、水平有限，如果错误，欢迎随时批评指正。
0x02 供应链攻击和供应链安全管理
供应链攻击目前尚没有清晰的定义，通常可以认为指的是攻击者通过攻击或者篡改信息系统在其生产构建过程中所依赖的组件（a.k.a 构件、Aritfact）、工具、服务等，对信息系统植入恶意代码或者后门，以达到进一步攻击目标的目的。
由于供应链的传递性，攻击行为将会对供应链的下游所有节点产生影响。攻击者也将利用供应链条上的信任关系逃避检测或者扩大部署范围，从而实现非常有效的攻击效果。
供应链安全管理就是对供应链条上各个环节可能出现的风险有针对性地建设能力，从发现、处置响应等方面展开工作，建设能力，降低供应链攻击发生时对组织的影响。
供应链安全的管理维度
供应链安全的复杂度在于一旦供应链攻击实施成功，理论上攻击影响的范围是供应链条在这个节点之后的所有范围。 这些范围由于企业经营活动的其他方面交织，进而造成灾难性的后果。从正向建设的角度，不仅仅需要关注软件开发过程，同时也需要关注信息系统在开发、构建、测试、发布、运维甚至售后全生命周期的完整性和第三方可信问题。
图0. 供应链安全管理的维度
0x03 软件开发完整性检测
Google 提出了 SLSA （ Supply-chain Levels for Software Artifacts ）[4] 作为检测端到端供应链完整性的框架。其中详细定义了如何减轻整个软件供应链中的威胁和提供合理的安全保证。
SLSA框架中定义了八种风险，将其作为软件开发完整性检测的抓手。并详细阐述了这些风险项是如何作用于软件产品开发过程中的三大要素，即制品（Artifact）, 流程（Process）和平台（Platfrom）。
图1. GOOGLE SLSA
编号 | 威胁 | 案例 | SLSA 建议 |
A | 提交恶意代码 | Linux 伪君子提交[5]: 研究人员尝试通过邮件列表上面的补丁故意将漏洞引入Linux内核 | Tow-person review ：虽然不能够发现全部问题，但是能够发现大部分问题。 |
B | 有缺陷的代码托管平台 | PHP[6]：攻击者入侵了PHP的自托管git，进行了两个恶意提交。 | 加强对代码托管服务器的保护。 |
C | 使用官方（正常）的构建平台进行构建，但被构建的代码脱离控制 | Webmin[7]：攻击者篡改了 CI/CD 流程中使用的代码源文件。 | 按照SLSA的构建要求，构建过程中可以追溯代码出处或者实际来源，从而能够检测到此类篡改。 |
D | 有缺陷的CI/CD平台 | Solarwinds[8]: 构建平台被攻击者植入了恶意程序，使得每次构建产物带毒。 | 增加构建平台的安全保护 |
E | 有问题的依赖 | Event-stream: 攻击者添加了一个无关紧要的递归依赖，并从一个非官方源更新了这个依赖。 | 严格控制递归依赖，依赖的来源必须是可信源。 |
F | 上传恶意制品 | Codecov: 攻击者上传了一个恶意制品到存储桶，用户下载时下载到了恶意制品 | 发布使用的存储桶内的制品需要确定来源，确保是通过正常的构建过程构建出来的。 |
G | 有问题的镜像源 | 攻击者上传有问题的制品到镜像源 | |
H | 相近名称的安装包投毒 | Python request 安装包投毒 [10]: 攻击者在PyPI官方仓库上传了request 恶意包，该恶意包通过伪造著名python 库 requests 包名来进行钓鱼， 攻击者可对受感染的主机进行入侵，并实施窃取用户敏感信息及数字货币密钥、种植持久化后门、命令控制等一系列活动。 注：没有使用Google的原版例子，个人觉得国内的这个例子更加容易理解。 | SLSA 不能直接解决这个问题，但是对构建的过程中使用制品追溯其来源是十分必要的。 |
0x04 开发、运维工具安全
在信息系统、软件的开发、构建过程中，除了代码本身，参与构建的依赖和制品之外，还有一类不容忽视的就是开发构建工具的安全。针对软件开发工具，运维工具的供应链攻击，国内早在2012年出现的 Putty 汉化版后门事件[11]可以称为运维工具供应链攻击的鼻祖，后来的XcodeGhost [12] 和Xshell Ghost [13] 都是运维工具供应链攻击的经典案例。
值得指出的是，虽然没有实际造成大规模影响的案例出现， 理论上，类似 VSC 这种支持插件开发工具，也存在被供应链攻击的可行性。国内有安全人员针对VSC进行了恶意插件钓鱼测试[14]。在测试过程中，研究人员构造了一个恶意的VSC插件，名字与 Sublime 的插件 Emmet 同名，最终获得了30多万的安装量。如果是一个真实的恶意插件，那么影响范围和效果可想而知。
企业中对于 IDE 插件的管理，仍然需要寻找行之有效的解决方案。在有效方案落地之前，可以参考对于钓鱼攻击的管理方案，提醒用户在安装时仔细辨别发布方，星级和发布时间。
图2. 国内安全研究人员测试 VSC 恶意插件
0x05 发布管理
渠道和安全检测
这部分是大家比较常见的针对供应链安全进行的工作，各个厂商都会建立自己的App Store ，并对其上发布的App 进行安全检测。通过这部分工作极大程度地保障了用户使用的安全。
但是也不是完全万无一失，由于App Store 需要审核大量的软件，恶意软件绕过审核是常有的事情。
另外，需要关注盗版软件的问题，其发布和下载的渠道就更加五花八门。国内由于盗版软件产生的攻击也比较多，这部分比较敏感，就不展开讲了。
同时发布制品清单
这属于开脑洞的部分，如果软件厂商能够做到在发布软件的同时，对于依赖的制品进行哈希或者签名，并且公布依赖的制品清单，也将能够大大地降低信息系统在发布过程中被篡改的情况。
0x06 其他第三方管理
在信息系统供应链管理中，运维等其他第三方也是风险来源之一。常见的风险有：
1. 供应商后门：典型的有2017年惠普笔记本音频驱动内置键盘记录后门事件。
2. 供应商维护通道： 供应商在维护过程中，可能会出现需要远程连接到公司网络环境中的通道，如 Teamview，向日葵，甚至就是直接开放一个能够被公网访问的 Shell。同时，可能会存在多个客户使用同一个密码的情况。这部分内容应该引起重视。
3. BYOD：BYOD 设备由于缺乏统一标准，在管控措施覆盖的有效性上需要特别考量。
4. 默认口令或者默认口令重置方式：购买的设备本身可能存在默认口令或者默认带外口令，这些口令通常有固定的重置方式，需要在管理过程中留意设备是否能够远程重置，重置的方式是否已经被管控。
0x07 可能有效的预防措施
这部分内容需要从软件生产厂商和用户两个不同的角度分开来看。
对于软件厂商
1. 产品构建的完整信任链条：因为供应链攻击本质上是对软件依赖的完整性进行破坏，因此对于构建过程中的完整性保护是解决问题的关键。Golang 中给出了一些缓解的思路，任何 Go 构建的每个依赖性的版本完全取决于主模块的 go.mod 文件，修改go.mod 必须通过goget 和 gomodtidy，而这两个命令在设计中不允许在CI中自动运行。换句话说，按照设计思路，任何对go.mod 的修改必须是故意为之。
2. 负责的代码检查机制：这部分指的是代码发布之前需要进行review，确保发布出来的代码经过审核。
3. 妥善保管软件签名key： 妥善保管企业的软件发布签名证书，避免不必要的麻烦。
4. 应急响应：
a. 及时下架被污染制品。
b. 发布补丁或者更新。
c. 确定影响的用户范围，按照相关法律法规要求进行披露。
对于用户
1. 建立企业内部软件市场：有条件的企业，可以通过建立内部软件市场的方式来管控开发，运维工具的分发渠道。确保内部使用的工具是被 IT 部门或者信息安全部门检查并且审计过的。同时控制内部使用的工具版本数量，尽可能地将工具版本控制在少数几个主流版本，减少中招的可能性。同时也增强了应急响应的便利性，减少响应时间。
2. 谨慎对待自动更新：被恶意控制的自动更新可能导致灾难性的后果。较好地方法是使用延迟更新策略，在企业内部充分评估和测试后再执行自动更新。
3. 建立资产台账：覆盖完整，并且小颗粒度（甚至到制品）可以提升应急响应的效率和速度，当然也是十分高成本和困难的，需要跟进实际情况进行评估。
4. 注重情报建设：在建立完善的软件完整性检查框架之前，供应链攻击可能难以发现。多数供应链攻击的发现主要依靠业界情报。建立完善的信息安全情报获取和响应体系，有助于在供应链攻击发生时第一时间获得消息和获取更多细节，进而采取高效的行动。
5. 明确的业务切换和降级策略：针对供应链攻击的应急响应和常规漏洞的应急响应会有些不同，供应链攻击发生在更上游，影响的深度会更深，修复的难度会更大。有可能需要重新编译，构建部署。这时候如果业务能够有成熟明确的切换策略，是十分有帮助的，能够减少修复时候束缚，让修复时间更短。
6. 应急响应：
a. 确定影响范围。
b. 收缩下一步的攻击面，或者隔离、阻断攻击者移动路径，减少损失。
c. 溯源、找到并且切断传播路径。
d. 和原有应急响应流程、系统或者SOC（SOAR）对接，防止反复发生。
0x 08 小结
信息系统供应链安全建设是一个广泛而又深入的话题。从攻击者的视角来看，这种攻击隐蔽性好，传播性强，响应和处置困难，是攻击的有效方式之一。从防守方的角度来看，对于资产管理，响应处置能力，溯源能力都提除了更高的要求，更致命的是它使得原有的边界和信任关系受到了挑战，更加考验防守方平时的信息安全建设能力和水平。但是笔者相信，随着广大安全工作者认识和研究的深入，随着供应链攻击事件响应的实践深入和对抗进行，攻守双方最终会达到平衡的状态，而逐步转入日常。
Refenrence
[1] 《供应链攻击安全启示 --- SolarWinds事件分析》 北京金融科技产业联盟 https://www.bfia.org.cn/upload/file/20210722/1626941538197081197.pdf
[2] 《供应链攻击已成全球企业的“心腹大患”》Freebuf https://m.freebuf.com/articles/neopoints/293359.html
[3] 《从solar winds黑客入侵事件中看供应链安全》安全客 https://www.anquanke.com/post/id/239404
[4] 《Introducing SLSA, an End-to-End Framework for Supply Chain Integrity》 https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html
[5] https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/
[6] 对 Git 提交工作流程的更改 https://news-web.php.net/php.internals/113838
[7] Webmin 1.890 Exploit - What Happened? https://www.webmin.com/exploit.html
[8] https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/
[9] Post-Mortem / Root Cause Analysis (April 2021) https://about.codecov.io/apr-2021-post-mortem
[10] PyPI 官方仓库遭遇request恶意包投毒 https://security.tencent.com/index.php/blog/msg/160
[11] PuTTY内置后门事件发酵：已致上万账户信息泄露 http://tech.sina.com.cn/i/2012-01-31/19186670190.shtml
[12] XcodeGhost风波 https://zh.wikipedia.org/wiki/XcodeGhost%E9%A3%8E%E6%B3%A2
[13] Xshell高级后门完整分析报告 https://security.tencent.com/index.php/blog/msg/120
[14] VSCODE EXTENSION 钓鱼 https://zhuanlan.zhihu.com/p/33203374
[15] Go 如何减少供应链攻击？https://www.infoq.cn/article/AyeYK1FRDfSfw6MhjwqV https://go.dev/blog/supply-chain
问答环节：
Q1：我想问下陈总，对于产品化程度比较高的业务系统，是如何管理和追踪涉及供应链的风险，（刚才陈总分享的情报和应急响应策略是个很好的建议），这些系统在合作落地过程中可能涉及到的仅是一些接口对接层面的开发，业务系统本身功能都是在厂商方内部完成的，可能对其进行成分分析能发现不少带问题的组件，但是要厂商修改可能会需要繁琐的流程和很长的迭代周期，对这样的情况你们一般是如何处理的？是靠合作协议转移风险吗？
A：这个我觉得涉及几个问题：
1、对合作方的约束， 这个是一个商业问题， 要想解决可以做如下尝试：
提供明确的安全标准，这个标准可以从影响出发，定义什么样的影响的安全问题，（其实不仅仅是供应链攻击里面涉及的组件安全问题，甚至是逻辑漏洞都可能适用）承担什么样的责任，或者需要什么样的承诺。通过这个承诺来约束修复动作发生和保证修复效果。
如果团队安全能力足够的话，可以在标准里面明确接口和二开的实现方式要求和安全功能要求，要求合作方达到，也能取到效果。
2、应急响应能力方面的问题，当有情报说某个组件存在问题，这个组件在系统中使用的范围，版本这些基础信息就比较重要了。这个目前没有什么好办法，是一个苦功夫。但是讲道理，就算流程繁琐，可能也是需要修复的。
Q2：供应链攻击受影响范围的有效排查是个痛点，不知道有没有什么好办法
A：这个确实是一个痛点，个人认为还是功夫在平时，要用各种方法建立台账。但是这个方法成本很高，要因地制宜。另外就是多练习，多演练，也是有帮助的。还有就是和运维搞好关系，很重要的。
Q3：如果有多家乙方供应链开发商，如何高效且有效检查他们的供应链安全保障能力？
A：对供应商进行分类是必要的，比如 移动app 的供应商，web 系统的供应商，二进制制品的供应商。
每种类型的供应商管理方式和排查方式，以及风险是不同的， 可以针对性地做一些措施。
但是有些通用的动作，比如协议约束，尝试要求公开和自动化获取制品清单，这些可以通用。
如果是纯软件供应商，对于他们管理的成熟度，今天介绍的Google的SLSA 是有成熟的level的，可以参考一下。
Q4：问一个关于如何收集组件元数据和指纹（哈希码）的问题。两个场景。
第一，我们用maven dependency tree采集java依赖包的哈希码，依赖的依赖也采集，好处是容易得到依赖库的使用和关联信息，也能在发布包中找到无主的、既不是二方、也不是三方的依赖包。碰到的问题是， maven dependency tree 很容易就产生链式反应，关联包滚雪球似的，从4万涨到10万，只要两天时间，数量涨的很快，有什么更好好的办法收集maven依赖包的元数据和指纹信息么？
第二，大厂说他们的恶意文件的指纹有40亿个，这个指纹信息有什么办法可以获取么？
A1：依赖清单的递归产生的 膨胀是一个比较复杂的问题。我不确定是否可以这样减轻这个问题，就是规定递归的深度。理论上，根据图理论，可能可以在有限的递归深度中找到 有问题的软件包，那么也是能够解决问题的。
A2:这个问题会不会正向建设会好一点，关注自己构建中最常用的，或者更新最频繁的。
Q5：感觉供应链安全内容庞杂，用户又想做的落地，非常有挑战。仅靠制度和人力感觉困难重重，急需工具，SBOM 软件物料清单这个感觉概念不错，但真正实施起来感觉有很多阻力和困难点 陈总怎么看？或者仅仅是我看一些相关分享的感受。
A：如果要实际落地 SBOM，我的建议是需要联合开发和运维，多请这两个团队的同学吃饭。 因为他们承担了大量的工作量。
这个地方有一个难点就是 SBOM 它现实中不一定是平的，可能是一个树状，或者网状的结构，想要穷举，就会落入到刚说的困境。所以还是建议设置递归的深度
Q6：怎样建立一个可维护性比较好的台账呢？建立和维护一个台账感觉好难
A：这个问题还是同上，要关注这个台账的结构，结构适合自己的信息系统是非常重要的。有一个好的结构，台账就不需要经历颠覆性的更新，容易对帐和检索，对实际落地就比较有好处。
声明：本文来自君哥的体历，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
