Vulnerabilities とは — OpenSSF Scorecard の見方

何を見るチェックか

Scorecard は OSV に問い合わせて、そのプロジェクトに関係する公開済みの脆弱性が残っていないかを調べます。

対象になるのは、

で、修正されていないものが1件でも見つかると 0 点になります。見つからなければ 10 点です。

つまりこの項目は、0 か 10 に振れやすい作りになっています。 9点や3点にはなりません。

0点ということは、OSV に登録されている脆弱性のうち、未修正のものが検出されたという意味です。

ただし、ここから先が重要です。0点であることは、あなたが危険であることを意味しません。

逆に 10点でも安心はできません。 これは「公開済みの脆弱性が見つからなかった」であって、「脆弱性が無い」ではありません。まだ誰も気づいていないものは、当然ここに出てきません。

この項目は、必ず具体的な Advisory の中身まで見てから判断してください。

「脆弱性の件数」で危険度を比べないでください。

よくある誤解を3つ挙げます。

件数が多いほど危険、ではない。 広く使われているプロジェクトほど、多くの人が調べ、多くの Advisory が公開されます。件数の多さは、注目度の高さと調査の density を反映していることがあります。誰も見ていないライブラリの Advisory が 0 件なのは、安全だからとは限りません。
リポジトリに脆弱性があるかどうかより、「使うバージョンに影響するか」が重要。 多くの Advisory は「◯.◯.◯ より前に影響、◯.◯.◯ で修正」という形を取ります。修正版を使っていれば、その Advisory はあなたには関係ありません。
依存経由のものと、そのプロジェクト自身のものは意味が違う。 依存経由であれば、あなたのプロジェクト側で依存のバージョンを上げるだけで解消できる場合があります。

「使うバージョン」を決めてから調べる。 バージョンを決めずに脆弱性の有無だけを見ても、判断材料になりません。
Advisory を開いて、影響範囲を読む。 Affected versions と Patched versions を確認します。修正版が出ているなら、そこへ上げられるかを検討します。
修正版が出ていない場合、回避策があるかを見る。 Advisory に Workarounds が書かれていることがあります。
自分のプロジェクト側でも走査する。 実際に何が入っているかは、ロックファイルを見ないと分かりません。 npm audit、pip-audit、composer audit、あるいは osv-scanner などを使います。 依存の依存まで含めて見るのが大切です。
報告先を確認しておく。 → Security-Policy

依存の更新を自動化する。 Dependabot や Renovate を入れておくと、 Advisory の公開に追随しやすくなります。 → Dependency-Update-Tool
修正版を出したら、GitHub Security Advisory を公開する。 Advisory を出すと OSV に取り込まれ、利用者側のツールが自動で検知できるようになります。修正だけして黙っていると、使っている人は気づけません。
修正版のバージョン番号を、Advisory の Patched versions に正確に書く。 ここが正確でないと、利用者のツールが「まだ危険」と誤検知し続けます。
サポートするバージョンを決めて SECURITY.md に書く。 すべての過去バージョンにバックポートする義務はありません。範囲を明示すれば十分です。