7.10 开放源码安全基金会评分卡
每个人都知道Marc Andreessen在十多年前提出的“软件正在吞噬世界”(https://a16z.com/2011/08/20/why-softw-is-eating-the-world)。软件几乎为现代社会的方方面面提供了动力,无论是个人还是职业,它对现代经济甚至国家安全都至关重要——这是毋庸置疑的。考虑到这一现实,也可以说OSS已经吞噬了软件行业。据Linux基金会等组织估计,自由和开源软件(FOSS)构成了任何现代软件解决方案或产品的70%到90% (www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-opensource-software-application-libraries-the-world-depends-on)。
现代软件不仅主要由OSS组件组成,而且IT领导者也更有可能与那些也为OSS社区做出贡献的供应商合作(www.redhat.com/en/enterprise-open-source-report/2022)。 大量使用OSS的原因有很多,比如灵活性、成本节约、通过社区支持的项目进行的创新,以及通过审查代码和在代码上拥有更多“眼球”的能力而获得的更好的安全性,特别是对于大型OSS项目。也就是说,OSS并非没有自己的担忧,包括受影响代码的漏洞和cve。CVE是MITRE的一个项目,致力于“识别、定义和编目公开披露的网络安全漏洞”(cve.mitre.org)。
然而,正如CNCF软件供应链最佳实践白皮书所指出的那样,cve是一个“跟踪度量”,这意味着cve是已公开披露的漏洞的枚举。它们也是与软件相关的潜在风险和漏洞之一。出于这个原因,建议组织使用其他方法来评估他们正在使用的特定OSS项目的安全状态,其中最值得注意的是OpenSSF的Scorecard项目(http://openssf.org),我们将在下面讨论它。
开源项目的安全记分卡
在2020年底,OpenSSF宣布了他们的项目“记分卡”,该项目旨在为OSS项目自动生成安全评分,以帮助消费者和组织对其OSS消费做出风险知情的决策。
组织正在大量使用OSS依赖项,但是确定消耗这些依赖项的风险在很大程度上仍然是一项手工活动,特别是在跨软件生态系统的规模上。Scorecard项目试图使用他们的自动启发式和安全检查来减轻一些负担,评分范围为0-10(参见图7.13)。
| 名称 | 描述 | 风险等级 |
|---|---|---|
| 二元属性 | 项目是否不包含签入的二进制文件? | 高 |
| 分支保护 | 项目是否使用分支保护? | 高 |
| CI测试 | 项目是否在CI中运行测试,例如GitHubActions,Prow? | 低 |
| CL-最佳实践 | 项目是否有CI最佳实践徽章? | 低 |
| 代码复查 | 在合并代码之前,项目是否需要对代码进行审查? | 高 |
| 贡献者 | 项目是否有来自至少两个不同组织的贡献者? | 低 |
| 危险工作流 | 项目是否避免了GitHub Action工作流中的危险编码模式? | 被批评的 |
| 依赖更新工具 | 项目是否使用工具来帮助更新其依赖项? | 高 |
| 模糊 | 项目是否使用模糊化工具,例如OSS-Fuzz? | 中等 |
| 许可证 | 项目是否声明许可证? | 低 |
| 维护 | 项目是否维护了? | 高 |
| 固定依赖 | 项目是否声明固定依赖项? | 中等 |
| 包装 | 项目是否从CI/CD构建和发布官方软件包,例如GitHub发布? | 中等 |
| SAST | 项目是否使用静态代码分析工具,例如CodeQL、LGTM、SonarCloud? | 中等 |
| 安全政策 | 项目是否包含安全策略? | 中等 |
| 符号释放 | 项目是否对发布进行加密签名? | 高 |
| Token允许 | 项目是否将GitHub工作流令牌声明为只读? | 高 |
| 漏洞 | 项目是否存在未修复的漏洞?使用OSV服务。 | 高 |
| 表7.13 |
计分卡项目的目标也不低;他们根据直接依赖关系扫描一百万个最关键的OSS项目,并每周将结果发布到公共数据集中。除了利用这个公开可用的数据集,组织还可以通过使用GitHub Actions对自己的GitHub项目运行记分卡。然后,当存储库中有变化时,GitHub Actions会运行并向这些项目的维护者提供警报。
Scorecard项目使用Critical、High、Medium和Low的评分等级,这是许多安全从业人员所熟悉的严重级别。Scorecard项目运行一个针对所有项目的标准检查列表,无论是公共项目还是您在自己的GitHub存储库中本地使用它。对于那些感兴趣的人,你可以深入了解其中一些分支是什么。它们包括基本的安全实践,例如使用分支保护和对发布进行加密签名。
为了检测未修复漏洞的存在,计分卡项目使用OSV漏洞数据库(http://osv.dev),采用OpenSSF OSV格式的开源软件分布式漏洞数据库。OSV的核心是图7.13中使用OSV模式的其他漏洞数据库的聚合,例如GitHub安全咨询和全球安全数据库等。
OSC还支持api和命令行界面(CLI)工具,用于扫描CycloneDX或SPDX格式的soms,我们在第3章“漏洞数据库和评分方法”中讨论过。
组织如何使用记分卡项目?
如前所述,组织正在广泛使用OSS。然而,对OSS消费进行尽职调查、治理和风险管理的实践仍处于起步阶段。我们看到了支持软件供应链弹性和成熟组织软件供应链安全实践的巨大推动,NIST的系统和组织网络安全供应链风险管理实践,NIST的SSDF, OpenSSF OSS安全动员计划,SLSA,以及许多其他最佳实践和指导来源已经出现。所有这些都涉及到管理组织对OSS的消耗,并确保这种消耗与组织的风险容忍度保持一致的需要。
虽然表面上听起来很简单,但是在整个健壮的OSS项目和组织正在使用的组件的生态系统中这样做的想法并不是那么微不足道。OpenSSF的Scorecard项目提供了一种自动化的方式来获取超过100万个领先的OSS项目的安全和风险洞察,并允许组织将该项目原生地用于他们自己的软件和项目。
组织可以通过CLI对他们不拥有的项目使用记分卡,也可以对npm、PyPi或RubyGems等项目使用包管理器。 Scorecard也可以作为Docker容器使用,也可以通过这个路径进行部署。
计分卡项目每两周开一次会,并且有一个活跃的Slack频道。它由来自谷歌、Datto和思科等公司的推动者领导。自成立以来,Scorecard越来越受欢迎,并被列为有超过3000名Stargazers或用户,他们已将该项目加入书签。随着组织继续推动其OSS消费治理实践的成熟,该项目将不可避免地越来越受欢迎。组织和个人贡献者也有机会参与项目,包括提交用于评分评估的检查。组织还可以定制他们对Scorecard的使用,并只运行可能与组织或行业特定安全需求相一致的特定检查。
Scorecard提供了一种关键的功能,可以自动执行一组健壮的评估标准,对于组织来说,无论是在他们正在使用的公共项目上,还是在他们想要评估的内部项目上,手动执行这些标准是不切实际的。众所周知,尽管开源软件带来了价值和创新,但大多数自由/开源软件项目人员不足,并且由无偿的志愿贡献者领导。
这并不是说组织不应该利用OSS项目,而是说他们应该对他们所使用的项目和这些项目所带来的风险有一些严格的要求。Scorecard项目以易于使用的方式完全满足了这种需求。它在评估OSS项目的安全问题时完成了所有这些工作,这些安全问题与最佳实践(如签名、SAST等)保持一致,这些都是公共和私人安全领导者已经提倡的。
No Comments