开源安全如何落地?OpenSSF发布多份生命周期安全指南

admin 2022年9月19日22:47:42安全开发评论0 views3309字阅读11分1秒阅读模式

关注我们

带你读懂网络安全

开源安全如何落地?OpenSSF发布多份生命周期安全指南


OpenSSF发布4项开源软件安全指南,给出了开源软件使用、开发、漏洞报告、包管理等生命周期安全最佳实践。


前情回顾·开源软件安全治理
本文作者:奇安信代码安全事业部 董国伟
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文件只列出了直接依赖,未列出传递依赖
依赖项可以通过包名、URLrepo等来定义;可以为每个依赖项定义额外约束
可重复安装
保证每次安装包时使用完全相同的依赖项副本
提供依赖项(在存储库中保存所有直接依赖项和传递依赖项的本地副本);或使用锁文件(通过加密哈希实现哈希固定[pinning],将各依赖项的预期哈希告知包管理器,每次安装时,包管理器验证依赖项的哈希值是否相同)
维护
定期更新依赖关系,特别在新漏洞被披露和修复时
使用工具管理依赖项;及时了解依赖项中存在的漏洞;定期运行NPM prune并提交合并请求,以删除依赖
私有包方面的最佳实践针对依赖混淆攻击,该类攻击大多发生在项目依赖于内部registry的私有包时,指南建议使用作用域(Scopes)来保障NPM能够获取正确的依赖。
具体而言,对于公共NPM registry,因其上受作用域限定的包只能由相关的用户或组织发布,指南建议,该作用域内的包可被设为私有、作用域名可被链接到给定的registry;对于私有registry,指南建议,仅使用支持作用域的私有registry、私有包不可变、关注构建失败的情况并修复。


推荐阅读




文章来源:安全内参社区


点击下方卡片关注我们,
带你一起读懂网络安全 ↓


原文始发于微信公众号(安全内参):开源安全如何落地?OpenSSF发布多份生命周期安全指南

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年9月19日22:47:42
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  开源安全如何落地?OpenSSF发布多份生命周期安全指南 http://cn-sec.com/archives/1305535.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: