随着近年来开源软件的蓬勃发展, 现代化软件的开发和供应模式极大地促进了开源软件自身的快速迭代和演进, 也提高了社会效益. 新兴的开源协作的软件开发模式, 使得软件开发供应流程由较为单一的线条转变为复杂的网络形态. 在盘根错节的开源软件供应关系中, 总体安全风险趋势显著上升, 日益受到学术界和产业界的重视. 针对开源软件供应链,厘清了其关键环节, 基于近10年的攻击事件, 归纳了开源软件供应链的威胁模型和安全趋势, 并通过对现有安全研究成果的调研分析, 从风险识别和加固防御这两个方面总结了开源软件供应链安全的研究现状, 最后对开源软件供应链安全所面临的挑战和未来研究方向进行了展望和总结.
In recent years, the vigorous development of open source software and the modern software development and supply models have greatly facilitated the rapid iteration and evolution of open source software, resulting in increased social benefits. The emerging collaborative software development model of open source has transformed the software development supply process from a relatively linear path to a complex network structure. Within open-source software's complex and intertwined supply relationships, the overall security risk trend has significantly increased, drawing increasing attention from the academic and industrial communities. This work tries to define the new open-source software supply chain model and, based on attacks that have occurred over the past decade, summarizes the threat model and security trends of the open-source software supply chain. For securing the open-source software supply chain, this work provides a systematic overview from the perspectives of risk identification and reinforced defense and also highlight the new challenges and opportunities.
随着近年来开源软件(opensource software)的蓬勃发展, 开源软件已经成为现代化信息产业不可或缺的一部分, 也给软件的构成和开发过程带来了巨大的变化. 近年来, 软件开发模式从一个组织、一个厂商单独开发一个产品, 到了依赖部分共享的组件进行开发, 形成一条线性的软件供应链. 现今, 现代化软件开发过程中, 开发人员及企业为了提高开发的效率, 会优先考虑安装相关第三方开源组件的依赖, 并在此基础上进行修改、拓展及改进. 这种开发模式可以避免重复设计开发, 降低研发成本, 提高生产力和生产效率, 推动软件系统快速迭代, 形成了开源协作的软件开发新模式. 在开源协作模式下, 软件的功能和体系也越来越复杂, 呈现为更加复杂的网络型供应链形式. 在此背景下, 本文采用开源软件供应链的概念, 围绕现代化软件开发新模式下的安全问题进行深入的研究和分析.
开源软件供应链和我国国民生活、城市建设、工业生产等息息相关, 影响着智能家居、汽车、智能电网等众多关键基础设施的开发和管理, 其安全问题也影响着我国现代化建设和发展. 然而, 随着开源软件供应链体系越来越庞大, 威胁的渗入点不断增多, 分布在开源软件供应链的各个环节. 同时, 开源软件供应体系呈现全球化的态势, 增加了开源软件供应监管的难度. 根据Verocode的研究报告[
为了构建安全可靠的开源软件供应链, 保障软件供应安全和高质量创新, 一大批来自学术界和工业界的学者探索了开源软件供应链的攻击事件和存在的安全风险, 并且前瞻性地提出了一系列针对开源软件供应链的风险识别和加固防御方法, 涵盖了软件开发、分发、使用等环节. 然而, 由于不同学者所处的研究领域不同, 解决问题的角度不同, 因而构建的威胁模型也不同, 研究的攻击或防御方法也各有侧重, 缺乏系统的整理、归纳、总结、分析. 虽然有学者在2019−2020年对软件供应链的研究工作[
本文首先介绍开源软件供应链的模型, 接着对开源软件供应链面临的风险和攻击事件进行总结和归纳, 然后从风险识别和加固防御两个角度对开源软件供应链的安全防御研究进行系统的分析、归纳和总结, 并讨论相关研究的局限性. 最后, 本文将探讨开源软件供应链安全研究所面临的挑战以及未来可行的研究方向.
在研究和定义开源软件安全供应链安全前, 首先需明确开源软件供应链的定义. 学术界和工业界对软件供应链提出了很多定义, He等人[
复杂的组件和应用软件依赖关系图
本文定义开源软件供应链是指开源软件在开发和运行过程中, 涉及的所有开源软件的上游社区、源码包、二进制包、第三方组件分发市场、应用软件分发市场, 以及开发者和维护者、社区、基金会等, 按照依赖、组合等形成的供应关系网络. 如
开源软件供应链主要环节模型
(1) 组件开发环节中, 多个开发人员协作开发代码, 利用源码管理工具(source code management, SCM)管理源代码, 通过编译、生成、测试, 完成组件的开发, 并上传到第三方组件开发市场. 此外, 开发人员出于高效协作开发代码的考虑, 会从第三方组件分发市场下载第三方组件并安装依赖来完成开发. 其中, 流行的源码管理工具包括GitHub[
(2) 应用软件开发环节中, 多个开发人员会从第三方组件分发市场安装组件依赖, 和组件开发一样, 利用源码管理工具管理源代码, 通过编译、生成、测试, 完成对应用软件的开发. 其中, 应用软件指的是可以直接发布给终端用户使用的完整产品, 如手机应用、物联网设备和网页应用等.
(3) 应用软件分发环节中, 应用软件在软件分发市场上被发布. 常见的应用软件分发市场主要是应用商店和软件开发者维护的含有下载连接的软件网站.
(4) 应用软件使用环节中, 终端用户将从应用软件分发市场下载软件并使用. 终端用户在使用过程中也可进一步根据软件的迭代对软件进行更新.
开源软件供应链模型的定义, 为开源软件供应链的安全研究带来了全新的视角. 本节首先总结了开源软件供应链威胁模型, 根据该模型, 分析供应链各个环节的安全事件, 并总结当前开源软件供应链风险的总体趋势.
已有学者对软件供应链的威胁模型进行了分析, 给出了多种类型的威胁渗入点或攻击向量. Zhou等人[
综上研究, 当前学者们已经列举分析了多种多样的软件供应链威胁渗入点, 但缺少系统性的概括, 或缺少某个供应链环节的威胁分析, 或没有考虑到当前开源协作新模式下引入的威胁, 同时也缺少对开源软件供应链攻击面的总结, 缺少对攻击向量和攻击影响的深层讨论. 因此, 本文综合考虑了上述研究和本文建立的开源软件供应链模型, 对威胁模型进行了系统的分析和总结. 如
开源软件供应链的威胁模型
环节 | 攻击面 | 违反的安全属性 |
组件和 |
1. 攻击者通过分发市场的缺陷, 制作伪装、虚假的第三方组件, 或篡改已有的第三方组件, 欺骗开发人员下载使用 |
1. 组件的完整性 |
应用软件 |
攻击者通过分发市场的缺陷制作并上传伪装、虚假的应用软件或篡改已有的应用软件欺骗终端用户下载使用 | 应用软件的完整性 |
应用软件使用环节 | 1. 攻击者对软件下载更新过程进行劫持 |
1. 下载更新过程的完整性, 软件的完整性 |
下面, 本文通过对开源软件供应链的攻击事件的分析, 进一步介绍
组件和应用软件开发环节中, 多个开发人员共同协作, 把代码上传到源码管理器. 接着, 项目代码被编译、构建和测试, 然后, 组件会被发布到第三方组件分发市场. 应用软件及组件开发集成过程中会从第三方组件分发市场安装组件依赖, 提高开发效率. 考虑到组件开发和应用软件开发共同面临着恶意代码提交、恶意的第三方组件依赖等风险问题, 本文对两个环节进行了总结, 统一分析两个开发环节面临的安全风险.
首先, 针对开发环境, 攻击者可以通过污染开发人员使用的开发、编译、构建、测试时使用的开发集成环境, 导致开发完成的组件和应用软件具有缺陷或后门, 或窃取开发人员的隐私数据. 该攻击面主要利用了污染、操控、攻陷开发集成工具和环境等攻击向量. 在组件和软件开发过程中, 如果被攻击者在源代码级别植入恶意代码, 由于源码审查的难度较高, 导致这一问题将很难被发现. 且这些恶意代码在披上正规软件厂商的合法外衣后, 更能轻易躲过安全软件产品的检测, 可以长时间潜伏于用户机器中不被察觉. 典型的开发集成环境污染事件如2019年Unix管理工具Webmin的构建服务器中, 被攻击者发现存在可以隐秘方式修改密码、提升权限的漏洞, 该漏洞允许已知此后门知识的攻击者在缺少输入验证的情况下而执行恶意代码[
此外, 由于开源协作的新模式, 源码管理可能存在新的缺陷, 如攻击者可以向源码管理工具提交具有缺陷或后门的源代码, 在软件开发中注入漏洞, 或窃取隐私. 其中, 隐私信息包括开发管理过程中的敏感资源与流程相关的信息, 例如设置的密钥、生产日志、漏洞追踪、参数配置和临时文件等. 该攻击面主要采用的攻击向量是绕过源码管理工具的验证管控、窃取开发人员的信任凭证等. 针对漏洞注入, 利用源码管理器验证管控的缺陷, 攻击者曾攻击源码管理器Git, 通过伪造Git创建者的签名, 向源代码中注入可执行任意代码的后门[
最后, 针对开发依赖, 开源软件供应链面临着恶意第三方组件依赖和代码复用的安全问题. 攻击者通过第三方组件分发市场的缺陷, 制作伪装、虚假的第三方组件, 或篡改已有的第三方组件, 欺骗开发人员下载使用. 具体来说, 攻击者可以通过如窃取分发市场的信任凭证, 借助分发市场管理上的错误绕过验证等攻击向量来上传伪装、虚假的第三方组件. 典型的攻击事件通过引入恶意第三方库带来的安全风险, 攻击者通过向PyPI包管理器上传常用包名称相似的恶意包[
应用软件分发环节主要面临分发管理的风险. 针对分发管理的风险, 攻击者通过分发市场的缺陷制作并上传伪装、虚假的应用软件或篡改已有的应用软件欺骗终端用户下载使用. 该攻击面的主要攻击向量包括绕过分发市场的验证管控、包名误用攻击、恶意接管分发市场的管理权限等. 一个典型的例子是WireX Android BotNet污染Google Play应用市场事件[
应用软件使用环节主要面临两大安全风险, 包括下载更新机制和运行环境的风险.
首先, 针对下载更新机制, 用户下载更新软件过程中存在下载更新通道被劫持的风险. 这主要是当前网络通道和下载更新过程无法保证完全安全, 仍存在DNS劫持、中间人攻击、钓鱼攻击等攻击向量, 导致用户错误地连接到攻击者的恶意分发站点上, 欺骗终端用户下载更新. 典型的攻击事件如2017年6月27日晚被发现的NotPetya勒索病毒[
其次, 针对运行环境, 应用软件可能存在来自软件供应链上游的漏洞缺陷. 攻击者可以利用软件的缺陷、后门进行攻击, 如利用窃取软件和运行环境中的敏感数据, 对运行环境中的其他数据进行篡改, 拒绝服务攻击以及提权攻击等攻击向量. Xiao等人[
本文汇总并分析了开源软件供应链从2010年以来的攻击事件, 绘制了如
开源软件供应链近10年的攻击事件趋势分析
为了详细探究各类供应链攻击的形成方式, 本文绘制了近10年来开源软件供应链4个环节攻击事件的成分图, 如
各个环节出现的攻击事件占比
基于上述分析, 可见, 针对新型开源协作模式下的软件供应链的安全研究仍需进一步加强, 积极主动应对新型开源协作模式下复杂开源供应链带来的风险, 尤其是加强对开源软件供应链上游环节的风险检测和加强对开源软件供应链的加固和防御.
基于上述安全风险, 安全人员针对开源软件供应链各个环节的攻击面设计了风险识别技术.
(1) 针对组件和软件开发环节中, 现有工作主要研究了供应链视角下组件及软件的漏洞检测、面向第三方组件分发市场的风险识别, 其中, 第三方组件分发市场的风险识别包括第三方组件分发市场中的恶意软件识别以及第三方组件分发市场的风险检测; 此外, 在组件和软件开发环节, 考虑到协作开源的场景, 研究人员分别从开源项目的安全性以及开源代码贡献人员的隐私性这两个方面研究协作开发的风险.
(2) 针对软件分发环节, 当前的研究集中在对软件分发市场如安卓软件商店等中软件的风险识别.
(3) 针对软件使用环节, 当前的研究重点分别是软件下载更新时网络劫持的风险识别及软件风险识别.
综上, 本文将各个环节的风险识别和评估总结为以下4个关键研究方向: 开源软件供应链中第三方组件的风险识别、开源软件供应链视角下的应用软件风险识别、协作开发的风险识别及下载更新过程的风险识别.
其中, 第三方组件的风险识别包括了分发市场中的第三方组件风险识别及其风险识别和第三方组件分发市场的安全评估; 开源软件风险识别可以被应用在开发环节中开发人员的测试, 或应用在分发环节中分发市场或研究人员对软件的审核, 在使用环节, 用户也可对软件进行风险识别后再进行使用. 因此, 本文总结了开源软件供应链视角下各个环节的应用软件风险识别技术, 并放在第3.1节讨论, 包含应用软件中的第三方组件检测及其风险识别、应用软件代码复用检测以及分发市场中的恶意应用软件识别.
接下来, 本文对上述4个关键研究方向的风险识别技术进行分析和总结.
近些年来, 研究人员开始关注开源软件供应链中第三方组件的安全性. 在软件供应链中, 开发人员从第三方组件分发市场下载安装第三方组件依赖. 这一过程中, 研究人员着力开展了对分发市场第三方组件的风险识别, 同时, 也对第三方组件分发市场进行分析和安全评估.
传统的第三方组件研究主要集中在如PyPI、NPM、RubyGem、OPKG等主流第三方组件分发市场. 上述例子中, 针对特定开发语言的第三方组件分发市场也被称作包管理器. 此外, 面向新兴的物联网语音设备, 也涌现出了第三方语音技能分发市场、自动化应用程序的组件分发市场等, 如亚马逊的语音技能市场、IFTTT平台. 已有部分工作研究了上述第三方组件分发市场及软件系统的第三方组件风险识别问题.
(1) 面向包管理器的第三方组件风险识别
考虑到新型复杂网络开发流程下, 包管理器中的包一旦出现安全问题, 如存在缺陷导致攻击者可以注入并执行恶意代码等, 将影响到下游海量应用程序的安全. 因此, 已有多个研究[
面向包管理器的风险识别, 研究人员主要研究了恶意包注入的检测技术和其他支持在包管理器中批量扫描和检测潜在具有漏洞风险的第三方包的相关研究. 其中, 包名抢注是是近年来研究人员发现的一种恶意包注入的攻击手段, 攻击者以流行包相似名字注册的恶意包, 使开发者误以为恶意包是他要下载的目标包, 大大提升了恶意包的下载概率, 并进一步传播到开发的软件中. 如先前研究识别发现PyPI市场上12个包名误用的恶意包. 如
4个针对“Django”包的恶意抢注包
当前的检测方案主要通过包名抢注的两大特性来检测: (1) 攻击目标往往是流行包; (2) 恶意包和原始包的名字十分相似. Taylor等人[
针对包管理器中的存在漏洞风险的第三方包检测, 研究人员主要致力于发现包管理器中存在的新的风险以及提出有效和系统性的方案来对包管理器中的包进行系统性的检测. 针对一些新发现的包风险检测, 研究人员主要采用基于源代码的分析方法, 分为静态检测和动态检测这两种方案. 如James等人[
相比于针对包管理器特定风险的检测研究, Duan等人提出了一个更为有效和普适的方案, 即MALOSS[
● 元数据分析: 通过提取代码包的元数据, 如包的名称、开发作者、维护者、发布版本、下载次数和依赖关系等, 来识别出潜在的恶意数据包.
● 静态分析: 通过对代码包的源代码进行分析, 标记网络、文件系统、进程、代码生成相关的API, 进一步将源代码解析为语法结构树并搜寻标记API的使用情况, 最后分析代码数据流, 检查代码数据流的源、sink节点和传播节点.
● 动态分析: 通过在隔离的docker环境中安装执行二进制代码包, 触发导入包时的初始化逻辑来测试import包, 用动态模糊测试触发相应功能来测试导出函数, 最后用sysdig来捕获代码运行时的系统调用trace.
除了包管理器这一第三方组件分发市场以外, 恶意包注入和第三方包风险检测的研究也同样在新兴的物联网分发市场, 即第三方语音技能分发市场以及自动化应用程序组件分发市场, 有一定进展. 其中, 语音技能是用于物联网场景下智能语音设备上应用的开发, 如亚马逊Alexa[
语音技能的工作流程[
(2) 面向第三方语音技能分发市场的第三方组件风险识别
由于物联网的迅速发展, 智能语音设备在社会家庭生活中越来越流行. 为了更方便地集成和开发相关语音应用程序, 各大物联网厂商如亚马逊、谷歌和小米等提供了语音技能开放平台, 允许开发人员上传自己开发的语音技能或者配置部署来自其他用户的语音技能, 形成了第三方语音技能分发市场. 针对新兴的第三方语音技能分发市场, 恶意包的注入主要体现为语音抢注攻击、语音伪装攻击这两种新型攻击, 可能导致恶意指令执行、隐私窃取等风险. 其中, 语音抢注攻击指的是攻击者设计类似发音或者语义的语音名称来劫持用于合法技能的语音命令, 如
4个针对“Capital One”语音技能的恶意抢注包
Zhang等人[
(3) 面向自动化应用程序组件分发市场的第三方组件风险识别
针对流行的自动化应用程序组件分发市场, 研究人员研究如何大规模且高效地识别市场中存在潜在漏洞风险的第三方包, 主要检测是否存在恶意程序组件收集用户的隐私以及程序组件是否存在自身的缺陷易被攻击者利用, 并进一步评估当前分发市场中第三方组件的安全情况. 自动化应用程序分发市场上发布了一系列提供特定应用功能的组件, 由下游开发者或用户对不同功能的组件进行组合配置, 实现自动化的应用程序. 如通过配置温度传感器数值读取组件和控制窗户开关命令的组件, 可以实现一个应用程序, 自动化执行命令: “当温度上升到35℃时打开窗户”. 针对这一类型流行的自动化应用程序组件的分发市场, 分发市场和研究人员需要检测市场上是否存在恶意组件, 还需要考虑到下游用户安装组件组合的风险, 设计研究方案对分发市场上不同组件的组合进行扫描并分析安全性, 可以帮助用户在安装组件依赖时提供安全风险的评估参考.
针对分发市场上的恶意程序组件, Bastys等人[
考虑到下游用户对自动化应用程序组件组合配置的安全风险, 研究人员主要考虑一些程序组件的交互逻辑. 除了软件程序自身的交互逻辑外, Ding等人[
一个存在风险的利用物理通道交互的例子[
综合上述分析, 安全研究人员及分发市场对不同类型的组件分发市场的风险都设计了相应的风险识别方案. 其中, 针对包名抢注、语音抢注类型的攻击, 研究人员主要利用该攻击的特性, 即包名相似这一点特点, 结合其他特征设计检测方案, 包括设置黑名单、计算流行度等; 针对第三方组件, 研究人员也在探索现有的第三方组件存在新的安全风险, 并设计相应的风险检测方案支持大规模识别分发市场中第三方组件的风险. 针对上述研究, 大部分学者采用了元数据、静态分析等技术手段, 检测效率高, 但也存在高误报率、低检测率的问题; 也有一些研究采用了动态技术如模糊测试等来提高检测的效率, 但检测开销时间较大. 考虑到第三方组件分发市场的多样性, 仍缺少自动化可扩展的工具, 也缺少更加智能高效的检测方法.
此外, 在物联网的快速发展背景下, 新的第三方组件如语音技能、自动化应用程序组件呈现出新的威胁渗入点, 如语音伪装攻击等; 此外, 开发人员在开发软件系统、语音智能设备和自动应用程序等需依赖大量组件, 组件组合也存在如依赖冲突等风险. 从供应链上游的组件分发市场上大规模分析组件组合配置的风险, 为开发人员提供安全风险提示和评估, 是有效渠道之一. 而针对该方向等相关研究仍较少, 仅有少数研究探索了自动应用程序的组合风险, 针对其他的风险, 如第三方包组合配置风险识别技术需要更深入的探索. 经典的分发市场中恶意第三方组件识别方法相关总结见
经典的分发市场中恶意第三方组件识别方法总结
方法名称 | 检测的开发语言 | 分发市场 | 分析方法 | 分析场景 | 性能 | 可扩展 | 支持识别的缺陷 | |||
静态 | 动态 | 黑盒 | 白盒 | 检测能力 | 检测速率 | |||||
注: ●=高, ◑=中, ○=低; √=满足, ×=不满足; 检测能力是对检测准确率和误报率的综合评价; 可扩展是方法针对不同开发语言及分发市场的扩展能力的综合评价, 可传递是指方法能识别依赖的组件, 并进一步识别依赖的组件和别的组件依赖关系 | ||||||||||
TypoGuard[ |
JavaScipt, Python, Ruby | NPM, PyPI, RubyGems | √ | × | × | √ | ○ | ● | ◑ | 包名误用 |
PyPi-parker[ |
Python | PyPI | √ | × | × | √ | ○ | ● | ○ | 包名误用 |
Vu等人[ |
Python | PyPI | √ | × | × | √ | ◑ | ◑ | ◑ | 包名误用、代码缺陷 |
James等人[ |
JavaScript | NPM | √ | × | × | √ | ○ | ● | ○ | 代码缺陷 |
Synode[ |
JavaScript | NPM | √ | √ | × | √ | ◑ | ● | ○ | 代码缺陷 |
Staicu等人[ |
JavaScript | NPM | √ | √ | × | √ | ◑ | ◑ | ○ | 代码缺陷 |
MALOSS[ |
JavaScipt, Python, Ruby | NPM, PyPI, RubyGems | √ | √ | × | √ | ● | ◑ | ◑ | 隐私泄露、代码缺陷、包名误用、网络劫持等 |
Skill-name Scanner[ |
− | Alexa skill market | √ | √ | × | √ | ● | ● | ◑ | 语音抢注、语音伪装 |
SkillExplorer[ |
− | Alexa skill market | √ | √ | √ | × | ◑ | ◑ | ● | 隐私泄露 |
LipFuzzer[ |
− | Alexa skill market, Google Assistant vApp | × | √ | √ | × | ◑ | ● | ● | 语音抢注、语音伪装 |
Bastys等人[ |
Groovy | IFTTT | √ | × | × | √ | ○ | ● | ◑ | 隐私泄露 |
IoTMon[ |
Groovy | SmartThings | √ | × | × | √ | ◑ | ◑ | ◑ | 组件组合风险 |
iRuler[ |
Groovy | IFTTT | √ | × | × | √ | ◑ | ◑ | ◑ | 组件组合风险 |
IoTCom[ |
Groovy | SmartThings, IFTTT | √ | × | × | √ | ◑ | ● | ◑ | 代码缺陷 |
面向第三方组件分发市场的分析和安全评估, Kula等人[
认识到第三方组件分发市场中组件漏洞的危害性后, 已有研究人员对漏洞影响力和修复情况进行了研究. Decan等人[
对第三方包管理平台的评估方案[
特征 | 包管理器 | |||||
PyPI | Npm | RubyGems | ||||
注: ●=强制的, ◑=可选的, ○=不支持 | ||||||
功能性检查 | 软件包维护者 | 发布包的权限 | 密码验证功能 | ● | ● | ● |
访问令牌验证功能 | ◑ | ● | ● | |||
公钥验证功能 | ○ | ○ | ○ | |||
多因子验证功能 | ◑ | ◑ | ◑ | |||
发布 | 上传功能 | ● | ● | ● | ||
引用功能 | ○ | ○ | ○ | |||
签名功能 | ◑ | ◑ | ◑ | |||
拼写保护功能 | ○ | ● | ● | |||
命名规则推荐的功能 | ○ | ◑ | ○ | |||
管理 | 删除数据包 | ◑ | ◑ | ◑ | ||
弃用数据包 | ○ | ◑ | ◑ | |||
添加协作者 | ◑ | ◑ | ◑ | |||
转移拥有权 | ◑ | ◑ | ◑ | |||
开发者 | 选择包 |
提供信誉评分 | ● | ● | ● | |
提供代码质量评估 | ○ | ○ | ○ | |||
提供安全实践分析 | ○ | ○ | ○ | |||
提供已知风险分析 | ○ | ○ | ○ | |||
提供包名误用检测功能 | ○ | ○ | ● | |||
安装包 | Hook安装 | ● | ◑ | ○ | ||
安装时指定特定依赖项 | ○ | ◑ | ◑ | |||
源代码安装 | ◑ | ◑ | ◑ | |||
嵌入式的二进制安装 | ◑ | ◑ | ◑ | |||
审核检查 | 软件包维护者、开发人员 | 元数据检查 | 依赖检查 | ○ | ○ | ○ |
更新检查 | ○ | ○ | ○ | |||
二进制检查 | ○ | ○ | ○ | |||
软件包维护者账号 | ○ | ○ | ○ | |||
静态分析 | 语法错误识别 | ○ | ○ | ○ | ||
逻辑错误识别 | ○ | ○ | ○ | |||
恶意逻辑代码 | ○ | ○ | ○ | |||
动态分析 | 安装过程检测 | ○ | ○ | ○ | ||
嵌入式二进制检测 | ○ | ○ | ○ | |||
Import检测 | ○ | ○ | ○ | |||
功能性的检测 | ○ | ○ | ○ | |||
补救响应功能 | 软件包维护者、开发人员、终端用户 | 删除 | 删除包 | ● | ● | ● |
删除发布者 | ● | ● | ● | |||
删除已安装的包 | ○ | ○ | ○ | |||
通知 | 通知软件包维护者 | ○ | ○ | ○ | ||
通知相关软件包维护者 | ○ | ○ | ○ | |||
通知开发人员 | ○ | ○ | ○ | |||
通知漏洞建议修复数据库 | ○ | ● | ● |
根据Duan等人[
此外, 面向新兴的物联网语音设备, Cheng等人[
综上所述, 研究人员已经在第三方组件分发市场的分析和安全评估上开展了一系列的研究, 通过对第三方组件市场数据的分析, 能够增强对软件生态系统的理解. 更重要的是, 研究人员揭示了当前第三方组件分发市场中的组件仍存在很多安全隐患而市场的审查机制不够完善, 且和当前学术研究存在一定差距, 第3.1.1节研究提到的前沿的第三方组件风险识别方案仍未应用到当前主流的开发市场的审查机制中.
传统的应用软件风险识别利用静态分析和动态测试[
针对特定的开发软件系统, 其使用的第三方组件以及内在的依赖关系检测能够帮助开发者、维护者和使用者实现对软件系统的总体架构理解, 进一步实现对软件系统的可靠性风险管理. Tellnes等人[
元数据静态检测主要是利用软件系统中提供的第三方组件相关字段等信息进行检测. Maven组织实现了OWASP Dependency Check工具[
上述工具仅仅通过一些简单的字符匹配技术来进行检测, 由于元数据无法真实反映软件的依赖关系且一但代码采用了一些混淆技术, 上述工具就无法识别相应的特征, 存在大量漏报. 因此, 研究人员提出了基于源代码的静态检测方案, 主要利用哈希、控制流图和函数名等信息的匹配. Backes等人[
上述方法都是已知第三方库的特征对未知的软件系统进行匹配识别, 另一种方案是直接对软件系统进行第三方库的提取, 无须提前获取到第三方库的知识. 针对第2种方案, Li等人[
相比于上述先检测第三方组件再分析第三方组件是否存在漏洞, Ohm等人提出了Buildwatch[
基于上述调研, 关键的应用软件中第三方组件风险识别方法总结见
经典的应用软件中第三方组件识别及漏洞挖掘方法总结
方法名称 | 检测的开发语言 | 分析方法 | 分析场景 | 性能 | 可扩展 | 抗混淆 | 可传递 | 支持识别的缺陷 | |||
静态 | 动态 | 黑盒 | 白盒 | 检测能力 | 检测速率 | ||||||
注: ●=高, ◑=中, ○=低, \=不具有该特性; √=满足, ×=不满足; 检测能力是对检测准确率和误报率的综合评价; 可扩展是方法针对不同开发语言扩展能力的综合评价, 可传递是指方法能识别依赖的组件, 并进一步识别依赖的组件和别的组件的依赖关系 | |||||||||||
OWASP Dependency Check[ |
Java, NET, Python, Ruby, PHP, NodeJS | √ | × | × | √ | ○ | ● | ◑ | ○ | ○ | 1day漏洞 |
VAS[ |
Java | √ | × | × | √ | ○ | ● | ◑ | ○ | ○ | 1day漏洞 |
LIBSCOUT[ |
Java | √ | × | × | √ | ◑ | ◑ | ◑ | ◑ | ◑ | 1day漏洞 |
Atvhunter[ |
Java | √ | × | × | √ | ● | ◑ | ◑ | ◑ | ○ | 1day漏洞 |
CENTRIS[ |
C/C++ | √ | × | × | √ | ● | ◑ | ◑ | ◑ | ● | 1day漏洞、许可证违规 |
LibD[ |
Java | √ | × | × | √ | ◑ | ◑ | ◑ | ● | ◑ | \ |
Eclipse Steady[ |
Java, Python | √ | √ | × | √ | ● | ◑ | ◑ | ◑ | ○ | 1day漏洞 |
OSSPolice[ |
Java | √ | × | √ | × | ◑ | ● | ◑ | ● | ○ | 许可证违规、1day漏洞 |
Buildwatch[ |
JavaScript | × | √ | √ | × | ◑ | ○ | ◑ | ● | \ | 恶意的第三方组件 |
可见, 针对软件系统中的第三方组件的风险识别研究中, 当前的研究方案能够支持白盒和黑盒场景的分析, 但是在抗混淆和可传递性上仍有较大研究空间. 尤其考虑到当前软件依赖关系层层嵌套, 十分复杂, 亟需研究具有高效可传递性的第三方组件依赖检测方案. 此外, 当前的研究方案都针对特定已知的攻击设计, 在发现新漏洞的能力上仍有所欠缺. 最后, 新的开发和应用场景随着现代化的进展也在不断涌现, 当前研究对物联网分发市场的研究仍处于初级探索阶段, 对新的开发和应用场景的第三方组件风险检测研究仍有待研究, 如多架构的物联网设备固件、人工智能平台和模型中也依赖大量第三方组件, 且存在安全风险.
除了第三方组件带来的1day漏洞及许可证违规风险以外, 研究人员也探索了开源软件供应链中代码复用带来的1day漏洞及许可证违规风险. 现有研究重点探索了软件代码的新型表示, 进一步结合人工智能技术等完成代码克隆检测及风险的识别.
针对源代码, Fischer等人[
针对二进制代码, 研究人员主要结合了代码相似性分析的方法. 当前的方法主要依赖于近似图匹配算法, 效率和准确率都比较低. Xu等人[
基于神经网络的第三方组件检测方案Gemini的工作流图[
综上所述, 开源软件供应链视角下的应用软件代码克隆检测主要目的是为了检测软件中的1day漏洞及许可证违规的风险. 当前的研究在人工智能技术的辅助下, 在源代码和二进制代码的测试上, 准确率都有一定提高, 但在混淆后的代码上的检测能力仍显不足. 且上述研究仅仅对代码表示进行了优化的设计, 而上述代码表示方法在下游的漏洞检测及许可证违规检测的能力仍有待研究.
考虑到开源软件供应链的分发环节中攻击者会对安全软件进行恶意篡改或者添加恶意载荷, 研究人员探索了如何利用软件智能风险检测技术来识别这些恶意的软件.
基于元数据的方案是最简单的方案, 检测速度快, 但准确率低. Hemel等人[
基于相似度函数的相似恶意检测主要是利用哈希作为相似度函数进行比较, 依然保持较快的检测速度, 但比基于元数据的方案在准确率上提高了很多. Zhou等人[
应用程序重打包检测系统DroidMOSS框架[
基于人工智能的代码相似性比较是当前比较有效且热门的研究方案, 但对训练要求高, 训练花费时间长. Crussell等人[
应用程序相似性检测Andarwin框架[
开源软件项目往往需要多个开发人员、维护人员共同持续开发维护, 这涉及开源软件项目的源码管理工具, 也带来了新的风险渗入点, 攻击者利用了持续集成(CI)/持续交付(CD)管道和开发工具中的弱点注入隐蔽的安全漏洞、窃取开源软件的隐私信息. 为了解决上述安全风险, 研究人员开展了代码仓库接受开发维护提交请求的评估、识别协作开发过程中代码提交的风险和隐私数据泄露的研究等.
针对代码提交请求中的代码风险, Wan等人[
恶意代码提交的检测框架Anomalicious[
相比于上述研究考虑的是代码仓库恶意代码提交的风险, 研究人员也探索了代码提交请求中隐私泄露的风险, 即作者在提交代码时无意泄露自己的隐私的风险, 并研究了相应的检测方案. Sinha等人[
(1) 基于关键词的搜索. 当前, 项目密钥一般会有独特的声明字段, 例如“––BEGIN RSA PRIVATE KEY––”通常出现在SSH密钥的头部. 基于这一发现, 可以通过收集相应密钥使用的关键词字段并进行批量搜索, 用于检测密钥的泄露. 该方法检测速度较快, 但存在较高的误报率和漏洞率, 只能搜索到关键词, 无法确定密钥是否已经进行脱敏处理, 且无法搜索到没有相应独特声明字段的密钥泄露.
(2) 基于模式匹配的搜索. 一些密钥除了有独特声明字段外, 自身的格式也十分独特. 基于这一发现, 他们将Java源文件生成抽象语法树(AST), 并对字符串文字节点执行模式搜索. 与基于关键词搜索方案相比, 该方案能够减少14个与Client ID模式匹配的代码中的30个实例, 以及准确识别到与密钥模式匹配的17个项目中的43个实例. 虽然基于模式匹配的搜索在搜索效率上略有下降, 但大大降低了误报率和漏报率. 但是, 该方案需要手动定义规则, 且无法支持没有特定格式的密钥的识别, 仍存在大量漏报.
(3) 基于启发的密钥泄露检测过滤. 在上述两种方案的基础上, 他们探索了一些额外的启发式规则来帮助过滤一些误报. 例如, 考虑到客户ID和密钥通常成对出现, 添加额外的检查搜索客户端ID和密钥是否出现在5行之内. 虽然这种方法通常是精确的, 但很可能会遗漏客户端ID和密钥关系不紧密的密钥泄露实例, 且很大程度依赖客户端ID和密钥识别的准确度. 在匹配API密钥模式的字符串中, 减少误报的另一种方法是尝试猜测它们是自动生成的还是手写的. 他们注意到, 许多误报实际上是人类可读的字符串, 例如“SomeLabelTextInMyAppWhichIsAPerfectMatch”, 或占位符, 例如“00000000...”. 为了解决这个问题, 他们应用了一个标准的密码强度估计器, 过滤掉具有重复字符或包含字典单词的字符串, 降低了误报.
(4) 基于源程序切片的检测. 准确地查找流入客户端API调用的那些字符串的重量级方法是使用程序切片, 但传统的程序切片有很大的时间消耗. 他们设计了一种轻量级的流敏感程序切片算法, 切片标准是密钥相关函数的调用, 进一步对返回的密钥进行密码强度分析. 该方法实现了100%的准确度和84%的召回率.
然而, Sinha等人提出的方案仅仅关注AWS的密钥泄露检测, 具有较大的局限性. Meli等人[
综合上述研究分析可见, 关于协作开发的风险识别的研究较少. 考虑到开源生态环境的来自不同开发人员的代码提交数量多、项目提交动态更新等特点, 当前仍然没有较好的方案能够实现大规模、自动化且可扩展的风险识别方案, 也无法支持动态增量式的轻量级的风险识别.
面对用户在下载和更新软件时可能存在网络劫持、钓鱼网站等风险, 研究人员主要研究了更新下载渠道的风险识别. Garrett等人[
在开源软件供应链中, 软件下载更新渠道的风险识别方案研究较少, 是因为研究人员希望从本质上提升加固软件下载更新渠道的安全性.
除了对上述风险的被动检测研究外, 研究人员探索了多种针对开源软件供应链的主动加固和防御方案. 针对开源软件供应链的各个环节, 研究人员分别针对各个环节研究了相应的主动加固方案, 同时, 也有一部分研究旨在对开源软件供应链多个环节或整个模型设计防御方案. 下面将围绕以上两点展开总结和分析.
当前, 面向开源软件供应链单个环节的加固防御研究主要集中在以下4个方面: 组件及应用软件开发环节中可信开发方案的设计、组件及应用软件开发环节中代码的安全加固、应用软件分发环节中可靠的分发方案和应用软件使用环节中安全的使用方案.
针对可信开发, 本文围绕协作开发过程和开发依赖介绍了工业界及学术界的可信开发研究.
针对源代码构建, 考虑到协作开发过程中可能有恶意攻击者冒充开发人员提交恶意代码, 业界实践及学术研究最普遍实用的加固防护机制是代码跟踪校验. 下面以最流行的开发协作平台GitHub[
针对开发依赖, 考虑到分发市场可能存在恶意或有缺陷的第三方组件, 工业界往往采用建立自己的开源第三方组件管理库, 如领英公司拥有良好的外部第三方组件管理模式[
上述研究主要利用了密码学数字签名、可信证书技术, 通过对开发过程中协作人员行为的验证、开发过程中关键信息的完整性及对第三方组件的评估管理来实现可信开发, 其中, 对协作人员行为及关键信息完整性验证主要利用数字签名及证书, 较为高效, 已被广泛应用. 然而, 上述研究方案主要基于密钥来保障签名和证书的安全性, 一旦签名的密钥被泄露或攻击者基于源代码集成环境的缺陷绕过验证, 上述方法将不再有效.
针对组件及应用软件开发环节中的代码加固研究, 研究人员主要从减少攻击风险及构建代码补丁这两个方面展开了研究. 在减少攻击风险的研究中, 研究人员主要关注的是开发过程中是否引入不必要或存在问题的第三方组件, 同时也关注开发和部署的完整性. 为了实现开发过程中的安全, Koishybayev等人[
此外, 软件的补丁研究是开发过程中的重要加固技术. 在开源软件供应链视角下, 漏洞会从上游传播到下游, 下游组件及应用软件的补丁难以第一时间得到响应, 相关研究面临着新的风险和挑战. 一方面, 下游厂商也无法确定含有大量组件依赖和代码复用的组件及应用软件中是否修复了哪些漏洞, 继承的组件依赖及复用的代码中是否已经修复了相关代码; 另一方面, 当一个漏洞披露时, 下游厂商难以确定当前依赖的组件或复用的代码是否受到影响, 且受到影响的组件及复用的代码是否已经进行了修复. 因此, 针对上述问题, 在研究软件的补丁过程中, 需加强对开源软件供应链漏洞影响的评估、对软件是否存在补丁的评估和自动打补丁的研究. 针对漏洞评估, 安全开发人员和维护人员在发现新漏洞时需要对其进行评估, 以便对其进行优先级排序, 进行打补丁. 基于CVSS度量标准[
补丁存在性检测PDiff框架[
人[
为了减少人工的参与度及减轻对大量下游组件软件打补丁的压力, 软件自身加固的研究主要集中在自动打补丁的研究上. Chen等人[
Duan等人[
上述研究展示了开源软件供应链视角下安全加固的两个重要研究方向.
● 一方面, 从代码层面添加了加固的设计来减少风险, 增强应用软件自身的防御能力. 但当前开发过程中, 自动化分析并处理依赖项的工具仍较匮乏, 相关代码加固研究在更广泛的C/C++语言开发的组件及软件上以及支持更复杂功能的第三方组件上仍处于初步阶段, 需要更深入的探索.
● 另一方面, 针对开源软件供应链的补丁研究仍有许多亟待解决的难题, 如更准确的漏洞影响范围的评估、更高效的补丁存在性检测、自动化持续性的打补丁研究等.
当前, 应用软件的可靠分发主要目标是保障应用软件的完整性和可追溯性. 观察分发环节的业界实践, 我们发现, 分发市场和应用商店通常设计并实现软件审核和检测机制, 以对抗伪装、虚假的应用软件. 如, 苹果的应用商店提供了严格的审查流程以规范应用程序的发布[
研究人员也开展了一些关于抵御重打包攻击的研究, 主要包括自签名策略和代码混淆. 其中, 自签名策略指的是在发布软件的过程中, 软件包的哈希值和开发者签名也需要被发布, 让用户下载软件时可以对软件进行完整性的验证. 如Android Studio在发布他们的终端软件的页面上[
上述研究展示了保障应用软件可靠分发的两个重要加固手段: 一方面, 需加强应用软件分发时的安全审核, 需基于第3.2节提出的软件风险识别技术来提高审核能力; 另一方面, 需加强应用软件抵御重打包攻击的能力. 代码混淆对抗仍是当前软件工程及网络空间安全研究的重要议题, 如何结合智能技术如混淆逻辑门、深度学习等来加强代码混淆能力以及对代码混淆的评估, 仍是重要研究方向之一.
针对使用环节, 研究人员主要研究安全运行、安全下载更新这两个方面. 针对安全运行, 研究人员提出了多种可信运行环境, 使得应用软件运行时免遭攻击者的威胁. 当用户运行时, Gregor等人[
针对安全更新, Ozga等人[
基于上述研究可见, 结合一些新兴的技术如可信计算等进行拓展应用来保障安全运行和下载更新、针对新场景下使用环节的加固防御研究, 是当前主要的两个研究方向.
研究人员面向开源软件供应链提出了多种面向多环节的设计方案. 当前的研究方案主要考虑到组件及应用软件开发环节和应用软件分发环节之间的供应关系, 设计对组件及应用软件开发和分发过程进行全面管理和监控的方案, 以使得开发人员或终端用户可以从分发市场上下载可信安全的组件或应用程序.
针对该目标, Singi等人[
除此之外, 有研究积极探索了开源软件供应链的框架设计. 研究方案in-toto[
添加了in-toto元素的软件供应链的图形描述[
该方案主要基于密钥来保障签名的安全性, 一旦签名的密钥被泄露或攻击者基于源代码集成环境的缺陷绕过验证, 该方法将不再有效. 针对这一缺陷, 研究人员探索了增强的可信开发过程的管理方案, 一大研究方向是, 基于多级密钥管理来降低密钥泄露的风险; 另一个研究方向是, 基于区块链的方式来实现可信开发管理方案.
基于多级密钥管理的研究方案主要是由一个根密钥管理者生成并保存一个密钥, 基于该密钥, 向下级开发人员或维护人员派生分发相应的密钥, 将对代码修改维护等操作的权限委托给可信的协作开发人员. 基于该思路, Samul等人[
上述基于多级密钥管理的研究方案主要贡献在于降低了密钥泄露的风险, 而新兴的基于区块链的研究方案则进一步加强了开发过程的透明性, 同样积极探索了动态的密钥派生和撤销以及开发过程中引入风险识别知识来加强开发代码的安全性等研究. Nikitin等人提出了SkipChain[
基于上述研究, 可见, 当前针对开源软件供应链多环节的管理方案主要有以下两个方向: 从设计上加强开源软件供应链结构上的改进, 以实现组件及应用软件的可信开发及可信分发目标; 结合智能技术, 针对开源软件供应链的知识管理、风险监控进行进一步探索.
目前, 多个国家已经制定了针对开源软件供应链的法律政策. 2015年, 美国国家标准技术研究院(NIST)专门制定了SP800-161《联邦信息系统和组织供应链风险管理/方法实践清单》[
2021年4月, 美国网络安全与基础设施安全局(CISA)和NIST联合发布Defending Against Software Supply Chain Attacks提供软件供应链风险的概况描述, 并为厂商和用户提供使用C-SCRM和SSDF两个框架来识别、评估和缓解此类风险的建议[
针对开源软件供应链层出不穷的安全问题, 相关社会组织也提出了相应的措施来减少开源软件供应链的潜在风险. OpenChain是由Linux基金会联合知名企业共同建立的项目, 旨在提供开源软件供应链规范. 目前, OpenChain 2.1, 即由Linux基金会、Joint Development基金会和OpenChain项目共同制定的ISO/IEC 5230:2020标准已经被核准成为国际标准. 该标准能够进一步解决开源软件供应链中的信任问题, 在提升开源合规方面做出了重要的贡献. 众多国际知名企业都加入了由OpenChain领导的开源软件供应链社区, 例如丰田、谷歌以及思科等企业[
除了来自国家层面以及社会组织层面的开源软件供应链规范以外, 部分企业也出台了各自相应的管制措施.早在2011年, 微软率先发布了《网络供应链风险管理: 实现透明和信任的全球共享》报告[
根据上述对开源软件供应链安全问题背景的介绍, 结合对开源软件供应链安全研究现状的调研, 本文总结了现阶段开源软件供应链安全研究所面临的四大挑战和四大未来研究方向及研究内涵, 见
开源软件供应链的现实挑战和未来研究方向
现实挑战 | 未来研究方向 | 研究方向内涵 |
协作模式下软件依赖复用关系 |
高效智能的组件及应用 |
1. 自动化可扩展的第三方组件风险识别技术 |
开源趋势下软件供应链 |
新场景及新模式下的 |
1. 新的场景下开源软件供应链的风险识别技术 |
加固防御能力不足, |
开源软件供应链的 |
1. 自动化高效的代码加固技术 |
安全可控不足增大了开源软件 |
结合新兴技术的开源 |
1. 可靠的开源软件供应链安全设计 |
基于上述研究及
(1) 协作模式下软件依赖关系高度复杂化, 漏洞检测能力受限.
软件的复杂度正随着对软件功能需求的不断提高而不断上升, 由于信息技术产业的不断发展以及其他产业对软件依赖的加深, 软件的复杂性也不断增加. 软件复杂性主要体现在多个开发人员协同的代码的开发中, 该过程会使用大量第三方组件或进行代码复用. 同时, 漏洞也随着软件复杂的依赖关系进行扩散, 对整个开源软件供应链体系的风险检测能力的要求也大大提高. 具体来说, 在海量及复杂类型的第三方组件不断涌现的背景下, 针对它们的风险识别技术仍存在自动化程度低、可扩展性差等难题; 在软件组成高度复杂化, 混淆对抗技术流行的背景下, 检测软件中依赖的第三方组件及复用的代码仍存在检测精度低, 依赖组件识别浅层等难题.
(2) 开源趋势下, 软件供应链体系不断扩大, 新模式下的风险识别技术匮乏.
开源给软件供应链引入了新的环节和步骤, 也增加了软件供应链的攻击面. 开源软件均需要经过复杂的开源软件供应链的供应关系, 涉及多个开发人员、项目管理者、源码管理工具和分发市场, 依赖大量第三方组件和开发人员的代码贡献. 利用这一庞大体系, 攻击者有更多机会来发起攻击, 包括植入恶意代码、劫持供应渠道. 而复杂的供应关系也使得攻击者的攻击更加难以检测, 难以定位威胁渗入点. 具体来说, 新的开源协作模式中, 现有的研究方案仍较少支持对持续性的开发过程或针对性地检测增量改变的代码进行漏洞识别的相关研究, 检测效率较低, 难以识别持续性开发过程中引入的隐蔽漏洞; 此外, 复杂供应关系及对大量第三方组件和开发人员代码贡献的依赖也引入了新的风险, 如知识产权等法律问题以及第三方组件组合的风险等, 当前研究方案针对上述新风险的研究仍较匮乏, 对软件中许可证的自动化提取和语义理解、基于许可证要求对组件及应用软件代码的一致性检测和对海量的第三方组件组合实现高效的风险识别仍是解决上述新风险的重要挑战; 最后, 新的物联网和人工智能场景给开源软件供应链的风险识别带来了新的挑战, 现有的研究方案对如语音智能设备中引入新的第三方组件语音技能, 深度学习模型中对第三方神经网络模块的复用等新的场景和研究对象的认识仍属于初步阶段, 识别能力有限.
(3) 加固防御能力不足, 难以应对海量复杂的开源软件供应链渗入点.
面向开源软件供应链的攻击事件越来越多, 在发现攻击后, 有必要对软件进行及时的修补和加固. 而当前, 海量、依赖关系复杂的开源软件给软件的安全加固带来了更大的难度: 首先, 针对海量软件, 难以及时监控和确定软件是否存在漏洞及相应的补丁并及时对软件进行修补; 针对软件的多个不同漏洞, 无法在短时间内全部修复, 需要衡量软件漏洞的严重程度, 评估打补丁的优先级别; 针对海量的软件漏洞, 手动对不同软件的不同漏洞进行修补, 需要大量专家知识并花费大量人力, 增加了开源软件供应链防御的负担; 最后, 现有的应用软件代码保护能力弱, 仍面临着恶意代码注入、重打包、知识产权侵犯等重要风险, 如何对应用软件的代码进行加固, 在保留原有功能及性能的基础上避免攻击者恶意篡改或盗用, 仍是亟需解决的重要问题.
(4) 安全可控不足, 增大了开源软件供应链“带菌”发展的安全风险.
当前, 开源软件的供应更注重效能, 对网络安全方面的需求主要是结合已有的防御手段进行适配应用, 或对已知的攻击设计防御, 导致当前对开源软件供应链的防御管控处于比较被动的状态. 且当前的开源软件供应链安全仍然主要依靠开发人员、组件分发市场、软件管理者、应用软件分发市场和终端用户的努力, 对每一个环节的代码软件进行审查, 具有较低的效率和可信度, 安全管控力度远远不够, 容易将漏洞、后门或者错误代码驻留在供应链中, 造成“带菌”开发、分发和使用, 带来的安全威胁不言而喻. 针对日益复杂庞大的开源软件供应链, 如何实现设计可靠的开源软件供应链监管方案, 仍是当前亟需解决的一个难点.
基于上述研究及
(1) 高效智能的组件及应用软件风险识别技术
针对开源软件供应链依赖复杂背景下漏洞检测能力受限这一难点, 开源软件供应链中, 各个环节的风险识别技术相较于传统的漏洞挖掘技术具有更高的要求, 包括支持自动化可扩展的第三方组件风险识别和抗混淆深层次的应用软件风险识别. 针对自动化可扩展的第三方组件风险识别技术, 潜在的解决方法是结合多种动静态检测方法和智能技术来提高检测能力, 如有机耦合基于元数据、基于静态分析和动态分析的检测方案来识别分发市场上的第三方组件的安全风险. 另一方面, 通过深度学习等技术辅助提取可靠第三方组件的特征, 来区分恶意冒充的第三方组件来抵抗包名无用攻击等. 针对抗混淆深层次的应用软件风险识别, 潜在的解决方案是结合深层次代码语义表征、基于人工智能的程序语义解混淆等智能化技术来提高应用软件风险识别的抗混淆能力, 结合复杂图数据构建与分析等技术来提取目标程序中的复杂依赖关系, 并做进一步的分析.
(2) 新场景及新模式下的风险智能识别技术
新的开发和应用场景随着现代化的进展也在不断涌现, 开源软件供应链各个环节的风险识别技术需基于新的场景和模式进行相应的补充和优化.
针对新涌现的物联网及人工智能场景, 当前研究对其分发市场的研究仍处于初级探索阶段, 相应的第三方组件及应用软件的风险识别研究仍十分匮乏, 如物联网设备固件、人工智能平台和模型中也同样利用了大量第三方组件, 且存在安全风险. 新的场景在攻击面上也会有多样的变化, 带来了新的挑战, 如物联网设备固件架构多样、深度学习模型中的网络模块复用等问题, 需基于新场景下第三方组件和应用软件的特点设计相应的检测方案. 此外, 由于考虑到大量代码依赖和复用带来的许可证违规和组件组合配置风险等, 需要加强对上述新风险的检测方案的研究, 如结合自然语言处理技术增强许可证的语义理解、结合CodeQL等对代码、执行流程的搜索技术来实现对代码的许可证违规查询、基于深度学习技术实现对第三方组件关联组合关系挖掘和风险识别等. 最后, 由于协作开发新模式的引入, 需研究持续性风险识别技术来对不同研究人员的代码提交进行自动化持续性的检测, 如持续性模糊测试、对修改或添加的代码进行定向模糊测试等.
(3) 开源软件的新型加固防御
针对开源软件的新型加固防御技术主要考虑以下两个研究方向: 如何实现组件及应用软件开发环节中高效自动化的代码加固技术及如何实现应用软件分发环节中复杂语义空间下的抗重打包技术.
针对组件及应用软件开发环节, 考虑到开源软件供应链的依赖关系网络, 一个组件的漏洞可以很快利用该网络快速传播, 由点及面, 导致大量下游组件软件面临漏洞威胁, 直接影响到大规模的用户. 漏洞在开源软件供应链上能够以极快的传播速度传播到广大的软件项目中. 针对这一现象, 亟需在组件和应用软件开发环节实现对目标组件及软件的补丁存在性检测、漏洞评估及自动化补丁加固等技术, 且要求能够通过有效的渠道快速、准确地部署到相应的软件系统上.
此外, 针对应用软件分发环节中严重的重打包攻击, 需研究新型安全防御技术如代码水印、代码混淆技术来实现应用软件的知识产权保护, 避免攻击者篡改应用软件.
(4) 结合新兴技术的开源软件管理方案
开源软件供应链庞大复杂, 具有多个环节, 开发实现的软件系统具有大量组件依赖关系. 各个分发市场平台和用户的检测能力有限, 也难以应对风险. 需要软件供应商实现对整个开源供应链的供应关系的管理和检测, 实时提供预警信息. 目前, 这方面的研究仍处于初步阶段. 针对可靠的安全管理方法, 一是需要研究如何加强顶层设计, 通过对开源软件链供应结构的改进, 如添加签名和完整性验证等技术, 将供应链中供应过程记录在区块链上, 保证供应链的完整性和不可否认性等, 从本质上提高开源软件供应链的安全性; 二是提高对开源软件供应链的理解和管理力度, 通过设计对完整供应链的管理手段和工具, 结合新兴的知识图谱、人工智能等技术探索端到端的监管方案, 设计相关流程和工具, 如利用知识图谱对开源软件供应链中第三方组件、应用软件、开发人员等知识进行建模, 并结合深度学习等技术, 帮助实现开源软件供应链的知识分析、管理和评估, 对风险检测和加固防御等下游任务具有重要意义.
随着开源协作新模式下软件供应链的发展, 软件在开发、分发和使用等关键环节中出现了新的威胁渗入点, 如包名误用、恶意代码提交等, 新的场景如物联网、人工智能也对开源软件供应链带来了独特的风险, 如语音抢注攻击、组件组合配置风险等. 针对上述问题, 一大批来自学术界和工业界的学者对开源软件供应链的安全问题进行了广泛关注和深入研究, 并且在开源软件供应链的风险识别、加固和管理等方向上取得了许多瞩目的研究成果. 然而到目前为止, 开源软件供应链安全的研究仍处于初级阶段, 在新兴的时代背景下仍然面临着许多关键的科学问题和挑战, 包括如何设计高效智能的组件及应用软件风险识别技术来应对高效协作模式下软件依赖复用关系高度复杂化、漏洞检测能力受限的挑战, 如何研究新场景及新模式下的风险智能识别技术作为不断扩大的开源软件供应链体系下的风险识别技术补充, 如何设计新型可靠的安全加固方案以应对海量复杂的开源软件供应链渗入点, 以及如何结合新兴技术实现对开源软件供应链的安全可控来降低其带“菌”发展的安全风险.
基于以上内容, 本文从开源软件供应链的理论模型、风险分析、风险识别及加固防御这4个层面系统地研究了当前开源软件供应链安全问题, 回顾了大量具有影响力的研究成果并进行了科学分类、总结和分析. 同时, 本文指出了当前开源软件供应链安全研究面临的现实挑战, 探讨了未来研究方向, 旨在为推动开源软件供应链安全研究的进一步发展和应用提供指导和参考.
Veracode. State of software security: Open source edition.
Wu ZH, Zhang C, Sun H,
武振华, 张超, 孙贺, 等. 程序逆向分析在软件供应链污染检测中的应用研究综述. 计算机应用, 2020, 40(1): 103−115.
Zhou ZF. Research on software supply chain contamination mechanism and defense technology. Beijing: Beijing University of Posts and Telecommunications, 2018 (in Chinese with English abstract).
周振飞. 软件供应链污染机理与防御研究. 北京: 北京邮电大学, 2018.
He XX, Zhang YQ, Liu QX. Software supply chain security: A survey. Journal of Cyber Security, 2020, 5(1): 57−73 (in Chinese with English abstract).
何熙巽, 张玉清, 刘奇旭. 软件供应链安全综述. 信息安全学报, 2020, 5(1): 57−73.
Hassija V, Chamola V, Gupta V,
Du S, Lu T, Zhao L,
GitHub. Build software better, together.
Gitee. Software development and collaboration platform.
PyPI. The python package index.
NPM. Npm.
Maven. Maven—Welcome to apache maven.
OpenWrt Wiki. OPKG package manager.
RubyGems. Your community gem host.
Amazon. Alexa skills and features.
IFTTT. My applets—IFTTT.
OpenSSF. Identifying security threats in open source projects.
Lewandowski K, Lodato M. Introducing SLSA, an end-to-end framework for supply chain integrity. 2021.
CISA. Supply chain compromise.
Torres-Arias S, Afzali H, Kuppusamy TK,
Murray A. Software supply chain attacks. 2021.
Webmin. Webmin 1.890 exploit—What happened?
CrowdStrike Intelligence Team. SUNSPOT malware: A technical analysis.
SECURELIST. ShadowPad in corporate networks.
Wikipedia. XcodeGhost.
The Good Hacker. PHP GIT server hacked and backdoor injected in PHP source code.
Pelayo D. I don't know what to say.
Cimpanu C. Hacker backdoors popular JavaScript library to steal bitcoin funds. 2018.
Cimpanu C. Malware found in arch linux AUR package repository. 2018.
Gonzalez D, Zimmermann T, Godefroid P,
Nutt C. Cloud source host code spaces hacked, developers lose code. 2014.
Codecov. Post-Mortem/Root cause analysis.
Vu DL, Pashchenko I, Massacci F,
Cimpanu C. 17 backdoored malicious images removed from docker hub, but are you really any safer? 2018.
Birsan A. Dependency confusion: How I hacked into apple, Microsoft and dozens of other companies. 2021.
Heartbleed. The heartbleed bug.
Grossman N. Extracting a 19 year old code execution from WinRAR. 2019.
Fischer F, Böttinger K, Xiao H,
Leung L. Cisco sued for copyright infringement over linksys router. 2008.
Mazumdar A, Ross M. Oracle victory stirs uncertainties in software copyright. 2018.
Cochran J. The WireX botnet: How industry collaboration disrupted a DDoS attack. 2017.
Wikipedia. Petya (malware).
TitanWolf. Pandora's box opened: Large-scale software upgrade hijacking attacks broke out in many provinces across the country.
Kirk J. New malware overwrites software updaters. 2010.
Xiao F, Huang J, Xiong Y,
Wikipedia. Dirty COW.
Duan R, Alrawi O, Kasturi RP,
Taylor M, Vaidya R, Davidson D,
Bullock M. Pypi-Parker.
Vu DL, Pashchenko I, Massacci F,
Davis JC, Williamson ER, Lee D. A sense of time for JavaScript and Node. Js: First-class timeouts as a cure for event handler poisoning. In: Proc. of the USENIX Security Symp. 2018. 343–359.
Staicu CA, Pradel M, Livshits B. SYNODE: Understanding and automatically preventing injection attacks on NODE. JS. In: Proc. of the Network and Distributed System Security Symp. 2018. [
Alexa Developer Official Site. Amazon alexa voice AI.
Google. Google assistant, your own personal Google.
Zhang N, Mi X, Feng X,
Guo Z, Lin Z, Li P,
Zhang Y, Xu L, Mendoza A,
Bastys I, Balliu M, Sabelfeld A. If this then what? Controlling flows in IoT apps. In: Proc. of the ACM SIGSAC Conf. on Computer and Communications Security. 2018. 1102−1119.
Ding W, Hu H. On the safety of IoT device physical interaction control. In: Proc. of the ACM SIGSAC Conf. on Computer and Communications Security. 2018. 832−846.
Wang Q, Datta P, Yang W,
Alhanahnah M, Stevens C, Bagheri H. Scalable analysis of interaction threats in IoT systems. In: Proc. of the ACM SIGSOFT Int'l Symp. on Software Testing and Analysis. 2020. 272−285.
Staicu CA, Pradel M. Freezing the Web: A study of ReDoS vulnerabilities in JavaScript-based Web servers. In: Proc. of the USENIX Security Symp. 2018. 361–376.
Kula RG, Ouni A, German DM,
Dey T, Mockus A. Are software dependency supply chain metrics useful in predicting change of popularity of NPM packages? In: Proc. of the Int'l Conf. on Predictive Models and Data Analytics in Software Engineering. 2018. 66−69.
Zerouali A, Mens T, Gonzalez-Barahona J,
Zimmermann M, Staicu CA, Pradel M. Small world with high risks: A study of security threats in the Npm ecosystem. In: Proc. of the USENIX Security Symp. 2019. 995–1010.
Decan A, Mens T, Constantinou E. On the impact of security vulnerabilities in the npm package dependency network. In: Proc. of the Int'l Conf. on Mining Software Repositories. Association for Computing Machinery, 2018. 181−191.
Ruohonen J. An empirical analysis of vulnerabilities in python packages for Web applications. In: Proc. of the Int'l Workshop on Empirical Software Engineering in Practice. 2018. 25−30.
Cheng L, Wilson C, Liao S,
Alhadlaq A, Tang J, Almaymoni M. Privacy in the Amazon alexa skills ecosystem. In: Proc. of the Workshop on Hot Topics in Privacy Enhancing Technologies. 2017.
Lentzsch C, Shah SJ, Andow B,
Li Y, Ji S, Chen Y,
Lyu C, Ji S, Zhang C,
Wang Q, Ji S, Tian Y,
Wang L, Li F, Li L,
王蕾, 李丰, 李炼, 等. 污点分析技术的原理和实践应用. 软件学报, 2017, 28(4): 860−882. http://www.jos.org.cn/1000-9825/5190.htm [doi: 10.13328/j.cnki.jos.005190].
Bleser JD, Stiévenart Q, Nicolay J,
Karim R, Tip F, Sochůrková A,
Kreindl J, Bonetta D, Mössenböck H. Towards efficient, multi-language dynamic taint analysis. In: Proc. of the ACM SIGPLAN Int'l Conf. on Managed Programming Languages and Runtimes. 2019. 85−94.
Staicu CA, Torp MT, Schäfer M,
Manes VJM, Han H, Han C,
Ren ZZ, Zheng H, Zhang JY,
任泽众, 郑晗, 张嘉元, 等. 模糊测试技术综述. 计算机研究与发展, 2021, 58(5): 944−963.
Lee S, Yoon C, Lee C,
Han H, Cha SK. IMF: Inferred model-based fuzzer. In: Proc. of the ACM SIGSAC Conf. on Computer and Communications Security. 2017. 2345−2358.
Chen J, Diao W, Zhao Q,
Yun I, Lee S, Xu M,
Li Y, Ji S, Lyu C,
Zheng Y, Davanian A, Yin H,
Google. American fuzzy lop.
Tellnes J. Dependencies: No software is an island [MS. Thesis]. The University of Bergen, 2013.
OWASP. OWASP dependency-check project.
Cadariu M, Bouwers E, Visser J,
Backes M, Bugiel S, Derr E. Reliable third-party library detection in Android and its security applications. In: Proc. of the ACM SIGSAC Conf. on Computer and Communications Security. 2016. 356−367.
Zhan X, Fan L, Chen S,
Woo S, Park S, Kim S,
Li M, Wang W, Wang P,
Ponta SE, Plate H, Sabetta A. Detection, assessment and mitigation of vulnerabilities in open source dependencies. Empirical Software Engineering, 2020, 25(5): 3175−3215.
Duan R, Bijlani A, Xu M,
Ohm M, Sykosch A, Meier M. Towards detection of software supply chain attacks by forensic artifacts. In: Proc. of the Int'l Conf. on Availability, Reliability and Security. 2020. 1−6.
Akram J, Luo P. SQVDT: A scalable quantitative vulnerability detection technique for source code security assessment. Software: Practice and Experience, 2021, 51(2): 294−318.
Donovan R. Copying code from stack overflow? You might paste security vulnerabilities, tool. 2019.
Bilgin Z, Ersoy MA, Soykan EU,
Xu X, Liu C, Feng Q,
Ding SHH, Fung BCM, Charland P. Asm2Vec: Boosting static representation robustness for binary clone search against code obfuscation and compiler optimization. In: Proc. of the IEEE Symp. on Security and Privacy. 2019. 472−489.
Li X, Qu Y, Yin H. PalmTree: Learning an assembly language model for instruction embedding. In: Proc. of the ACM SIGSAC Conf. on Computer and Communications Security. 2021. 3236−3251.
Hemel A, Kalleberg KT, Vermaas R,
Zhou W, Zhou Y, Jiang X,
Golubev Y, Eliseeva M, Povarov N,
Sajnani H, Saini V, Svajlenko J,
Crussell J, Gibler C, Chen H. AnDarwin: Scalable detection of Android application clones based on semantics. IEEE Trans. on Mobile Computing, 2015, 14(10): 2007−2019.
Gonzalez H, Stakhanova N, Ghorbani AA. DroidKin: Lightweight detection of Android apps similarity. In: Proc. of the Int'l Conf. on Security and Privacy in Communication Networks. 2015. 436−453.
Wan L. Automated vulnerability detection system based on commit messages [Ph. D. Thesis]. Nanyang Technological University, 2019.
Andrade R. Privacy and security constraints for code contributions. In: Proc. of the ACM SIGPLAN Int'l Conf. on Systems, Programming, Languages and Applications: Software for Humanity. 2015. 27−29.
Wu Q, Lu K. On the feasibility of stealthily introducing vulnerabilities in open-source software via hypocrite commit. 2021.
Google. OSS-Fuzz.
Google. Overview of ClusterFuzzLite.
Sinha VS, Saha D, Dhoolia P,
Meli M, McNiece MR, Reaves B. How bad can it git? Characterizing secret leakage in public GitHub repositories. In: Proc. of the Network and Distributed System Security Symp. 2019. Article No. 04B-3.
Garrett K, Ferreira G, Jia L,
Teng JH, Guang Y, Shu H,
腾金辉, 光焱, 舒辉, 等. 基于流量分析的软件升级漏洞自动检测方法. 网络与信息安全学报, 2020, 6(1): 94−108.
Gerwitz M. A git horror story: Repository integrity with signed commits. 2012.
Tedhudek. Trusted publishers certificate store. 2022.
Neelakantam S, Pant T. Learning Web-based virtual reality: Build and deploy Web-based virtual reality technology. Apress, 2017. 69−79.
Lamb C, Zacchiroli S. Reproducible builds: Increasing the integrity of software supply chains. IEEE Software, 2021, 39(2): 62−70.
Ullah F, Raft A, Shahin M,
Bass L, Holz R, Rimba P,
Soliman J. External library management. 2017.
Koishybayev I, Kapravelos A. Mininode: Reducing the attack surface of Node. Js applications. In: Proc. of the Int'l Symp. on Research in Attacks, Intrusions and Defenses. 2020. 121−134.
Nguyen DC, Derr E, Backes M,
Vasilakis N, Karel B, Roessler N,
Vasilakis N, Benetopoulos A, Handa S,
CVSS. Common vulnerability scoring system SIG.
Younis AA, Malaiya YK, Ray I. Using attack surface entry points and reachability analysis to assess the risk of software vulnerability exploitability. In: Proc. of the Int'l Symp. on High-assurance Systems Engineering. 2014. 1−8.
Plate H, Ponta SE, Sabetta A. Impact assessment for vulnerabilities in open-source software libraries. In: Proc. of the Int'l Conf. on Software Maintenance and Evolution. 2015. 411−420.
Wu Q, He Y, McCamant S,
Zhang H, Qian Z. Precise and accurate patch presence test for binaries. In: Proc. of the USENIX Security Symp. 2018. 887−902.
Jiang Z, Zhang Y, Xu J,
Dai J, Zhang Y, Jiang Z,
Chen Y, Zhang Y, Wang Z,
Duan R, Bijlani A, Ji Y,
Wang X, Sun K, Batcheller A,
Wang X, Sun K, Batcheller A,
Apple Developer. Distribute.
Npm Docs. Npm-audit.
Android. Download Android studio and SDK tools.
ProGuard. Java obfuscator and Android app optimizer.
Song L, Tang Z, Li Z,
Gregor F, Ozga W, Vaucher S,
Ozga W, Quoc DL, Fetzer C. A practical approach for updating an integrity-enforced operating system. In: Proc. of the Int'l Middleware Conf. 2020. 311−325.
Karthik T, Brown A, Awwad S,
Singi K, RP JC, Podder S,
Samuel J, Mathewson N, Cappos J,
Kuppusamy TK, Torres-Arias S, Diaz V,
Kuppusamy TK, Diaz V, Cappos J. Mercury: Bandwidth-effective prevention of rollback attacks against community repositories. In: Proc. of the USENIX Annual Technical Conf. 2017. Article No. 17.
Brown F, Mirian A, Jaiswal A,
Cappos J, Samuel J, Baker S,
Nikitin K, Kokoris-Kogias E, Jovanovic P,
Stengele O, Baumeister A, Birnstill P,
Guarnizo J, Alangot B, Szalachowski P. SmartWitness: A proactive software transparency system using smart contracts. In: Proc. of the ACM Int'l Symp. on Blockchain and Secure Critical Infrastructure. 2020. 117−129.
Boyens JM, Paulsen C, Moorthy R,
Cooper D, Regenscheid A, Souppaya M,
CISA. Defending against software supply chain attacks.
UK National Cyber Security Centre. Supply chain security guidance.
UK National Cyber Security Centre. Secure development and deployment guidance.
UK National Cyber Security Centre. Defending software build pipelines from malicious attack.
National Security Science and Technology Evaluation Center. GB/T 36637-2018 Standard Interpretation. 2020 (in Chinese with English abstract).
国家保密科技测评中心. GB/T 36637-2018《信息安全技术ICT供应链安全风险管理指南》标准解读. 2020.
Coughlan S. OpenChain 2.1 is ISO/IEC 5230: 2020, the Int'l standard for open source compliance. 2020.
Clancy DC, Ferraro J, Martin RA,
Microsoft Cybersecurity. Cyber supply chain risk management.
Huawei Technologies Co. Ltd. Huawei Released 2016 Cyber Security White Paper. 2016 (in Chinese with English abstract).
华为技术有限公司. 华为发布2016年网络安全白皮书. 2016.
Red Hat. How to use a trusted software supply chain to adopt DevSecOps. 2020.