この記事は Google Open Source Security チーム、Kim Lewandowski、Azeem Shaikh、Laurent Simon による Google Online Security Blog の記事 "Measuring Security Risks in Open Source Software: Scorecards Launches V2" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
オープンソース プロジェクトの「リスクスコア」を生成する自動セキュリティ ツール、Scorecards プロジェクトの貢献者の皆さんは、昨秋のリリース以降、たくさんのことを成し遂げています。この度は、Open Source Security Foundationコミュニティとともに、Scorecards v2についてお知らせします。新しいセキュリティ チェックを追加して評価対象のプロジェクト数を拡大し、そのデータを簡単に分析できるようにしています。
現在、多くのソフトウェアがオープンソース プロジェクトを利用しています。そのため、依存関係が安全かどうかを簡単に判断する方法が必要です。Scorecards は、プロジェクトのサプライ チェーンを管理する際に、変化を続けるパッケージを継続的に評価するために必要な煩雑さや手作業を軽減するために役立ちます。ユーザーは、依存関係がもたらすリスクを自動的に評価し、そのデータを使って情報に基づいてリスクを受け入れるかどうかを判断したり、代替のソリューションを評価したり、メンテナンス担当者と協力して改善したりできます。
![]()
分析対象となるすべてのプロジェクトの最新データをエクスポートしたい方は、こちらの手順をご覧ください。
また、Google のデータ分析・視覚化ツールの 1 つである Google データポータルで Scorecards データを分析してみました。次の図は、実行されたチェックと、50,000 個のリポジトリに対する合格 / 失格の結果の内訳です。
ご覧のように、これらの主要プロジェクトのセキュリティを向上するには、たくさんの作業が必要です。多くのプロジェクトには、継続的なファジングが行われていない、脆弱性報告のセキュリティ ポリシーが定義されていない、依存関係が固定されていないなどの問題があり、これらは一般的な問題のごく一部にすぎません。業界が一丸となってこういった幅広いセキュリティ リスクへの認識を高め、すべての人に利益をもたらすような改善をする必要があります。
Scorecards
Scorecards 自体のスコアも改善しました。たとえば、CodeCovスタイルの攻撃を防ぐため、依存関係をハッシュで固定するようにしました（Docker 依存関係、ワークフロー依存関係など）。また、この推奨テンプレートに基づいてセキュリティ ポリシーも含めました。
この楽しい作業に参加したい方は、初めての方向けの Issueをご確認ください。
特定のプロジェクトで Scorecards を実行する際にサポートを受けたい方は、GitHub で pull リクエストを送り、こちらにプロジェクトを追加してください。
最後になりますが、私たちにはさまざまなアイデアがあり、追加したいチェックもさらにたくさんありますが、ぜひ皆さんの意見を聞きたいと思っています。Scorecards の次のバージョンで期待するチェックをお知らせください。
Reviewed by Eiji Kitamura - Developer Relations Team![]()
オープンソース プロジェクトの「リスクスコア」を生成する自動セキュリティ ツール、Scorecards プロジェクトの貢献者の皆さんは、昨秋のリリース以降、たくさんのことを成し遂げています。この度は、Open Source Security Foundationコミュニティとともに、Scorecards v2についてお知らせします。新しいセキュリティ チェックを追加して評価対象のプロジェクト数を拡大し、そのデータを簡単に分析できるようにしています。
現在、多くのソフトウェアがオープンソース プロジェクトを利用しています。そのため、依存関係が安全かどうかを簡単に判断する方法が必要です。Scorecards は、プロジェクトのサプライ チェーンを管理する際に、変化を続けるパッケージを継続的に評価するために必要な煩雑さや手作業を軽減するために役立ちます。ユーザーは、依存関係がもたらすリスクを自動的に評価し、そのデータを使って情報に基づいてリスクを受け入れるかどうかを判断したり、代替のソリューションを評価したり、メンテナンス担当者と協力して改善したりできます。
リスクの特定
昨秋より、Scorecards のカバレッジは拡大しています。Google が今年提唱した Know、Prevent、Fix フレームワークに従って優先順位付けをし、いくつかの新しいチェックを追加しました。悪意のある貢献者
悪意のある貢献者や侵害されたアカウントによって、コードに潜在的なバックドアが紛れ込む可能性があります。こうした攻撃は、コードレビューによって軽減できます。新しい Branch-Protectionチェックを使うと、プロジェクトでコードをコミットする前に別のデベロッパーによるコードレビューを必須にすることができます。GitHub API の制限のため、現在、このチェックはリポジトリ管理者のみが実行できます。サードパーティ リポジトリの場合は、これよりも情報が少ない Code-Reviewチェックを代わりに利用できます。
悪意のある貢献者や侵害されたアカウントによって、コードに潜在的なバックドアが紛れ込む可能性があります。こうした攻撃は、コードレビューによって軽減できます。新しい Branch-Protectionチェックを使うと、プロジェクトでコードをコミットする前に別のデベロッパーによるコードレビューを必須にすることができます。GitHub API の制限のため、現在、このチェックはリポジトリ管理者のみが実行できます。サードパーティ リポジトリの場合は、これよりも情報が少ない Code-Reviewチェックを代わりに利用できます。
脆弱なコード
デベロッパーやピアレビューの最大限の努力にもかかわらず、脆弱なコードがソース コントロールに紛れ込み、検出されないままになることがあります。そのため、継続的にファジングや静的コード解析をし、開発ライフサイクルの早い段階でバグを発見できることが重要です。そこで、CI/CD システムの一部として、プロジェクトがファジングや SASTツールを使っているかどうかを検出するチェックを追加しました。
デベロッパーやピアレビューの最大限の努力にもかかわらず、脆弱なコードがソース コントロールに紛れ込み、検出されないままになることがあります。そのため、継続的にファジングや静的コード解析をし、開発ライフサイクルの早い段階でバグを発見できることが重要です。そこで、CI/CD システムの一部として、プロジェクトがファジングや SASTツールを使っているかどうかを検出するチェックを追加しました。
ビルドシステムの侵害
GitHub プロジェクトで一般的に使われる CI/CD ソリューションは、GitHub Actionsです。このアクション ワークフローの危険なところは、信頼できないユーザー入力を扱ってしまう可能性があることです。つまり、攻撃者は悪意のある pull リクエストを作成することで、特権 GitHub トークンにアクセスし、それを使ってレビューを経ずに悪意のあるコードをリポジトリにプッシュすることができます。Scorecard の Token-Permissions防止チェックは、このリスクを緩和するため、GitHub トークンをデフォルトで読み取り専用にし、GitHub ワークフローが最小権限の原則に従っていることを検証します。
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チェックでは、脆弱性アラート システムをサブスクライブしなくても、この情報が提供されます。
どんなソフトウェアでも、依存関係が弱いほど安全です。これは当たり前に思えるかもしれませんが、依存関係を知るための第一歩は、依存関係を宣言し、その依存関係にも依存性を宣言させることです。この起源情報があれば、ソフトウェアのリスクを評価し、そのリスクを低減できます。残念ながら、よく目にするアンチパターンがいくつかあり、それによってこの起源の原則が崩れています。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 チェック情報を公開しています。
このデータは、bq コマンドライン ツールで取得できます。次の例は、Kubernetes プロジェクトのデータをエクスポートする方法を示しています。リポジトリの URL を置き換えると、別のプロジェクトのデータをエクスポートできます。
分析対象となるすべてのプロジェクトの最新データをエクスポートしたい方は、こちらの手順をご覧ください。
インターネットはどの程度基準を満たしているか
対象プロジェクトの Scorecards データは、最近発表された Google Open Source Insights プロジェクトに含まれており、OpenSSF Security Metrics プロジェクトでも公開されています。これらのサイトのデータからは、Kubernetes などの広く使われているパッケージであっても、埋める必要がある重要なセキュリティ ギャップがまだ存在することがわかります。また、Google のデータ分析・視覚化ツールの 1 つである Google データポータルで Scorecards データを分析してみました。次の図は、実行されたチェックと、50,000 個のリポジトリに対する合格 / 失格の結果の内訳です。
ご覧のように、これらの主要プロジェクトのセキュリティを向上するには、たくさんの作業が必要です。多くのプロジェクトには、継続的なファジングが行われていない、脆弱性報告のセキュリティ ポリシーが定義されていない、依存関係が固定されていないなどの問題があり、これらは一般的な問題のごく一部にすぎません。業界が一丸となってこういった幅広いセキュリティ リスクへの認識を高め、すべての人に利益をもたらすような改善をする必要があります。
実際の Scorecards
いくつかの大規模プロジェクトが Scorecards を採用し、その経験について継続的にフィードバックを行っています。以下に、実際に Scorecards を使った例をご紹介します。Envoy
以前、Envoy のメンテナンス担当者がプロジェクトに Scorecards を採用し、それを新しい依存関係を導入する際のポリシーに組み込んだ過程についてお話ししました。それ以降、新しい依存関係を Envoy に導入する pull リクエストは、依存関係のメンテナンス担当者からの承認が必要になりました。担当者は Scorecards を使い、一連の基準に照らして依存関係を評価します。
それに加えて、Envoy は独自の Scorecards 評価に基づいて専用のセキュリティ健全性指標を改善する作業にも着手し、現在は C++ の依存関係を固定し、Python の依存関係には pip ハッシュを要求しています。さらに、継続的インテグレーション フローで Github のアクションも固定しています。
以前、Envoy は依存関係についての Scorecards データを CSV として出力するツールを作成し、その結果から表を作成していました。
以前、Envoy のメンテナンス担当者がプロジェクトに Scorecards を採用し、それを新しい依存関係を導入する際のポリシーに組み込んだ過程についてお話ししました。それ以降、新しい依存関係を Envoy に導入する pull リクエストは、依存関係のメンテナンス担当者からの承認が必要になりました。担当者は Scorecards を使い、一連の基準に照らして依存関係を評価します。
それに加えて、Envoy は独自の Scorecards 評価に基づいて専用のセキュリティ健全性指標を改善する作業にも着手し、現在は C++ の依存関係を固定し、Python の依存関係には pip ハッシュを要求しています。さらに、継続的インテグレーション フローで Github のアクションも固定しています。
以前、Envoy は依存関係についての Scorecards データを CSV として出力するツールを作成し、その結果から表を作成していました。
現在はプロジェクトのデータが増えましたが、Envoy では依存関係についての最新の Scorecard 情報を自動生成し、次のようなドキュメントで公開できるようになっています。
Scorecards
Scorecards 自体のスコアも改善しました。たとえば、CodeCovスタイルの攻撃を防ぐため、依存関係をハッシュで固定するようにしました（Docker 依存関係、ワークフロー依存関係など）。また、この推奨テンプレートに基づいてセキュリティ ポリシーも含めました。
参加する
Scorecards コミュニティが拡大を続けるのを楽しみにしています。現在、このプロジェクトは 23名のデベロッパーの貢献を受けています。Scorecards の新機能やスケーリングの作業を行ってくださった Azeem、Naveen、Laurent、Asra、Chrisに感謝します。この楽しい作業に参加したい方は、初めての方向けの Issueをご確認ください。
特定のプロジェクトで Scorecards を実行する際にサポートを受けたい方は、GitHub で pull リクエストを送り、こちらにプロジェクトを追加してください。
最後になりますが、私たちにはさまざまなアイデアがあり、追加したいチェックもさらにたくさんありますが、ぜひ皆さんの意見を聞きたいと思っています。Scorecards の次のバージョンで期待するチェックをお知らせください。
次のステップ
次に示すのは、私たちが特に期待している大きな拡張です。- Scorecards バッジ - コンプライアンスを証明する GitHub バッジ
- CI/CD および GitHub コードスキャン結果との統合
- Allstar プロジェクトとの統合 - セキュリティ ポリシーを強制するための GitHub アプリ
Reviewed by Eiji Kitamura - Developer Relations Team