Branch-Protection とは — OpenSSF Scorecard の見方

何を見るチェックか

Scorecard は GitHub の API を使って、リポジトリの既定ブランチ（多くは main）と、リリースに使われているブランチに保護の設定があるかを調べます。

見ているのは、たとえば次のようなものです。

満たしている項目が多いほど点が上がり、10点に近づきます。

このチェックが見ているのは「書き込みの入口が絞られているか」であって、コードの中身ではありません。

点が低いということは、主要ブランチへ変更が入る経路が広い可能性がある、という意味です。

具体的には、次のようなことが起こりうる状態です。

いわゆるサプライチェーン攻撃では、コードそのものの脆弱性ではなく、「誰でも書き込める状態」が入口になることがあります。このチェックはその入口を見ています。

ただしこれは「攻撃されている」でも「脆弱性がある」でもありません。 開発プロセス上のリスク指標です。

0点でも「保護していない」とは限りません。ここが最も誤解されます。

GitHub のブランチ保護設定は、リポジトリの管理者権限を持つトークンでないと読めません。 OpenSSF が週次で回している公開スキャンは、当然ながら他人のリポジトリの管理者権限を持っていません。そのため、実際にはきちんと保護されていても、設定が読めずに低い点になります。

このほか、次の場合も低く出ます。

つまり、この項目の低さは「悪い」ではなく「わからない」であることが多いのです。 Branch-Protection が 0 だからという理由だけで採用を見送るのは、ほぼ確実に判断を誤ります。

設定そのものは外から見られないので、結果のほうを見ます。

最近のコミットが Pull Request 経由か。 リポジトリのコミット一覧を開き、Merge pull request #... が並んでいれば、実質的にレビューを通す運用がされていると分かります。逆に、main へ直接コミットが積まれ続けている場合は、運用として保護されていない可能性があります。
リリースの直前に何が入ったか。 タグとタグの間の差分を見て、レビューを経ていない変更が混ざっていないか確かめます。
組織アカウントか、個人アカウントか。 組織であれば複数人の目が入る余地があります。1人の個人アカウントで、直接コミットのみで運用されている場合は、その1アカウントが単一障害点になります。

そのうえで、あなたのプロジェクトにとってその依存が壊れたときの影響と見合うかを判断してください。

GitHub のリポジトリ設定から、Rulesets（新しい方式）または Branch protection rules（従来方式）を有効にします。

Scorecard の点が上がりやすいのは、次の組み合わせです。

最後の「管理者にも適用」を入れていないと、設定はあっても実質的に迂回できるため、Scorecard の評価も上がりません。

1人で開発している場合、「承認を1人必須」にすると自分でマージできなくなります。その場合は Pull Request 必須と CI 必須だけを入れ、強制プッシュの禁止を加えるところから始めるとよいでしょう。