Google发布新的开源安全检查工具：Scorecards

导读：这篇文章主要介绍了谷歌开源 Scorecards，为开源项目安全性“打分”。

一个问题，GitHub上有多少安全问题的开源软件？而现在谷歌可以帮助开评估某款开源软件到底安不安全。

一些天真的人们可能认为自己并没有使用开源软件，其实错了，每个人都在用，或多或少而已。

根据Synopsys 网络安全研究中心(CyRC) 2021 年发布的“开源安全与风险分析”(OSSRA) 报告，95% 的商业软件都含有开源软件的贡献。根据 CyRC 的统计，大多数程序包含过时或不安全的代码。但是如果不深入研究代码，如何判断哪些库和组件是安全的？Google和开源安全基金会 (OSSF)提供了一个快速而简单的答案：OpenSSF Scorecards —— 译为安全记分卡。

这些“记分卡”是基于一组自动式的通过/失败检测数据，能够快速查看多个开源软件项目，它是一个自动化的安全工具，生成一个“风险评分”的开源报告。

这样公司或组织就可以动用相关流程来检查系统中的开源依赖是否存在安全性问题。

现实情况下，即使是拥有众多资源的Google，检测安全问题的过程也需要手动，乏味且容易出错的。大部分的开发者或项目都受到资源的限制。很多情况下，系统安全性检测都在交付工作列表中的较低优先级，这导致很多项目未遵守安全最佳实践而受到攻击。

ScoreCards项目让此项工作变得轻松，让系统安全更易实现。

如今Scorecards刚刚发布了v2.0，又增强了新功能，包括新的安全检查、扩大被评测的项目数量，使这些数据更容易访问和分析。我们将Scorecards2的功能列表如下：

1）识别风险

Scorecards的覆盖领域有所扩大，Google将它已经添加到自己的Know、Prevent、Fix框架中作为重要之安全检查。

2）发现恶意代码作者

恶意作者，想盗取帐户或其它别有有心的贡献者，会在代码中混入后门程序。而代码审查则可以减轻此类之攻击。使用新的分支检查功能，可以要求某位开发者在提交代码之前接受别人折代码审查。目前受GitHub API的功能限制，该项审查只能由存储库的管理员执行。

3）发现易受攻击代码

即使代码审查/评审花了很大努力，但仍会有不好的代码进入存储库，因此要启用模糊测试和静态代码测试，即在开发生命周期越早发现错误越好，此部分应该成为持续集成/部署的一部分。

4）系统构建防护

在GitHub中，常见的持续集成与持续交付（CI/CD）解决方案是GitHub Actions（https://github.com/features/actions），GitHub工作流的风险是可以接受不受信任的用户输入。

恶意攻击者可以制恶意造拉取请求以获得特权的GitHub Token(令牌)，从而将恶意代码推送到存储库而无需审查。为降低此风险，Scorecards提供了Token权限检查功能，能够设置为只读来执行工作流，验证GitHub是否遵循最小权限的原则。

5) 不良依赖

系统的安全性取决于其最弱的依赖。有一些依赖使用了二进制文件，这让很多工具和人力无法检查其中的内容。尤其有一些文件以驱动程序的身份嵌入到软件系统中。

继续使用专有驱动程序，这可能无法避免恶意软件。基于如此，Scorecards 提供了一个 Binary-Artifacts检查来测试二进制文件的恶意行为。

另一个反模式是在脚本中使用 curl 或 bash，它动态地拉取依赖项，加密哈希让开发者将依赖项固定到一个已知值。如果这个值发生变化，构建系统会检测到它并拒绝构建，固定依赖项在我们有依赖项的任何地方都很有用：不仅在编译期间，而且在 Docker文件、CI/CD 工作流等中。Scorecards使用Frozen-Deps检查来检查这些反模式。此检测有助于缓解恶意依赖项攻击，例如最近的CodeCov攻击等。

即使使用散列固定，当依赖项修补漏洞时，散列也需要不时更新。Dependabot或renovatebot等工具可以查看和更新哈希值。Scorecards Automated-Dependency-Update检查验证开发人员是否依赖此类工具来更新其依赖项。

在将其用作依赖项之前了解项目中的漏洞非常重要。Scorecards可以通过新的漏洞检查提供此信息，而无需订阅漏洞警报系统。

以下是 Scorecards 2.0 项目的功能亮点： 

Scorecards 已经评估了超过 50,000 个开源项目的安全性。为了扩展这个项目，Scorecards v2.0的架构已经过大规模重新设计。它现在使用Pub/Sub模型，具有水平可扩展性和更高的吞吐量。这个完全自动化的工具会定期评估关键的开源项目，并通过每周更新的公共 BigQuery 数据集公开Scorecards检查的信息。

要访问此数据，可以使用bq 命令行工具。以下示例展示了如何为 Kubernetes 项目导出数据，你可以根据自己的目标，将 Kubernetes repo url 替换为自己要检查的程序 URL：

$bq query --nouse_legacy_sql 'SELECT Repo, Date, Checks FROM openssf.scorecardcron.scorecard_latest WHERE Repo="github.com/kubernetes/kubernetes"'

还可以查看所有Scorecards分析项目的最新数据，此数据也可在新的Google Open Source Insights项目和OpenSSF Security Metrics 项目中获取得到。原始数据也可以通过数据分析和可视化工具（例如Google Data Studio ）进行检查，它使用 CSV 格式的数据，可以使用任何你喜欢的数据分析和可视化工具来检查它。 

从这些数据中可以清楚地看到，即使在Kubernetes 等广泛应用的软件包中，仍有许多安全漏洞。比如很多项目没有定义用于报告漏洞的安全策略，也没有固定依赖项。

根据Google的说法，任何关心安全的人都说：“作为一个行业，我们都需要团结起来，提高人们对这些普遍存在的安全风险的认识，在每个人的改进中获益。”

Scorecards v2 项目现在有 23 名开发人员，欢迎更多人加入进来。如果各位想加入其中，可通过该项目的GitHub访问新手加入等问题。Google 的开发人员说：“我们还有很多想法想要添加到检查选项中，但我们希望听到更多用户的意见，希望在下一版本的Scorecards中看到更多类型检查.”

关于Scorecards的未来版本，该团队计划添加：

1）Scorecards徽章- 展示代码合规的 GitHub 徽章

2）与 CI/CD 和 GitHub 代码扫描结果集成

3）与 Allstar 项目集成- 用于执行安全策略的 GitHub 应用程序

Scorecards 项目可以使开发者的工作更加可靠，它承诺不仅可以提高程序的安全性，还可以更多提高其包含的程序代码的安全性。

各位怎么看？欢迎文底评论～

来源：21CTO

相关阅读：