前情回顾·开源软件安全治理

本文作者：奇安信代码安全事业部 董国伟

8月底至9月上旬，OpenSSF接连发布了4项有关开源软件安全的指南，包括《评估开源软件的简明指南》、《开发更安全软件的简明指南》、《安全研究人员与开源软件项目协同漏洞披露(CVD)指南》、《NPM最佳实践指南》，给出了开源软件使用、开发、漏洞报告、包管理等方面的安全最佳实践。

本文介绍了这些指南的主要核心内容。

使用环节：《评估开源软件的简明指南》

软件开发人员在使用开源软件依赖项或工具之前，基于安全性和可持续性的考虑，应该对其潜在的依赖关系进行评估，以确定候选，该指南即提供此方面的指导。

指南共包括9个方面：(1) 是否尽量减少依赖的数量(使用现有的依赖关系，不再增加)；(2) 是否确保版本来源安全(非个人发布或攻击者控制的版本)；(3) 是否有持续的维护；(4) 是否有其开发者增强安全性的证明；(5) 是否易于进行安全配置；(6) 是否有关于如何报告漏洞的说明；(7) 是否有重要用途；(8) 是否考虑了许可证的影响；(9) 对其代码的评价。

没有维护的开源软件是一种风险。对于开源软件持续维护的评估，指南列出了近期重大活动、最后一次发布时间、维护者的数量等5方面指标。奇安信代码安全实验室于2021和2022年发布的两份《中国软件供应链安全分析报告》也关注到了这一领域，通过对开源生态中一年未更新版本、一年更新超100次的开源软件数量，以及关键基础开源软件的维护状况进行统计，发现开源软件维护方面的现状不容乐观。

开发者增强安全性的证明方面，指南列出了11项评估指标，包括是否具备OpenSSF最佳实践徽章、是否检查了开源软件的OpenSSF记分卡值和已知漏洞、依赖项是否是最新的、是否及时修复了bug特别是安全bug、是否使用SAFECode《软件保障评价指导原则》、对于OpenChain《安全保障参考指南》的符合性如何等。

对开源软件代码的评价方面，指南列举的指标包括开发人员使用安全的开发方法、静态分析工具发现的首要问题等6项。

开发环节：《开发更安全软件的简明指南》

该指南是针对所有软件开发人员在软件开发、构建和发布时的简明指南，共25条建议，主要覆盖4个方面的内容。

依赖项安全性方面，建议：在选择软件作为直接依赖项之前对其进行评估(基于《评估开源软件的简明指南》)，只在需要时添加它，并再次检查它的名称，以防止误植域名攻击；使用包管理器自动管理依赖项并支持快速更新；使用软件组成分析(SCA)工具等持续监测软件直接和间接依赖项中的已知漏洞，快速更新易受攻击的依赖项；更新依赖项至最新。

漏洞分析和报告方面，建议：在CI管道中使用多种工具的组合来检测漏洞；实现自动化测试；实施第三方安全代码审查/审计；重点记录如何报告漏洞并为其做好准备(参考《安全研究人员与开源软件项目协同漏洞披露(CVD)的指南》)；将项目中的漏洞通知社区。

增强完整性、透明性和维护水平方面，建议：使用标准工具和签名格式为项目的重要发行版本签名；提高SLSA级别，以加强构建和分发过程的完整性从而抵御攻击；发布并使用软件物料清单(SBOM)，以帮助用户验证资产、识别已知的漏洞和潜在的法律问题；有清晰的管理，并努力增加积极的、值得信赖的维护者；确保特权开发人员使用多因子身份验证。

已有评估标准和方法实施方面，建议：为开源项目获得一个“OpenSSF最佳实践徽章”；提高项目的“OpenSSF记分卡”得分(如果是GitHub上的OSS)；采用了CNCF《软件供应链最佳实践指南》；实施了ASVS并遵循相关内容；采用了SAFECode《安全软件开发基本实践》。

漏洞披露环节：《安全研究人员与开源软件项目协同漏洞披露(CVD)指南》

该指南是由OpenSSF的漏洞披露工作组和个人贡献者共同完成的，旨在将安全缺陷负责任地报告给软件维护人员，以评估并修复它们，同时通知下游消费者。

该指南是一组能够为漏洞发现者在CVD之前、期间和之后提供高层次选择视角的指导方针。

在披露之前，指南建议：(1) 了解项目处理漏洞的方式，即安全策略，包括电子邮件、问题跟踪器等漏洞报告途径，漏洞报告奖励和保密条款等；(2) 编写便于理解和披露的报告；(3) 提供有用的信息，包含足够的漏洞细节，如发现的问题、易受攻击的版本、发现漏洞的步骤、源码中易受攻击的行号、被利用的危害、建议的补救措施等。

披露时，指南建议：(1) 尽早声明关于漏洞披露的目标和期望，以便各方了解约定的边界；(2) 披露选择项，如下表所示，建议每一项应由安全研究人员和项目共同完成。

披露选项

描述

示例场景

OpenSSF首选

不披露

发现者自己保留信息，不与维护者、公众共享或私下与他人共享

公司情况

协同的(Coordinated)

从漏洞发现者收集信息，协同利益相关者之间的信息共享，并向各利益相关者披露软件漏洞的存在及其缓解措施，包括公众

√

限制的(Limited)

公开披露漏洞的部分信息，但私自保留部分信息(如不发布PoC)

保密协议(NDA)、可信合作伙伴等

√

完全的(Full)

公布漏洞的全部细节(研究、结果和某些情况下的PoC)

在第三方平台上完全披露

√

0day

不为钱/完全披露：研究人员有时不希望以此获利，并完全披露漏洞和PoC，这使得产品受到影响，直至漏洞被修复

出售：一般来说是盈利性的，通常意味着研究人员为了赏金而售卖未披露的漏洞

此外，指南还为解决CVD的常见挑战，如项目维护者不认为报告的是安全问题等提供了建议。

包管理环节：《NPM最佳实践指南》

根据奇安信代码安全实验室《2022中国软件供应链安全分析报告》公布的数据，截止2021年底，NPM中开源项目的数量达1892984个，占主流开源软件包生态系统开源项目总数的43.1%，NPM以绝对优势成为开源项目数量最多的开源包生态系统。

该指南旨在成为一份介绍在使用NPM的包管理器时安全供应链最佳实践的全面文档，是对官方NPM文档的补充。指南包括CI配置、依赖管理、发布和私有包4个方面的最佳实践内容，其中依赖管理是主要部分，依赖管理的核心内容如下表所示。

方面

应解决问题

具体方法或建议

引入

研究依赖项的来源、可信性和安全性

关注误植域名攻击；根据文档确定项目的包名；了解传递依赖的安全情况；了解项目依赖中的存在漏洞的情况

声明

Manifest文件只列出了直接依赖，未列出传递依赖

依赖项可以通过包名、URL、repo等来定义；可以为每个依赖项定义额外约束

可重复安装

保证每次安装包时使用完全相同的依赖项副本

提供依赖项(在存储库中保存所有直接依赖项和传递依赖项的本地副本)；或使用锁文件(通过加密哈希实现哈希固定[pinning]，将各依赖项的预期哈希告知包管理器，每次安装时，包管理器验证依赖项的哈希值是否相同)

维护

定期更新依赖关系，特别在新漏洞被披露和修复时

使用工具管理依赖项；及时了解依赖项中存在的漏洞；定期运行NPM prune并提交合并请求，以删除依赖

私有包方面的最佳实践针对依赖混淆攻击，该类攻击大多发生在项目依赖于内部registry的私有包时，指南建议使用作用域(Scopes)来保障NPM能够获取正确的依赖。

具体而言，对于公共NPM registry，因其上受作用域限定的包只能由相关的用户或组织发布，指南建议，该作用域内的包可被设为私有、作用域名可被链接到给定的registry；对于私有registry，指南建议，仅使用支持作用域的私有registry、私有包不可变、关注构建失败的情况并修复。

声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。