Scorecards

悪意のある貢献者や侵害されたアカウントによって、コードに潜在的なバックドアが紛れ込む可能性があります。こうした攻撃は、コードレビューによって軽減できます。新しい Branch-Protection チェックを使うと、プロジェクトでコードをコミットする前に別のデベロッパーによるコードレビューを必須にすることができます。GitHub API の制限のため、現在、このチェックはリポジトリ管理者のみが実行できます。サードパーティ リポジトリの場合は、これよりも情報が少ない Code-Review チェックを代わりに利用できます。

デベロッパーやピアレビューの最大限の努力にもかかわらず、脆弱なコードがソース コントロールに紛れ込み、検出されないままになることがあります。そのため、継続的にファジングや静的コード解析をし、開発ライフサイクルの早い段階でバグを発見できることが重要です。そこで、CI/CD システムの一部として、プロジェクトがファジングや SAST ツールを使っているかどうかを検出するチェックを追加しました。

GitHub プロジェクトで一般的に使われる CI/CD ソリューションは、GitHub Actions です。このアクション ワークフローの危険なところは、信頼できないユーザー入力を扱ってしまう可能性があることです。つまり、攻撃者は悪意のある pull リクエストを作成することで、特権 GitHub トークンにアクセスし、それを使ってレビューを経ずに悪意のあるコードをリポジトリにプッシュすることができます。Scorecard の Token-Permissions 防止チェックは、このリスクを緩和するため、GitHub トークンをデフォルトで読み取り専用にし、GitHub ワークフローが最小権限の原則に従っていることを検証します。

どんなソフトウェアでも、依存関係が弱いほど安全です。これは当たり前に思えるかもしれませんが、依存関係を知るための第一歩は、依存関係を宣言し、その依存関係にも依存性を宣言させることです。この起源情報があれば、ソフトウェアのリスクを評価し、そのリスクを低減できます。残念ながら、よく目にするアンチパターンがいくつかあり、それによってこの起源の原則が崩れています。1 つ目のアンチパターンは、バイナリのチェックインです。プロジェクト内のバイナリ コンテンツを簡単に検証またはチェックする方法はないからです。Scorecards は、これを評価する Binary-Artifacts チェックを提供します。

もう 1 つのアンチパターンは、スクリプトで curl | bash を使って動的に依存関係をプルすることです。暗号化ハッシュを使うと、依存関係を既知の値に固定することができます。その値が変更されると、ビルドシステムはそれを検知してビルドを拒否します。依存関係がある場合、依存関係の固定は便利です。これはコンパイル時だけでなく、Dockerfiles や CI/CD ワークフローなどにも当てはまります。Scorecards は、Frozen-Deps チェックによってこのアンチパターンをチェックします。このチェックは、最近の CodeCov 攻撃のような悪意のある依存関係攻撃を軽減する際に役立ちます。

ハッシュを固定したとしても、依存関係で脆弱性の修正が発生すると、ハッシュを更新する必要があります。dependabot や renovatebot といったツールは、ハッシュの確認と更新をする機会を与えてくれます。Scorecards の Automated-Dependency-Update チェックは、デベロッパーがそのようなツールを使って依存関係を更新していることを検証します。

重要なのは、依存関係として取り込む前に、そのプロジェクトの脆弱性を把握することです。Scorecards の新しい Vulnerabilities チェックでは、脆弱性アラート システムをサブスクライブしなくても、この情報が提供されます。

影響力の拡大

現時点で、Scorecards プロジェクトは、50,000 を超えるオープンソース プロジェクトのセキュリティ基準を評価する規模になっています。このプロジェクトを拡大するため、アーキテクチャの大幅な再設計をし、水平スケーラビリティと高いスループットを実現する PubSub モデルを採用しました。この全自動ツールでは、定期的に重要なオープンソース プロジェクトを評価し、毎週更新されるパブリック BigQuery データセットを通して Scorecards チェック情報を公開しています。

インターネットはどの程度基準を満たしているか

対象プロジェクトの Scorecards データは、最近発表された Google Open Source Insights プロジェクトに含まれており、OpenSSF Security Metrics プロジェクトでも公開されています。これらのサイトのデータからは、Kubernetes などの広く使われているパッケージであっても、埋める必要がある重要なセキュリティ ギャップがまだ存在することがわかります。

また、Google のデータ分析・視覚化ツールの 1 つである Google データポータルで Scorecards データを分析してみました。次の図は、実行されたチェックと、50,000 個のリポジトリに対する合格 / 失格の結果の内訳です。

ご覧のように、これらの主要プロジェクトのセキュリティを向上するには、たくさんの作業が必要です。多くのプロジェクトには、継続的なファジングが行われていない、脆弱性報告のセキュリティ ポリシーが定義されていない、依存関係が固定されていないなどの問題があり、これらは一般的な問題のごく一部にすぎません。業界が一丸となってこういった幅広いセキュリティ リスクへの認識を高め、すべての人に利益をもたらすような改善をする必要があります。

実際の Scorecards

いくつかの大規模プロジェクトが Scorecards を採用し、その経験について継続的にフィードバックを行っています。以下に、実際に Scorecards を使った例をご紹介します。