去年所发布的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等恶意相依项目攻击。