OpenSSF Scorecard とは何か — 何を測っていて、何を測っていないか

OpenSSF Scorecard は、 Linux Foundation 傘下の OpenSSF（Open Source Security Foundation） が 開発している自動チェックツールです。

リポジトリを与えると、開発のやり方に関する項目を機械的に調べ、 それぞれに 0〜10 の点を付けます。

重要なのは、何を見ているかです。

つまり Scorecard が測っているのは、 **「そのプロジェクトが、事故を起こしにくいやり方で開発されているか」**です。 コードの中身の品質ではありません。

結果を得る方法は3つあります。

1. 公開されているスキャン結果を見る

OpenSSF は、重要度の高いリポジトリを週次でスキャンして結果を公開しています。 https://api.securityscorecards.dev/projects/github.com/{owner}/{repo} で取得できます。 deps.dev 経由でも参照できます。

2. 自分で実行する

scorecard は Go 製のコマンドラインツールとして配布されており、 自分のリポジトリに対して実行できます。 管理者権限のトークンで実行すると、公開スキャンでは読めない項目まで見られます。

3. GitHub Actions として組み込む

ossf/scorecard-action を使うと、リポジトリの更新のたびに結果を更新できます。

ここで押さえておきたいこと。

公開されているスキャンの対象は、 重要度（criticality）が一定以上と判定されたリポジトリです。 新しいプロジェクトや、あまり参照されていないリポジトリは対象外で、 結果そのものが存在しません。

結果が無いことは、評価が低いことではありません。

実際に有名なライブラリの結果を見ると、多くの項目が低いことに驚くかもしれません。 これには理由があります。

理由1: 公開スキャンには権限が無い

Branch-Protection や Webhooks は、 リポジトリの管理者権限が無いと設定を読めません。 OpenSSF は他人のリポジトリの管理者ではないので、 実際には保護されていても低い点になります。

理由2: そもそも大多数が満たしていない項目がある

Fuzzing や CII-Best-Practices は、 OSS 全体から見ればごく一部しか満たしていません。 0点が普通です。

理由3: 分野によって意味が無い項目がある

Packaging は、Go のように レジストリへの公開工程が存在しないエコシステムでは満たしようがありません。 Fuzzing は、パーサでないライブラリには効果が限られます。

理由4: 既定のままだと減点される項目がある

Token-Permissions は、 permissions: を書いていないだけで低く出ます。 意図して広い権限を与えているわけではありません。

結論として、総合スコアを足し引きして比べることには意味がありません。 項目ごとに、なぜ低いのかを見る必要があります。

ここまで限界を挙げてきましたが、Scorecard には確かな価値があります。

1. 観測が公開されている

誰かの主観ではなく、同じ基準で機械的に測られた結果が公開されています。 基準もソースコードも公開されており、誰でも検証できます。

2. 時系列で追える

週次で更新されるため、改善しているか、悪化しているかが分かります。 ある時点の点数より、その変化のほうが情報量があります。

3. メンテナーにとって実用的なチェックリストになる

自分のリポジトリに対して実行すると、 「ブランチ保護を入れていない」「権限を絞っていない」 といった抜けが具体的に出てきます。 多くは設定を数行足すだけで直るものです。

4. 特定の項目は、単独で強い意味を持つ

Dangerous-Workflow の 0点 は、 「確認できなかった」ではなく 「具体的な該当箇所が見つかった」 を意味します。 ファイル名と行番号まで出るので、実際に読んで判断できます。

Scorecard は「判定装置」ではなく「観測の道具」です。 OSSカルテがやっているのは、その観測結果に 日本語で意味を付けて、誤読を防ぐことです。

各項目の詳しい説明は、指標の読み方にまとめてあります。