OSSカルテの読み方 — 何を見て、何を見ないか

カルテを開くと、いちばん上に3つの数字が出ます。

ここに総合評価も点数もありません。 意図的にそうしています。

ひとつの色やスコアに丸めると、読む人はそれだけを見て中身を見なくなります。 そして丸め方の責任を、こちらが負うことになります。 セキュリティに絶対はなく、指標の組み合わせから 「このOSSを使ってよいか」を決めることはできません。

「データが取れないこと」と「問題があること」を分けて数えているのも重要な点です。 この2つを混ぜると、情報が少ないOSSほど悪く見えてしまいます。 新しいプロジェクトや、小さなライブラリが不当に低く見えるのを避けるためです。

指標は上から順に並んでいますが、採用を検討するときに見る順序は別です。 実務で効く順に並べると、こうなります。

1. ライセンス

最初に見てください。ここで条件が合わなければ、他をどれだけ見ても意味がありません。 確認にかかる時間も最も短く済みます。 → License

2. 使うバージョンに影響する脆弱性

「そのライブラリに脆弱性があるか」ではなく、 **「あなたが使うバージョンに影響するか」**を見ます。 多くの Advisory は「◯.◯.◯ 未満に影響、◯.◯.◯ で修正」という形です。 → Vulnerabilities

3. リポジトリとパッケージの紐付け

パッケージが宣言しているリポジトリは自己申告で、詐称できます。 名前の似た別物を掴んでいないかを確認してください。

4. 保守の状態

Archived になっていないか、直近のリリースがあるかを見ます。 ただし、更新が少ないことがそのまま問題を意味するわけではありません。 → Maintained

5. 開発プロセスの指標

OpenSSF Scorecard の各項目です。ここは最後でかまいません。 1〜4 に比べると、あなたのプロジェクトへの影響は間接的です。

OpenSSF Scorecard は各項目に 0〜10 の点を付けますが、 それらを合計して安全性を比べることはできません。

理由は、点が低くなる原因が項目ごとにまったく違うからです。

• Branch-Protection が 0 — 公開スキャンには設定を読む権限が無いため。実際は保護されていることが多い
• Fuzzing が 0 — ほとんどのプロジェクトが 0 です
• CII-Best-Practices が 0 — バッジを申請していないだけ
• Token-Permissions が 0 — permissions: を書いていないだけ
• Contributors が 0 — 1人で保守しているプロジェクト

低い点の多くは「悪い」ではなく「わからない」か「そういう分野ではない」です。

そのため、OSSカルテでは Scorecard の総合スコアを大きく出しません。 公式が算出した値として、出典とともに参考表示するにとどめています。

スター数やダウンロード数は表示しますが、健康状態とは別の枠に置いています。 同じ表にも、同じカードにも入れません。

理由は単純で、人気があることと、保守されていることは別のことだからです。

• スターが多くても、数年前に更新が止まっているライブラリはあります
• ダウンロードが多いのは、多くの依存に含まれているからかもしれません
• 逆に、スターが少なくても、必要な人にきちんと保守されているものもあります

スター数は「多くの人が便利だと思った」ことの記録であって、 「今も安全に使える」ことの記録ではありません。

同じ理由で、件数サマリの3つの数字にも人気の指標は含めていません。

OSSカルテは、次のような書き方をしません。

開発の終了について書けるのは、リポジトリが Archived になっている、 パッケージが Deprecated として公開されている、 README に明記がある、メンテナーによる告知がある、 のいずれかが確認できる場合だけです。

最終コミットが古いというだけでは書きません。 根拠のない断定は、OSS開発者に対する不当な評価になるからです。

掲載内容に誤りを見つけられた場合は、 お問い合わせからご連絡ください。 OSS開発者の方からのご指摘も歓迎します。