Gartner认为软件供应链攻击是2022年的主要的威胁来源，有人将2022年称为软件供应链安全元年，是新上任CIO的首要工作，越来越多开发者、安全研究人员在关注软件供应链安全。
我们通过梳理漏洞和开源组件数量变化、相关的漏洞风险事件、法规和标准、产品能力关注点，来对软件供应链安全这一领域进行回顾。
可以看到：
新出现的漏洞和开源组件的数量都在增长
中国有6个针对特定行业的信息安全管理法规中涉及软件供应链，软件供应链安全的标准与指南在加速，美国、新加坡、欧盟、英国也相继发布了软件供应链安全建设计划、指南
我们观察发现在软件供应链安全产品能力上，除了基础功能以外，企业开发者和安全团队更关注：
漏洞治理优先级
漏洞可达性分析
降低修复成本
二进制成分分析
研发流水线集成
我们认为，未来会有更多软件供应链的安全风险暴露到公众视野，针对全链条的治理标准和监管能力会走向成熟，产品能力发展趋势包括：
检测精度不断加深
适用范围越来越广
重视研发体验
集成能力增强
相关的数据及信息基于我们的观察和分析，可能不尽全面，也欢迎读者补充。
漏洞及开源组件增长
在2022年，CVE新公开的漏洞数量为33034个，达到新高。而CNVD公开的漏洞数为10651个，则有所下降。（CNVD的漏洞默认是在收录一年后公开，所以并不能完全反映当前漏洞趋势）
美国网络安全和基础设施安全局(CISA)从2021年11月开始维护一个已知被利用漏洞目录（Known Exploited Vulnerabilities Catalog），在2022年，该目录中的漏洞数量新增了557个，总数达到868个。
以java、python、node.js生态为例，从对应的maven中央仓库、pypi仓库、npm仓库中可以看到开源组件数量持续增长。
安全漏洞与投毒事件
漏洞是软件供应链安全中关注的首要风险，投毒是近年来越来越频繁出现的攻击方式，因此我们以月为维度梳理了有较大影响的漏洞及投毒事件。
1月-PwnKit漏洞、faker.js/color.js投毒
Qualys公司安全研究人员在Linux内核polkit组件pkexec中发现了存在12 年之久的PwnKit漏洞 (CVE-2021-4034)。通过利用该漏洞，可以在所有主流Linux发行版中实现本地提权。
faker.js 和colors.js的作者 Marak Squires 由于不满用户免费使用其开源组件，在这两个包中加入了恶意代码，执行后会输出三行「LIBERTY LIBERTY LIBERTY」，而后开始无限输出非 ASCII 字符。
3月-Node-ipc投毒、Spring4Shell漏洞
Node-ipc是NPM中每周下载量超百万的开源组件，3月7日，开发者因为不满俄乌战争，在代码中加入了针对俄罗斯与白俄罗斯IP用户删除、覆盖磁盘文件的恶意代码，通过peacenotwar组件在用户桌面放置反战标语。
3月31日，Spring发布安全公告，修复了影响spring-webmvc 和 spring-webflux的远程代码执行漏洞(CVE-2022-22965)，与Log4Shell(CVE-2021-44228)对应，有安全研究人员将其称为Spring4Shell。
4月-Gitlab测试密码硬编码漏洞
4月1日，Gitlab发布安全公告，在新版本中修复了硬编码密码导致的接管用户账户的安全问题(CVE-2022-1162)。当受影响版本的Gitlab开启OmniAuth后，攻击者可以通过三方登陆功能，利用硬编码的123qweQWE!@#000000000测试密码登录任意账号。
5月-Fastjson反序列化漏洞、Follina漏洞
5月23日，java开源组件fastjson开发者发布安全公告，发布了安全修复版本1.2.83，该版本修复了其收到在特定场景下可以绕过autoType关闭限制的漏洞(CVE-2022-25845)，建议fastjson用户尽快采取安全措施保障系统安全。
5月27日，nao_sec公布了在微软Office中通过诊断工具(MSDT)利用的远程代码执行漏洞，代号Follina(CVE-2022-30190)。
6月-Atlassian Confluence OGNL注入漏洞
6月3日，Atlassian公司发布安全公告，在Confluence Server 和 Data Center新版本中修复了远程执行任意代码的严重漏洞(CVE-2022-26134)。由于URL中的OGNL表达式存在注入问题，攻击者无需认证就可发送请求通过表达式执行恶意代码。
7月-Apache Commons Configuration 任意代码执行漏洞
7月6日，Apache基金会发布公告称在Commons Configuration组件中由于存在与Log4j相同的插值功能(interpolation)，攻击者可以利用形如${prefix:name}的字符串执行任意代码，建议开发者升级至新版本。
8月-Atlassian Bitbucket Server 和 Data Center 命令注入漏洞、GitHub中超过3.5万开源代码文件被投毒
8月3日，名为 Stephen Lacy 的工程师在Twitter中表示其发现大量GitHub仓库被加入了恶意代码，感染文件超过3.5万，随后GitHub对这些仓库进行了删除。攻击者大量克隆了已有开源项目的信息，加入恶意逻辑后再次提交代码。所幸由于被投毒的开源仓库大多无人关注，此次事件本身的实际影响较小。
8 月 24 日Atlassian官方安全公告发布了CVE-2022-36804漏洞，由于Bitbucket Server 和 Data Center 的多个 API 端点处存在命令注入漏洞，有权访问公共 Bitbucket 存储库或对私有存储库具有读取权限的攻击者可以通过发送恶意 HTTP 请求来执行任意代码。
9月-Linux kernel 释放后重用漏洞(DirtyCred)
9月20日，有安全研究人员公开了存在超过8年的Linux内核权限提升漏洞(CVE-2022-2588)利用代码，与DirtyPipe相对应，该漏洞被称作DirtyCred。漏洞源于Linux 内核net/sched/cls_route.c 实现的 route4_change 中存在释放后重用问题，当用户或网卡空间具有 CAP_NET_ADMIN 的特权能力时，攻击者可以将普通用户权限提升为root。
10月-Apache Commons Text 远程命令执行漏洞（Text4Shell）
10月13日，Apache Commons Text团队发布公告称在1.10.0以前的版本中存在远程代码执行漏洞（CVE-2022-42889），该漏洞也是由于支持了与Log4j相同的插值功能(interpolation)导致，因此有安全研究人员称其为Text4Shell漏洞。
此前Apache Commons Configuration的任意代码执行漏洞(CVE-2022-33980)也是由于对Commons Text进行了二次封装。
11月-OpenSSL 远程代码执行漏洞
11月1日，OpenSSL官方正式通告了一个可能远程执行任意代码的高危漏洞（CVE-2022-3602）。由于在 X.509 证书验证过程中（尤其在名称约束检查中）存在缓冲区溢出风险，可能导致拒绝服务或远程代码执行。
在此前10月25日OpenSSL预发布的通告中，该漏洞评级为严重，被认为是OpenSSL历史上第二严重的漏洞（仅次于Heartbleed），但此后考虑利用成本较高，漏洞评级降为高危。
12月-Linux内核ksmbd模块任意代码执行漏洞、PyTorch-nightly遭遇投毒
12月23日，ZDI公布了一处Linux内核ksmbd模块中存在的CVSS评分为10分（满分）的漏洞（CVE-2022-47939）。ksmbd模块自Linux 5.15版本开始引入，由于Linux内核在处理SMB2_TREE_DISCONNECT 命令时存在释放后重用漏洞，攻击者无需通过身份验证即可利用此漏洞远程执行任意代码。
12月31日，PyTorch团队发现 PyPI 仓库中出现了名为torchtriton的恶意包，由于与PyTorch-nightly中的私有包同名，在获取依赖项时，PyPI 的优先级较高，会导致恶意包在用户不知情下拉取到本地。恶意的torchtriton包不仅获取用户基本指纹信息（例如 IP 地址、用户名和当前工作目录），还会进一步窃取敏感数据（包括/etc/hosts 、/etc/passwd、$HOME/*中的前1000 个文件、$HOME/.gitconfig、$HOME/.ssh/*文件内容）。PyTorch团队通过将torchtriton依赖重新命名为pytorch-triton并发布至PyPI 仓库来修复这个问题。
法规与标准
中国
行业法规：6个针对特定行业的信息安全管理法规中涉及软件供应链
1月5日，银保监会发布《银行保险机构信息科技外包风险监管办法》
3月7日，工业和信息化部发布《车联网网络安全和数据安全标准体系建设指南》
3月29日，工业和信息化部等五部门发布《关于进一步加强新能源汽车企业安全体系建设的指导意见》
4月29日，证监会发布《证券期货业网络安全管理办法（征求意见稿）》
8月30日，国家卫生健康委等三部门发布《医疗卫生机构网络安全管理办法》
11月16日，国家能源局发布《电力行业网络安全管理办法》
标准与指南：软件供应链安全国家标准进入征求意见阶段、关键基础设施强调供应链安全保护
6月7日，中国信息通信研究院发布《软件物料清单实践指南》
9月28日，全国信息安全标准化技术委员会发布国家标准《信息安全技术 软件供应链安全要求（征求意见稿）》
11月7日，市场监管总局标准技术司、中央网信办网络安全协调局、公安部网络安全保卫局联合发布《信息安全技术 关键信息基础设施安全保护要求》（GB/T 39204-2022）
海外
美国、新加坡、欧盟、英国相继发布软件供应链安全建设计划、指南
3月1日，美国国家安全局（NSA）发布《网络基础设施安全指南》(Network Infrastructure Security Guidance)
5月1日，美国网络安全和基础设施安全局(CISA)和美国国家标准技术研究院(NIST)发布网络供应链风险管理框架指南(Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations)
5月27日，美国能源部发布《2022制造业网络安全路线图》(Cybersecurity Manufacturing Roadmap 2022)
7月27日，新加坡网络安全局(CSA)发布了关键信息基础设施 (CII) 供应链计划书(Critical Information Infrastructure Supply Chain Programme Paper)
9月1日，美国网络安全和基础设施安全局（CISA）、国家安全局 (NSA) 和国家情报总监办公室 (ODNI) 发布《面向开发者的软件供应链安全实践指南》(Securing the Software Supply Chain: Recommended Practices Guide for Developers)
9 月 14 日，美国总统办公厅颁布《通过安全软件开发实践增强软件供应链的安全性》备忘录（Enhancing the Security of the Software Supply Chain through Secure Software Development Practices）
9 月 15 日，欧盟颁布《网络弹性法案》(Cyber Resilience Act)
10月12日，英国国家网络安全中心(NCSC)发布供应链安全指南(How to assess and gain confidence in your supply chain cyber security)
10月31日，美国网络安全和基础设施安全局（CISA）、国家安全局 (NSA) 和国家情报总监办公室 (ODNI) 发布《面向供应商的软件供应链安全实践指南》(Securing the Software Supply Chain: Recommended Practices Guide for Suppliers)
11月17日，美国网络安全和基础设施安全局（CISA）、国家安全局 (NSA) 和国家情报总监办公室 (ODNI) 发布《面向客户的软件供应链安全实践指南》(Securing the Software Supply Chain: Recommended Practices Guide for Customers)
产品能力关注点
随着越来越多的开发者及安全工程师应用软件供应链安全治理工具，对于产品而言，也在基础能力之上有了更高要求。
漏洞治理优先级
企业安全团队经常面临着资源有限，而面对大量漏洞需要修复无从下手的场景，这时候就必须按照一定的优先级进行处置。
漏洞危害通常采用CVSS进行评分，但是CVSS评分存在着部分漏洞评分过高的问题（如前端组件和后端组件的任意代码执行漏洞评分可能一样，但其大多数情况下危害并不一样）、维度不足（如没有考虑被利用的情况，存在利用工具的漏洞对于企业而言风险更高）的问题。
因此仅仅根据CVSS评分不能客观反映漏洞处置的优先级，业界也提出了EPSS(Exploit Prediction Scoring System)的概念用于反映漏洞的利用情况，部分厂商会针对漏洞做出自己的评级。
除了评价的客观性容易受到挑战以外，优先级大多数情况下还和企业的安全管理状况相关，并没有一个万金油的标准。
漏洞可达性分析
仅依赖组件名称以及版本区间来判断是否受到漏洞影响不够准确，因为漏洞通常依赖于特定的代码写法、数据传递场景才能触发。
例如java中jackson-databind的反序列化漏洞，在应用中需要在开启DefaultTyping特性的情况下，调用readValue方法处理用户输入的json数据才能够被利用。安全工程师进行漏洞治理工作时，可能会被研发工程师挑战称其代码中没有调用问题方法，检测结果属于误报，并不存在漏洞。
因此除了版本判断外，如果能进一步分析代码中是否包含这样能导致漏洞触发的代码调用，则能让漏洞识别结果更有说服力，帮助企业安全团队进一步评估影响面，这被称为可达性分析。
降低修复成本
开发者在修复漏洞时，经常可能存在疑问，升级组件版本、新增某个配置，是否会存在不兼容，导致新代码无法正常完成业务功能。这样的问题常常成为漏洞修复路上的绊脚石，导致修复周期拉长。
对于间接依赖的组件存在漏洞，开发者如果要顺着依赖关系找到对应的直接依赖安全版本，是一个费时费力的事情；对于企业而言，当有大量开发者需要修复漏洞时，如果能够缩短修复漏洞所用的时间，很大程度上也是在提高研发效能、提高企业的生产力。
产品应该尽可能降低开发者修复漏洞的成本，降低开发者心智负担，提升安全治理效率。
二进制成分分析
软件产物有源代码、制品、二进制等多种形态，传统的软件供应链安全产品只能针对源代码做检测，而在当前我们面临着许多不同的应用场景，在不同的场景中就需要对不同的产物进行检测。
比如在开发过程中，通常只需要针对项目中的源码检测；在上线前java代码被打包成了jar包这样的制品，这时候需要对制品进行检测；而软件通过二进制形式交付是常见的做法，如果想要对交付的产品进行分析，则需要面对大量开发阶段信息丢失的问题。
尽管二进制成分分析面临许多困难，但由于闭源形式的商业软件是企业中难以忽视的供应链存在，过去它们往往是黑盒式的软件资产、安全治理的盲区，现在也希望它们也能变得更透明，因此二进制的分析能力在被越来越重视。
研发流水线集成
由于很大一部分的软件供应链安全问题是在研发过程中引入，因此针对研发流水线的工具集成被开发者关注。
与企业现有的研发流水线集成，能够降低开发者的使用成本，也便于建立卡位控制的安全门禁。常见的集成方式包括IDE插件、独立客户端、提供webhook服务等，常见需要适配的研发工具包括：IDE、代码仓库、CI/CD、制品库。
展望
Gartner预计到2025年，全球45%的组织都会遭受过软件供应链攻击，这一数量是2021年的3倍。
在接下来的2023年，我们预计会有更多软件供应链相关的漏洞、攻击事件出现，相关的法规、标准仍在持续完善的阶段。
对于这一领域的安全产品，将呈现以下趋势：
检测精度不断加深：风险识别越来越接近真实可利用场景；
适用范围越来越广：覆盖更多的软件产物形态、覆盖软件供应链全生命周期、覆盖不同的使用人群；
重视研发体验：研发工程师作为安全工具的终端用户，其是否愿意使用变得非常关键；
集成能力增强：包括研发流水线的集成、安全工具之间的集成，通过集成形成有效的协同能力。
参考链接
https://www.infoworld.com/article/3646231/2022-the-year-of-software-supply-chain-security.html
https://www.cio.com/article/410904/the-new-cio-security-priority-your-software-supply-chain.html
658
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
