何を見るチェックか
Scorecard は、リポジトリに SECURITY.md（または security.md、.github/SECURITY.md、
docs/SECURITY.md など）があるかを探します。
見つかった場合、さらに中身を確認します。
- メールアドレスや報告用URLなど、連絡先が書かれているか
- 報告からの流れや、対応の目安期間が書かれているか
- 十分な長さの説明があるか（1行だけのファイルは低く評価されます）
GitHub の Private vulnerability reporting が有効になっている場合も評価されます。
ファイルを置いただけでは満点になりません。中身が見られています。
点が低いと何を意味するか
点が低いということは、脆弱性を見つけた人が、どこへ知らせればよいか分からない状態を意味します。
これが実際に困るのは、次のような場面です。
- 発見者が Issue に脆弱性の詳細を書いてしまい、修正前に公開されてしまう
- 報告先が分からず、そのまま放置されて誰にも直されない
- 報告してもいつ対応されるのか分からず、発見者が独自に公表してしまう
つまりこの項目は、**そのプロジェクトが「悪い知らせを受け取る準備をしているか」**を示します。
なお、これは「脆弱性がある」という意味ではまったくありません。 脆弱性の有無を見ているのは Vulnerabilities の方です。
誤解しやすい点
「SECURITY.md が無い＝ずさんなプロジェクト」ではありません。
次のようなケースでは、点が低くても実害はほとんどありません。
- 組織全体で共通の SECURITY.md を持っている場合。
GitHub は組織の
.githubリポジトリに置いたファイルを全リポジトリに適用しますが、 Scorecard がそれを拾えないことがあります。 - 小さなユーティリティで、報告先が README に書かれている場合。 実質的に連絡はできますが、決められたファイル名ではないため評価されません。
- 報告先がプロジェクトの公式サイト側にある場合。
逆に、ファイルはあるのに中身が空に近い場合も低く出ます。 「Please report security issues.」の一行だけ、というファイルがこれにあたります。
判断するときは、点数ではなく実際に SECURITY.md を開いて読むのが確実です。
採用する側が確認すべきこと
-
リポジトリの
SECURITY.mdを実際に開く。 連絡先が書かれているか、対応の目安が書かれているかを見ます。 -
無ければ、組織の
.githubリポジトリを見る。github.com/{組織名}/.githubに共通のファイルが置かれていることがあります。 -
過去の Advisory の扱われ方を見る。 リポジトリの Security タブに公開済みの Advisory があれば、 報告から公開までの流れが実際に機能していた証拠になります。 これは SECURITY.md の有無よりも強い材料です。
業務で使う依存であれば、自分が脆弱性を見つけたときに誰へ連絡するかを、 採用の時点で1行メモしておくと後で困りません。
メンテナーなら何を改善できるか
リポジトリのルートに SECURITY.md を置きます。GitHub のリポジトリ設定にある
**Security policy の「Start setup」**から雛形を作れます。
最低限、次を書いておくと十分に機能します。
- 報告先（メールアドレス、または GitHub の Private vulnerability reporting を使う旨）
- サポートしているバージョン（どのバージョンなら修正を出すか）
- 返信の目安（例: 3営業日以内に一次返信）
- 公開までの流れ（修正版の公開後に Advisory を出す、など）
あわせて、リポジトリ設定の Private vulnerability reporting を有効にすることをおすすめします。 発見者が GitHub 上から非公開で報告でき、Issue に書かれてしまう事故を減らせます。
1人で開発している場合でも、「返信は遅れることがあります」と正直に書いておく方が、 何も書かれていないより発見者にとって親切です。