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

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

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。