开源项目软件安全扫描工具Scorecards更新扩大检验项目

去年所发布的Scorecards项目,现在Google与开源安全基金会(Open Source Security Foundation)社群合作,发布了Scorecards v2,这个新版本添加了新的安全检查,对开源项目扩大评分,同时也简化资料取得的方式,使得这些资料更易于分析。

Scorecards项目的目标,是要能够对开源项目自动产生安全分数,协助用户选择可信且安全的解决方案。Scorecards定义了一个初始评估标准,该标准以完全自动化的方式,对开源项目产生计分卡,每个计分卡的检查都是可采取行动的,像是定义明确的安全策略、使用模糊测试、静态程序代码分析工具的持续测试覆盖率,以及程序代码审查过程等,这些安全检查回传播尔值和可信分数。

Google提到,由于目前有非常多的软件依赖开源项目,用户需要一种简单的方法,来判断他们所使用的相依项目安全性。在维护项目供应链时,Scorecards自动评估相依项目可能带来的风险,可以减少用户持续评估项目所付出的劳动与人工,并且根据这些资料,做出相对应的决策。

Scorecards项目自发布以来持续更新,Google提出了解、预防和修复框架,以覆盖更多的检查项目,这些项目包括恶意贡献者,项目存在具有恶意意图或是被盗账号的贡献者,可能在程序代码中偷藏后门,程序代码审查有助于减轻这类的攻击,而借由新的分支防护检查,开发人员可以在提交程序代码之前,验证项目是否强制执行开发人员程序代码审查。目前因为GitHub API的限制,这类检查只能由存储库管理员执行,而其他第三方存储库,则需要改用信息较少的Code-Review检查代替。

即便开发人员审查和同侪审查机制,能够最大程度避免易受攻击的程序代码,在未被发现的情况下进入程序代码控制中,因此激活持续模糊测试和静态程序代码分析显得重要,能够在开发生命周期中提早发现问题,因此Scorecards v2也会检测项目是否在CI/CD系统中,使用模糊测试和静态程序代码分析工具。

Google提到,诸如GitHub项目常用的CI/CD解决方案GitHub Actions,可能接受不受信任的用户输入,使构建系统出现漏洞,这代表攻击者可以制作恶意的拉取请求,以获得对特权GitHub权限的访问权限,使得将恶意程序代码推送到存储库的过程不需要受到审查。为了降低这种风险,Scorecards权限权限预防检查,现在会验证GitHub权限设置,项目需要默认GitHub权限为只读,以遵循最小权限原则。

错误的相依项目设置,也可能使得开源项目产生安全破口,虽然Scorecards能够评估软件来降低风险,但是反面模式(Anti-Pattern)可能破坏Scorecards的评估能力,像是签入(Checked In)无法被简单验证的二进制文件,因此现在Scorecards提供二进制构件检查来进行测试。

另一个反面模式则是使用curl|bash来动态拉取相依脚本,由于加密散列值能够确认已知的相依项目,当散列值发生变化,则构建系统便会拒绝构建。固定相依项目的机制,在编译、Dockerfiles和CI/CD工作流程,都能发挥良好的效果,而现在Scorecards会使用Frozen-Deps项目,检查这个反面模式,发现像是CodeCov等恶意相依项目攻击。

发表评论