开源专案软件安全扫描工具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等恶意相依项目攻击。