文献阅读笔记 # 开源软件供应链安全研究综述_sourcerercc

• 纪守领,王琴应,陈安莹,赵彬彬,叶童,张旭鸿,吴敬征,李昀,尹建伟,武延军.开源软件供应链安全研究综述.软件学报. http://www.jos.org.cn/1000-9825/6717.htm
• 主要作者来自浙江大学、中科院软件所、华为
• 资源: pdf

---

摘要

本文总结了开源软件供应链的关键环节, 基于近10年的攻击事件总结了开源软件供应链的威胁模型和安全趋势, 并通过对现有安全研究成果的调研分析, 从风险识别和加固防御两个方面总结了开源软件供应链安全的研究现状, 最后对开源软件供应链安全所面临的挑战和未来研究方向进行了展望和总结。

1 开源软件供应链模型

• 软件供应链：
  • 定义一：通过一级或多级软件设计、开发阶段编写软件,并通过软件交付渠道将软件从软件供应商送往软件用户的系统；
  • 定义二： 开发软件和组装软件的过程, 包括从源代码到最终软件交付给用户的整个开发、发布、部署和维护过程；
• 开源软件供应链：
  • 开源软件在开发和运行过程中, 涉及到的所有开源软件的上游社区、源码包、二进制包、第三方组件分发市场、应用软件分发市场，以及开发者和维护者、社区、基金会等，按照依赖、组合等形成的供应关系网络；
• 开源软件供应链的四个关键环节：组件开发环节、应用软件开发环节、应用软件分发环节和应用软件使用环节；
  

2 开源软件供应链的风险分析

2.1 开源软件供应链的威胁模型

本文从开源软件供应链的环节角度对开源软件供应链进行威胁建模，总结了攻击目标环节、攻击面和违反的关键安全属性：

2.2 开源软件供应链的攻击事件分析

（下面是简要记录，详细内容看原文，主要是表1的展开举例）

2.2.1 组件和应用软件开发环节的安全风险

开发环境：污染、操控、攻陷开发集成工具和环境等；
源码管理：绕过源码管理工具的验证管控、窃取开发人员的信任凭证等；
开发依赖：窃取分发市场的信任凭证, 借助分发市场管理上的错误绕过验证等；

2.2.2 应用软件分发环节安全风险

分发管理：绕过分发市场的验证管控、包名误用攻击、恶意接管分发市场的管理权限等；

2.2.3 应用软件使用环节安全风险

下载更新机制：DNS 劫持、中间人攻击、钓鱼攻击等；
运行环境：对运行环境中的数据进行篡改, 拒绝服务攻击以及提权攻击等；

2.2.4 开源软件供应链风险的总体趋势分析

• 应用软件使用环节的安全事件占比最高（因为于攻击者主要目标是实现对终端用户的
  攻击, 并获取收益, 因此大多数攻击都会在该阶段暴露），在开发和分发环节, 攻击者的目的是为了注入恶意代码或者植入后门, 隐蔽性更高, 检测发现安全事件的难度更大；

3 开源软件供应链的风险识别与评估

开源软件供应链各个环节的攻击面风险识别技术：

• 组件和软件开发环节：
  • 供应链视角下组件及软件的漏洞检测
  • 第三方组件(TPC)分发市场的风险
    • 第三方组件分发市场中的恶意软件识别
    • 第三方组件分发市场的风险检测
  • 协作开发的风险：
    • 开源项目的安全性
    • 开源代码贡献人员的隐私性
• 软件分发环节：
  • 对软件分发市场如安卓软件商店等中软件的风险识别
• 软件使用环节：
  • 软件下载更新时网络劫持的风险识别及软件风险识别

各个环节的风险识别和评估总结为以下四个关键研究方向: 开源软件供应链中第三方组件
的风险识别、开源软件供应链视角下的应用软件风险识别、协作开发的风险识别及下载更新过程的风险识别；

3.1 开源软件供应链中第三方组件的风险识别

3.1.1 分发市场中的第三方组件风险识别

主流第三方组件分发市场（包管理器）：PyPI、NPM、RubyGem、OPKG等；
新兴第三方组件分发市场：亚马逊的语音技能市场、IFTTT平台等；

面向包管理器的风险识别，主要研究了恶意包注入的检测技术和其他支持在包管理器中中批量扫描和检测潜在具有漏洞风险的第三方包的相关研究；

• 恶意包注入检测：包名抢注检测，通过包名抢注的两大特性来检测: (1) 攻击目标往往是流行包; (2) 恶意包和原始包的名字十分相似；当某个软件包与某个流行的软件包名称十分相似, 且自身的流行度较低, 则认为该软件包为潜在的恶意软件包；
  
• 包管理器中的存在漏洞风险的第三方包检测：基于源代码的分析方法；
  • 静态检测：eg.利用正则匹配对 NPM 包的元数据进行分析;
  • 动态检测：eg.Synode 框架通过静态分析识别相关 API 的调用点, 基于分析结果实现脚本的模拟运行，来检查是否存在恶意的第三方组件以开发人员可能无法预见的方式实现恶意代码执行;(静态分析的准确率较低，而动态分析提高了准确率的同时，性能开销较大)

MALOSS 框架是一个更普适的方案：通过元数据分析、静态分析和动态分析来对 NPM、PyPI 和 RubyGems 三大市场中的第三方包进行全面、系统的分析：

• 元数据分析：通过提取代码包的元数据，如包的名称、开发作者、维护者、发布版本、下载次数和依赖关系等来识别出潜在的恶意数据包；
• 静态分析：通过对代码包的源代码进行分析，标记网络、文件系统、进程、代码生成相关的 API，进一步将源代码解析为语法结构树并搜寻标记 API 的使用情况，最后分析代码数据流，检查代码数据流的源、sink 节点和传播节点；
• 动态分析：通过在隔离的 docker 环境中安装执行二进制代码包，触发导入包时的初始化逻辑来测试 import 包, 用动态模糊测试触发相应功能来测试导出函数, 最后用 sysdig 来捕获代码运行时的系统调用 trace；

面向第三方语音技能分发市场的第三方组件风险识别：

• 恶意包的注入主要体现为语音抢注攻击、语音伪装攻击两种新型攻击, 可能导致恶意指
  令执行、隐私窃取等风险；相关检测工具：Skill-name Scanner、SkillExplore、LipFuzzer

面向自动化应用程序组件分发市场的第三方组件风险识别：自动化应用程序分发市场上发布了一系列提供特定应用功能的组件, 由下游开发者或用户对不同功能的组件进行组合配置，实现自动化的应用程序；

• 主要检测是否存在恶意程序组件收集用户的隐私以及程序组件是否存在自身的缺陷易被攻
  击者利用，还需要考虑到下游用户安装组件组合的风险；
• 物联网设备的组件可以共同对环境作用，当用户安装配置了一些特定的第三方组件的组合时，形成了一些潜在的物理通道，攻击者可以利用这些物理通道控制受害者的物联网设备并执行恶意指令；
  相关工作：IoTMon、iRuler、IoTCom；
  
  

3.1.2 第三方组件分发市场分析及安全评估

• 第三方包在供应链关系中的依赖链条较长，第三方包的变化会对整个软件生态系统造成巨大的变化；
• 供应链中上下游依赖关系对第三方组件的分发有重要影响；
• 单个第三方包甚至能够影响整个生态系统的大部分包（只需要拥有极少部分维护者账号就能够将恶意代码注入生态系统中大多数的包）；

• 现有的第三方包供应链生态在功能性检查、审核检查和补救响应审查上仍缺失大量措施，审核检查阶段是当前最薄弱的阶段，在补救响应上仍存在较大缺失；

3.2 开源软件供应链视角下的应用软件风险识别

开源软件供应链视角下特有的软件风险及对应的风险识别方案：

• 应用软件中第三方组件检测及其风险识别；
  • 检测应用软件中的第三方组件（软件成分分析）
  • 应用软件中的第三方组件的风险识别（前文3.1所述）
    • 1-day 漏洞
    • 许可证违规
• 应用软件代码克隆检测；
  • 利用软件相似性技术识别代码克隆导致的漏洞传播；
  • 许可证违规风险；
• 分发市场中的恶意软件识别；
  • 利用软件相似性技术识别恶意篡改的软件；

3.2.1 应用软件中的第三方组件检测及其风险识别

针对软件系统中的第三方组件的风险识别研究中，当前的研究方案能够支持白盒和黑盒场景的分析，但是在抗混淆和可传递性上仍有较大研究空间。

多个角度研究高效检测软件系统中的第三方组件及其漏洞：

• 基于元数据的第三方组件静态检测；
  • Maven 实现了 OWASP Dependency Check（由于字段名可能发生变化，该工具存在较大的漏报率）：支持扫描项目中的依赖项文件名、供应商和版本等信息并识别潜在的依赖第三方组件；
  • 进一步通过确定项目依赖项中是否存在 通用平台枚举标识符(CPE) 来检测项目依赖关系中是否包含公开的披露漏洞；（CPE 标识符唯一地表示受 CVE 影响的应用程序）；
• 基于源代码的第三方组件静态检测：利用哈希、控制流图和函数名等信息进行匹配；【白盒】
  • 已知第三方库的特征对未知的软件系统进行匹配识别
    • 基于哈希匹配的安卓库检测工具 LIBSCOUT，支持提取应用程序中混淆后的配置特征，能够抵抗常见的代码混淆问题，并精确定位应用中使用库的版本；基于多层哈希，对安卓库的 method、class、package 类
      层层递进实现哈希，最后进行匹配；
    • Atvhunter：查明应用程序使用的易受攻击的第三方组件版本并提供有关第三方组件漏洞的信息；基于两阶段检测方法来识别特定的第三方组件版本；提取控制流图(CFG)作为粗粒度特征以及提取 CFG 的每个基本块中的操作码作为细粒度特征来识别确切的第三方组件及其版本；（但不能用于识别修改后的三方组件）；
    • CENTRIS：基于代码分段技术，使用松散匹配来检查目标软件和第三方组件之间的代码相似性是否大于预定义的阈值，来嵌套检测相似的第三方组件依赖关系；（代码分段技术降低了误报，且能在大量修改或嵌套的情况下识别第三方组件）；
  • 直接对软件系统进行第三方库的提取, 无需提前获取到第三方库的知识
    • 抗混淆的第三方组件检测工具 LibD：用安卓程序内部的代码依赖性来检测和分析潜在的第三方组件，相比代码相似性检测，LibD 使用特征哈希处理混淆的函数名称, 准确率较高；
    • 检测、评估和缓解第三方组件漏洞的方法 Eclipse Steady：以代码为中心，在给定的上下文中结合静态和动态分析来确定库中易受攻击部分的可达性；
• 基于二进制代码的第三方组件静态检测；【黑盒】
  • OSSPolice：支持在没有目标应用软件源代码场景下对二进制的程序进行第三方组件的识别，对软件系统的开源软件证书冲突进行了检测, 并对 1-day 漏洞进行识别；采用分层索引方案来比较应用程序的二进制文件和数万个第三方库源代码的数据库, 能够实现高可扩展性和高准确率的第三方组件检测
  • Buildwatch：动态分析软件及其第三方依赖组件，存在恶意第三方组件的软件在安装过程中会引入大量新的第三方组件，将测试软件运行在沙箱环境中, 分析软件的系统调用，主要是分析测试软件在安装过程中表现出来的行为来确定软件可能已经被恶意的第三方库感染。

3.2.2 应用软件代码复用检测

开源软件供应链中代码复用带来的 1day 漏洞及许可证违规风险；缺陷：混淆后的代码上的检测能力，下游任务如漏洞检测及许可证违规检测的相关研究；

源码

• SQVDT：收集易受攻击的代码数据集并提取不同的特征来构建指纹签名集，对项目中的文件进行相似性匹配；利用 MapReduce 在大规模集群上进行快速分析和处理，在相似性检测的效果上准确率较高，但召回率较低；
  【该综述对源码方面的工作列举的太少了，这里应该有很多相关工作】

二进制 【ps：之前写过相关笔记】

• Gemini：分析二进制程序，控制流图+图嵌入【ps：之前写过相关笔记】
• Asm2vec
• PalmTree

3.2.3 分发市场中的恶意应用软件识别

分发环节中攻击者会对安全软件进行恶意篡改或者添加恶意载荷;

基于元数据的方案简单、速度快但准确率低。

• 分析固件源码和二进制两者是否字符串、压缩数据的大小、二进制增量的数据大小是否一致来实现检测，存在大量误报和漏报；

基于相似度函数的相似恶意检测：

• 利用哈希作为相似度函数进行比较，检测速度快，准确率相比元数据高；
• 安卓应用分发市场中有攻击者会对应用程序进行重打包，然后嵌入一些新的广告，来窃取广告或者重新路由广告收入：DroidMOSS 用于检测这些重打包的应用程序，基于模糊哈希技术对程序的指令序列进行计算形成应用的指纹，通过计算相似性函数来定位和检测应用程序重打包行为，该方案抗混淆能力弱；
• SourcererCC：采用了针对代码块的比较算法，用于软件许可证违规的检测；
  

基于人工智能的代码相似性比较：训练要求高，训练花费时间长

• Andarwin：将程序表示为一组在应用程序的程序依赖关系图上计算的向量，接着对所有应用程序的所有向量进行聚类找到相似的代码段, 考虑完全和部分应用程序的相似性
  
• DroidKin：在多种混淆级别下检测应用程序的相似性，对程序元数据和字节码提取特征形成特征向量，基于特征向量对给定程序的潜在候选者进行识别和评分，最后检查相似应用之间的所有可能关系并根据所设计功能的类型进行优先级排序；

3.3 协作开发的风险识别

对持续集成(CI)/持续交付(CD)管道和开发工具中的弱点进行代码仓库接受开发维护提交请求的评估、识别协作开发过程中代码提交的风险和隐私数据泄露的研究

代码提交请求中的代码风险

• 基于深度神经网络对提交消息自动识别恶意修复提交 (VFC)
• Anomalicious：更具有扩展性且自动化的恶意提交检测方案，利用提交的日志记录和代码存储仓库元数据来自动化检测异常和潜在的恶意提交，识别敏感文件的修改、异常值更改属性、提交作者的名誉，采用基于规则的决策模型来自动计算和分析敏感行为或者影响因素，最终进行判断是否是恶意的提交；
  
• Salvum：自动化发现提交代码是否存在访问隐私文件的风险，Salvum 要求用户使用他们的策略语言编写约束，再基于信息流控制 (IFC) 的工具实现对 Java 源代码的静态分析，并判断代码对用户编写的约束的遵守情况；
• “伪装者提交”：提交一系列看似无害的代码补丁，但是当代码被集成到软件中后，提交的代码和已存在的代码可以共同作用导致引入一些漏洞；
• OSSFuzz、ClusterFuzzLite：研究持续地对代码提交进行模糊测试

代码提交请求中隐私泄露风险 如：API 密钥泄露

• 基于关键词的搜索：例如"––BEGIN RSA PRIVATE KEY––“，缺点：误报、漏报较高，无法确定密钥是否已经进行脱敏处理, 且无法搜索到没有相应独特声明字段的密钥泄露；
• 基于模式匹配的搜索：将源文件生成抽象语法树 (AST)，并对字符串文字节点执行模式搜索
• 基于启发的密钥泄露检测过滤：启发式规则，如客户 ID 和密钥通常成对出现，添加额外的检查搜索客户端 ID 和密钥是否出现在 5 行之内，另外降低误报方面，许多误报实际上是人类可读的字符串，可以用标准的密码强度估计器，过滤掉具有重复字符或包含字典单词的字符串。
• 基于源程序切片的检测

3.4 下载更新过程的风险识别

用户在下载和更新软件时可能存在网络劫持、钓鱼网站，研究方向：更新下载渠道的风险识别

• 恶意更新异常检测：利用了机器学习技术, 通过学习正常软件包更新的特征, 训练模型分辨恶意更新的数据包；
• 网络劫持的风险识别：基于流量分析的软件更新漏洞自动检测和验证，通过提取软件更新过程中的网络流量，对升级机制进行自动画像，并将其与漏洞特征向量匹配，来预判潜在的漏洞；

该方面研究较少，是因为希望从本质上解决下载更新渠道的安全性【但其实存在非渠道被攻击，而是供应链提供者主观作恶的情况，这方面研究就存在重要意义了】

4 开源软件供应链的加固与防御

针对开源软件供应链的主动加固和防御方案

4.1 针对开源软件供应链单个环节的加固防御

组件及应用软件开发环节中可信开发方案的设计、组件及应用软件开发环节中代码的安全加固、应用软件分发环节中可靠的分发方案和应用软件使用环节中安全的使用方案；

4.1.1 可信开发

协作开发过程和开发依赖中的可信开发研究

整个开发过程的安全性：通过对代码构建、编译、生成、测试和部署的每一个环节添加校验来保证程序的完整性，帮助实现安全可信的开发过程；

• 源代码构建：恶意攻击者冒充开发人员提交恶意代码，解决方案：代码跟踪校验
  • 对每个提交都进行代码提交的签名并对签名进行验证；
  • 可信发行商证书让开发人员对受信任的代码发布者的签名信息进行验证；
• 编译、生成、测试过程中可能引入新的漏洞来破坏用户系统：可复制构建(reproducible builds)
  • 构建一个给定的源代码树会生成逐位相同的结果，可以通过比较从多个独立构建起输出的结果来确定构建器是否可信，来确定二进制程序是否和其源代码一致
• 持续部署管道
• 开发依赖：工业界往往采用建立自己的开源第三方组件管理库(只有第三方组件通过企业的安全审核后再进入企业的第三方组件管理库中)；

4.1.2 代码加固【重要】

研究课题：减少攻击风险及构建代码补丁

• 减少攻击风险：开发过程中是否引入不必要或存在问题的第三方组件，同时也关注开发和部署的完整性。
  • Mininode：检查 node 项目，减少攻击面；
  • BreakApp：支持开发者在开发过程中限制引入的第三方组件行为（JavaScript）；
  • 编译型语言的加固相对较难，目前研究相对较少；
• 代码补丁：在开源软件供应链视角下，漏洞会从上游传播到下游，下游组件及应用软件的补丁难以第一时间得到响应；对开源软件供应链漏洞影响的评估、对软件是否存在补丁的评估和自动打补丁的研究；
  • 漏洞评估：补丁的效果和违反安全规则的影响可以建模为需要自动解决的约束问题，利用基于规则的比较和符号执行等对漏洞进行分类和评估。除了漏洞的影响力评估外，安全开发和维护人员需要进一步确认漏洞的影响版本，补丁的定位，以及下游组件及应用软件是否部署了该补丁。
    • 基于 CVSS 度量标准，基于可利用性和影响度量衡量严重性，但缺失对访问复杂性的评估；
    • 基于攻击面入口点和到达能力更全面地评估漏洞可利用性风险；
    • 通过分析补丁引入的代码更改来评估漏洞的影响；
  • 补丁存在性：
    • Fiber：解析和分析开源安全补丁，然后生成细粒度的二进制签名，反映补丁引入后的最具代表性的语法和语义变化，用于搜索目标二进制文件；主要关注补丁和最小上下文的小变化，而不是整个功能或文件，提高了效率；（二进制）
    • PDiff：基于语义的补丁存在性检测框架，基于程序代码的语义总结，将补丁采用前后的目标内核与其主流版本进行比较，优先选择更接近的参考版本来确定补丁状态，基于补丁的语义来检查相似性，因此对代码级变化提供了很高的容忍度；（源码级别）
      
    • BScout：直接检查 Java 可执行文件中是否存在整个补丁，即检查补丁识别漏洞是否存在，不需要特征构建，通过建立 Java 字节码对源代码的链接，实现对整个目标可执行文件中的细粒度补丁语义的准确检测；
  • 自动打补丁【亮点】：
    • KARMA：适用于 Android 内核的自适应实时修补系统，KARMA 中的补丁可以放置在内核中多个级别来过滤恶意输入且自动适应数千种 Android 设备；
    • OSSPATCHER：能够直接从源代码补丁构建功能级的二进制补丁，并在发现漏洞的应用程序上执行补丁；
    • 考虑到攻击者可能提供不安全/带有漏洞的补丁，因此需要区分安全的补丁和不安全的补丁；

4.1.3 可靠分发

可靠分发主要目标是保障应用软件的完整性和可追溯性
分发市场和应用商店通常设计并实现软件审核和检测机制以对抗伪装、虚假的应用软件，对应用程序进行 API 的扫描、代码相似性的检测以及人工审核测试程序是否能够正常运行且没有安全风险；

• npm 提供了自动的项目漏洞扫描和兼容性更新修复的功能；
• 抵御重打包攻击：
  • 自签名策略：在发布软件的过程中，软件包的哈希值和开发者签名也需要被发布，让用户下载软件时可以对软件进行完整性的验证；
  • 代码混淆：增加逆向门槛
    • Proguard：安卓的一个基础混淆工具，混淆源码
    • 具有时间多样性的联锁保护网来防止安卓应用程序的篡改，根据相应的威胁模型随机构建不同结构的防护网，利用了 Java 原生接口的跨层调用机制为代码、核心算法和敏感数据提供多级保护；

如何结合智能技术如混淆逻辑门、深度学习等来加强代码混淆能力以及对代码混淆的评估仍是重要研究方向之一；

4.1.4 使用安全

• 安全运行：可信运行环境，应用软件运行时免遭攻击者的威胁；
• 安全下载：
  • TSR：基于可信运行环境的进一步研究，结合 SGX 提出的安全更新方案，能够保证软件包升级的机密性和完整性；
  • Uptane：针对汽车的安全更新框架，专为智能汽车实现固件更新，使用了多个服务端来对要下载的固件进行检验，设计了控制服务器来管理固件映像决定哪些固件映像需要被安装和验证，设计了时间服务器通过从车辆接受令牌并返回包含令牌和当前时间的签名序列来通知车辆当前时间，避免重放攻击；

4.2 面向多环节的可靠开源软件供应链方案设计

当前的研究方案主要考虑到组件及应用软件开发环节和应用软件分发环节之间的供应关系【没考虑使用环节】, 设计对组件及应用软件开发和分发过程进行全面管理和监控的方案，来使得开发人员或终端用户可以从分发市场上下载可信安全的组件或应用程序。

• 可信的软件供应链治理框架：
  • 把软件供应过程中产生的所有数据包括依赖的第三方组件、开发人员对应开发的代码等存储在区块链中，进行统一的表示，接着以智能合约的形式指定合规/监管规则和最佳实践，并分析事件数据以识别不合规问题并发出警报；
  • 该框架允许在整个应用程序开发生命周期中记录、监视和分析各种活动，从而使开发过程透明、可审计、遵守法规和最佳实践, 从而实现软件的可信赖性；
• in-toto：关注组件及应用软件从开发到分发过程中代码的完整性，并保证开发人员可以按预期完成开发过程；
  • 项目管理者：
    • 设置称为布局的数据即 .po 文件，定义了软件项目在软件供应链开发环节中的每一个步骤包括代码书写、测试和分发等涉及的人员及资源信息；
    • 项目管理者可以定义由三个步骤组成的供应链: 标记、构建和打包步骤；
    • 项目管理者还定义了资源将如何在供应链中流动；
    • 项目管理者可以分配工作人员来执行这些步骤；
  • 软件开发维护者：
    • 负责执行该任务的需要使用布局中定义的私钥数据对每个环节中的输入输出和执行过程进行签发，作为供应元数据；
  • 终端用户：
    • 当产品交付到终端用户时，终端用户可以对以下几点进行校验：(1) 供应链布局由项目管理者签发，并且尚未过期(时效性)；(2) 检查供应元数据是否和布局一致，验证供应的每个步骤是否按预期执行; (3) 检查供应元数据确认供应链的完整性；
      

in-toto 方案如果密钥泄露或者源代码集成环境缺陷导致绕过验证，该方案将不再有效。针对这一缺陷有两个研究方向：

• 基于多级密钥管理来降低密钥泄露的风险：降低了密钥泄露的风险
  • 由一个根密钥管理者生成并保存一个密钥，基于该密钥向下级开发人员或维护人员派生分发相应的密钥，来将对代码修改维护等操作的权限委托给可信的协作开发人员；
  • TUF：定义了不同的用户角色和信任委托机制, 对开发过程中的角色包括源码管理仓库的管理者、协作开发人员以及下游组件或应用软件的使用者进行划分和限制, 防止各环节参与方权限滥用、破坏开发的组件及应用程序的完整性；
    • TUF 定义了在密钥泄露的情况下如何实现可信开发；定义了不同的用户角色和授权, 在密钥泄露的情况下，基于多级密钥管理实现的信任层次结构使攻击者难以破坏整个系统；
    • TUF 给社区存储库带来了巨大的可用性挑战：要求开发者在交付一个组件或应用软件视就需要实时在相应的分发市场向该框架进行注册登记；【不适合于开源场景】
  • Diplomat：对 TUF 缺陷进行改进，但容易遭受回滚攻击；
  • Mercury：修复了 Diplomat 框架中的回滚攻击缺陷；只需要较少的带宽，使用增量压缩仅仅传输先前和当前版本信息列表之间的差异时来降低传输开销；
  • SPAM：主要解决密钥重用和密钥攻陷的问题, 支持自动化管理开发协作人员；
  • Stork：主要研究如何实现基于角色的最小信任量委派, 以及考虑到开发的组件及应用软件可能需要动态更新或撤销, 研究如何在密钥分配管理中支持动态的密钥派生和撤销；
• 基于区块链的方式来实现可信开发管理方案：加强了开发过程的透明性，动态的密钥派生和撤销以及开发过程中引入风险识别知识来加强开发代码的安全性
  • SkipChain：需要协作开发人员均可信，使用了集体签名协议来签署开发的组件或应用软件，将开发过程中的所有相关信息都存储到区块链中, 保证了开发流程的透明性, 但该系统没有考虑软件供应链中开发过程的动态性, 没有解决繁琐的证书撤销问题；
  • Stengele 等人：解决 SkipChain 未解决的动态的证书撤销和派生问题，基于以太坊区块链, 提出了一个用于发布和撤销二进制文件完整性保护信息的方案，设计智能合约用于强制执行对完整性保护信息的发布和撤销的访问控制；
  • SmartWitness：提供开发组件及应用软件的透明性、高效且细粒度的密钥撤销，动态将一些安全检测方法构建为智能合约, 实现对开发代码安全性的评估, 并作为元数据添加保存；

5 开源软件供应链的法律政策

这一节略写，详情看原文；

5.1 国家层面的法律政策

国内相关法律文件：

• 《网络安全审查办法》
• GB/T 24420-2009 供应链风险管理指南
• GB/T 31168-2014 云计算服务安全能力要求
• GB/T 32921-2016 信息技术产品供应方行为安全准则
• GB/T 22080-2016 信息技术-安全技术-信息安全管理体系要求
• GB/T22239-2019 信息系统安全等级保护基本要求
• GB/T 29245-2012 政府部门信息安全管理基本要求
• GB/T36637-2018 信息安全技术 ICT 供应链安全风险管理指南 【我国第一个 ICT 供应链安全国家标准】

5.2 社会层面的行业规范

• ISO/IEC5230:2020 标准

5.3 企业层面的具体实践

略；

6 现实挑战与未来研究方向

6.1 现实挑战

略；类似上表；

6.2 未来研究方向

略；类似上表；

7 结束语

略；