近日，微软发布“安全供应链消费框架(Secure Supply Chain Consumption Framework，简称S2C2F)”1.1版本。该框架已被OpenSSF供应链完整性工作组采用。至此，OpenSSF开源软件评价相关的项目和指南已覆盖使用安全、关键性、基础设施安全、漏洞披露机制等多个方面，它们公布出的相关框架流程、指标条目、实践工具等内容对我国的开源软件安全工作有一定的借鉴作用。

一、S2C2F V1.1解读

S2C2F自2019年提出后，一直作为微软的一项内部倡议，直至此次被OpenSSF采用，它专注于开发集成人员对开源软件(OSS)使用的安全。与其他开源软件安全框架或指南相比，S2C2F具有三个主要特点：

1、框架实践面向威胁且覆盖使用全过程

S2C2F V1.1共包含8项实践，即引入、扫描、库存、更新、审计、执行、重构建、修复(并通知上游)，涵盖了组织在使用OSS过程中各个环节上的治理工作，每个实践又包括若干条具体的“要求”，例如，“扫描”实践的“要求”共有5条，如下表所示。

实践	要求ID	要求标题	价值
扫描	SCA-1	扫描OSS中的已知漏洞(如CVE、GitHub建议等)	能够更新OSS以降低风险
	SCA-2	扫描OSS中的许可证	确保组织与软件许可证保持一致
	SCA-3	扫描OSS确定其寿命是否结束	出于安全目的，任何组织都不应该依赖不再接收更新的软件
	SCA-4	扫描OSS中的恶意软件	能够防止恶意软件进入CI/CD环境
	SCA-5	对OSS进行主动的安全审查	识别0day漏洞并秘密地将修复工作反馈给上游维护者

S2C2F的实践和要求是基于已知OSS安全威胁而设计的，包括战术和技术两方面的威胁，如漏洞、后门、恶意代码植入和欺骗、恶意依赖项、编译器破坏、依赖混淆、包完整性篡改、上游源代码删除、OSS组件停止修复、未按时修复漏洞、包管理器恶意代码上传等。

针对每种威胁类型，框架都列出了相应的可用来缓解的“要求”。例如，针对“构建恶意OSS包欺骗使用者”的威胁，框架建议采用的要求包括：验证OSS的来源(AUD-1)、强制使用策划的OSS入口控制器以增强对OSS的信任(ENF-2)、扫描OSS中的恶意软件(SCA-4)等。

2、成熟度等级便于组织建立进阶路线图

S2C2F是一个成熟度模型，将针对OSS使用安全的25条要求划归4个不同的成熟度等级，组织可以对照评价自己当前所处的等级，并明确未来改进的方向。下表是各等级的主要描述及对应的要求，其中L4被定义为理想级，实现成本较高，估计难以在整个组织中大规模实施，但可以考虑在关键项目中的关键依赖项上应用。

等级	L1	L2	L3	L4
目标	OSS最小治理计划	使用安全和改进平均修复时间(MTTR)	恶意软件防御和0day漏洞检测	高级威胁防御
主要内容	使用包管理器、工件本地副本、扫描已知漏洞、扫描软件许可、库存OSS、手动OSS更新	扫描已终结组件、有事件响应计划、自动OSS更新、PR时漏洞预警、审计使用批准的方法引入的组件、验证OSS的完整性、包源文件配置安全	拒绝列表功能、克隆OSS源、扫描恶意代码、主动安全审查、强制OSS来源、强制使用来自策划的入口控制器的组件	验证使用OSS的SBOM、在可信的环境上重构建OSS、数字签名重构建的OSS、为重构建的OSS生成SBOM、数字签名受保护的SBOM、实施修复
对应要求	ING-1、ING-2、SCA-1、SCA-2、INV-1、UPD-1	SCA-3、INV-2、UPD-2、UPD-3、AUD-2、AUD-3、ENF-1	ING-3、ING-4、SCA-4、SCA-5、AUD-1、ENF-2	AUD-4、REB-1、REB-2、REB-3、REB-4、FIX-1

3、各条要求对应的工具列表展现实操性

S2C2F还有一大特点是聚焦OSS安全治理的落地，框架针对各成熟度等级中对应的具体实践和每条要求，列出了自动化免费工具和付费工具，供开发集成人员参考。例如，针对L1中的要求SCA-1(需扫描依赖的已知漏洞。选择一款可从更多渠道而不仅仅是CVE获取漏洞的工具，对于确保从多个漏洞来源获得信息非常重要)，S2C2F推荐的工具包括：免费工具GitHub Dependency Graph和付费工具Snyk Open Source、Mend SCA。

当然，由于微软的背景，S2C2F推荐的工具以美国厂商生产的产品为主。国内用户在参考时可考虑使用相同功能的国产工具，例如，在OSS已知漏洞扫描、许可证风险扫描等方面，奇安信开源卫士可提供同等优良的能力。

此外，S2C2F每条要求的制定也充分参考了NIST SP 800-161、SSDF、CIS软件供应链安全指南、OWASP SCVS、SLSA、CNCF软件供应链最佳实践等已有框架指南的内容。

二、OpenSSF开源软件安全评价方法体系分析

1、开源软件安全评价方法体系

OpenSSF单独或联合其成员发布的项目、指南、框架已覆盖开源软件的使用安全、关键性、基础设施安全、漏洞处理等多个方面，形成了针对开源软件的安全评价方法体系，如下图所示。基础设施安全包括网站、版本控制、构建、加密、包管理器等涉及OSS开发、存储、发布等环节设施的安全。部分指南内容可参见https://mp.weixin.qq.com/s/NyVxcJmUol-2X1kH5r_pvA。

上述分类仅反映这些项目、指南、框架的侧重点，并不代表它们之间是完全没有交集的。例如，OpenSSF记分卡中有一个指标是“被维护的”，其中重要的一项是考虑OSS项目每周的提交次数，而OpenSSF开源项目关键性评分中也有类似指标。《评估开源软件的简明指南》(以下简称《简明指南》)中也有“持续维护”方面的内容。

2、开源软件的使用安全

作为软件开发中最重要的第三方原材料之一，OSS的使用安全对于使用者来说，无疑是最值得关注的。OpenSSF记分卡、S2C2F和《简明指南》虽然都侧重于OSS的使用安全，但它们之间也有明显的差异。

· 关联关系

OpenSSF记分卡是一款基于19项评价指标的OSS项目安全指数自动生成工具。S2C2F为“扫描”实践的SCA-3要求(扫描OSS生命是否已终结)推荐的免费工具就是OpenSSF记分卡；《简明指南》中“开发者增强安全性的证明”方面的评价也包括“是否检查了开源软件的OpenSSF记分卡值和已知漏洞”的指标。因此，记分卡可以看做是基础。

另一方面，三种评价方法中的指标有许多也是相同的。例如，三者都有“扫描已知漏洞”的指标或要求，这也是OSS使用安全中最核心的内容之一，可借助软件成分分析(SCA)工具方便的实现。

· 主要差异

首先，OpenSSF记分卡是从OSS自身的角度考虑的，而S2C2F和《简明指南》则是从开发集成人员的操作层面考虑的。

在具体指标方面，三者也存在不小的差异，主要体现在两个方面。一是名称或技术内涵相同但实施环节或方式不同的指标，例如，OpenSSF记分卡和《简明指南》中都有代码审计的指标，但记分卡中指的是“合并之前，项目是否要求代码审计”，而《简明指南》中的代码审计指开发集成人员使用静态分析工具发现首要问题；二是各自特有的指标，如OpenSSF记分卡的“项目是否有分支保护”、《简明指南》的“是否尽量减少依赖的数量(使用现有的依赖关系，不再增加)”、S2C2F的“强制使用策划的OSS入口控制器(ENF-2)”，这些都是各自特有的。

总体而言，三者各有优势。OpenSSF记分卡的优势在于其自动化工具的属性，有助于使用者对OSS的安全状况进行自动化分析和信任决策；S2C2F的优势是其框架结构和成熟度等级，符合使用者的理解逻辑，针对性的指导作用较强；《简明指南》给出了OSS使用安全9个方面的内容，可看做是一些基本原则，某些方面也列出了具体的示例。

三、对我国开源软件安全工作的启示

2021年10月，中国人民银行、中央网信办等五部门联合发布了《关于规范金融业开源技术应用与发展的意见》，就规范金融机构合理应用开源技术，提高应用水平和自主可控能力等方面提出了原则性要求，开源软件安全是其中的重要内容；2022年11月初，国家标准《信息安全技术 软件产品开源代码安全评价方法》完成立项。

这些都说明国家层面已意识到开源软件安全的重要性，并着手规范应对此类问题。结合前面的相关研究，本文建议可从以下三个方面考虑开源软件的安全评价方法：

· 从开源软件使用者角度确立指标体系框架。

S2C2F给出了一个很好的示范，该框架从开源软件使用者的角度梳理出8项安全实践，对应于使用过程中的8个环节。因为开源软件使用者同样也是评价方法的使用者和评价结果的决策者，所以从这个角度设计的框架更符合广泛的理解逻辑，能够产生更好的指导效果。

· 兼顾开源软件的自身安全和基础设施安全。

对于开源软件安全性的评价，既要考虑安全漏洞、后门、恶意代码、数字签名、SBOM等自身的安全因素，同时也应该兼顾诸如OpenSSF最佳实践徽章和《NPM最佳实践指南》之中明确的官方发布网站、版本控制、构建、加密、包管理器、漏洞共享披露机制等基础设施的安全。

· 统筹开源软件安全评价的指导性和落地性。

一方面，可参考目前已有的标准、指南和框架，并结合我国开源软件使用组织的实际状况，制定兼具指导性和完备性的开源软件安全评价指标体系；另一方面，可借鉴S2C2F工具列表的做法，推荐相关的自动化工具，并将国产优秀工具作为首选，以增强评价方法的落地性和实操性。

推荐阅读

在线阅读版：《2022中国软件供应链安全分析报告》全文

在线阅读版：《2021中国软件供应链安全分析报告》全文

微软GitHub Copilot 被诉违反开源许可条款和侵犯开发人员权益

美国政府发布软件供应链供方实践建议指南

NISA和CISA分享软件供应链安全建议

美国“加强软件供应链安全实践的指南” (SSDF V1.1草案) 解读来了

速修复！这个严重的 Apache Struts RCE 漏洞补丁不完整

Apache Cassandra 开源数据库软件修复高危RCE漏洞

美国国土安全部：Log4j 漏洞的影响将持续十年或更久

Apache Log4j任意代码执行漏洞安全风险通告第三次更新

PHP包管理器Composer组件 Packagist中存在漏洞，可导致软件供应链攻击

LofyGang 组织利用200个恶意NPM包投毒开源软件

软件和应用安全的六大金科玉律

美国政府发布关于“通过软件安全开发实践增强软件供应链安全”的备忘录（全文）

OpenSSF发布4份开源软件安全指南，涉及使用、开发、漏洞报告和包管理等环节

美国政府发布联邦机构软件安全法规要求，进一步提振IT供应链安全

美国软件供应链安全行动中的科技巨头们

Apache开源项目 Xalan-J 整数截断可导致任意代码执行

谷歌推出开源软件漏洞奖励计划，提振软件供应链安全

黑客攻陷Okta发动供应链攻击，影响130多家组织机构

Linux和谷歌联合推出安全开源奖励计划，最高奖励1万美元或更多

开源web应用中存在三个XSS漏洞，可导致系统遭攻陷

开源软件 LibreOffice 修复多个与宏、密码等相关的漏洞

Juniper Networks修复200多个第三方组件漏洞

美国国土安全部：Log4j 漏洞的影响将持续十年或更久

美国国土安全部：Log4j 漏洞的影响将持续十年或更久

PyPI 仓库中的恶意Python包将被盗AWS密钥发送至不安全的站点

开源项目 Parse Server 出现严重漏洞，影响苹果 Game Center

奇安信开源软件供应链安全技术应用方案获2022数博会“新技术”奖

更好的 DevSecOps，更安全的应用

他坦白：只是为了研究才劫持流行库的，你信吗？

热门PyPI 包 “ctx” 和 PHP库 “phpass” 长时间未更新遭劫持，用于窃取AWS密钥

从美行政令看软件供应链安全标准体系的构建

研究员发现针对 GitLab CI 管道的供应链攻击

五眼联盟：管理服务提供商遭受的供应链攻击不断增多

趁机买走热门包唯一维护人员的邮件域名，我差点发动npm 软件供应链攻击

RubyGems 包管理器中存在严重的 Gems 接管漏洞

《软件供应商手册：SBOM的生成和提供》解读

和GitHub 打官司？热门包 SheetJS出走npmjs.com转向自有CDN

不满当免费劳力，NPM 热门库 “colors” 和 “faker” 的作者设无限循环

NPM流行包再起波澜：维护人员对俄罗斯用户发特定消息，谁来保证开源可信？

NPM逻辑缺陷可用于分发恶意包，触发供应链攻击

攻击者“完全自动化”发动NPM供应链攻击

200多个恶意NPM程序包针对Azure 开发人员，发动供应链攻击

哪些NPM仓库更易遭供应链攻击？研究员给出了预测指标

NPM 修复两个严重漏洞但无法确认是否已遭在野利用，可触发开源软件供应链攻击

热门NPM库 “coa” 和“rc” 接连遭劫持，影响全球的 React 管道

速修复！热门npm 库 netmask 被曝严重的软件供应链漏洞，已存在9年

25个恶意JavaScript 库通过NPM官方包仓库分发

Pwn2Own大赛回顾：利用开源服务中的严重漏洞，攻陷西部数据My Cloud PR4100

开源网站内容管理系统Micorweber存在XSS漏洞

热门开源后端软件Parse Server中存在严重的 RCE ，CVSS评分10分

开源组件11年未更新，严重漏洞使数百万安卓按设备易遭远程监控

开源工具 PrivateBin 修复XSS 漏洞

奇安信开源组件安全治理解决方案——开源卫士