Signed-Releases とは — OpenSSF Scorecard の見方

何を見るチェックか

Scorecard は、そのリポジトリの直近のリリース（GitHub Releases）を見て、成果物に署名が付いているかを調べます。

探しているのは次のようなものです。

直近の複数のリリースを対象に、署名が付いている割合で点が決まります。

署名は「中身が安全であること」を保証しません。 保証するのは「このファイルは、確かにその鍵の持ち主が作った」という点だけです。

点が低いということは、配布物が本物かどうかを、受け取る側が機械的に確認できない、という意味です。

これが効いてくるのは、次のような場面です。

署名があれば、これらは検証の時点で弾けます。無ければ、「ダウンロードできた＝正しいものだった」と信じるしかありません。

ただし、署名が無いこと自体はよくあることです。次で説明します。

署名の無いリリースは、まったく珍しくありません。

多くのエコシステムでは、署名より先にレジストリの仕組みが機能しています。 npm や PyPI では、パッケージの公開元がアカウントで管理されており、多くの利用者はレジストリ経由で入手します。GitHub Releases の署名を見る機会自体が少なめです。
npm では、署名より「provenance（来歴）」が主流になりつつあります。 GitHub Actions から公開すると、どのリポジトリのどのコミットから作られたかの証明が付きます。これは .asc ファイルではないため、 Scorecard の Signed-Releases では拾われないことがあります。 「provenance はあるのに Signed-Releases は低い」という状態は普通に起こります。
そもそも GitHub Releases を使っていないプロジェクトもあります。 タグだけを打ち、配布はレジストリ側だけ、という運用は一般的です。この場合、検査する対象が無いので低く出ます。

この項目が 0 だからという理由だけで採用を見送るのは、現実的ではありません。

自分がどこから入手しているかを確認する。 npm / PyPI / Packagist などのレジストリ経由なら、まずレジストリ側の情報（公開元、provenance の有無）を見ます。
npm の場合は provenance バッジを見る。 パッケージページに provenance の表示があれば、どのリポジトリのどのワークフローから公開されたかを確認できます。
バイナリを直接ダウンロードして使う場合は、署名の確認を運用に組み込む。 CLI ツールやコンテナイメージを配布物から直接入れている場合、ここは実際に効きます。
ロックファイルのハッシュを信頼の起点にする。 package-lock.json などには取得物のハッシュが記録されます。ロックファイルをコミットしておけば、少なくとも「前回と同じものが入ったか」は検証できます。

今から入れるなら、GPG の鍵管理より、CI からの自動署名のほうが現実的です。

npm なら provenance を有効にする。 GitHub Actions から npm publish --provenance で公開すると、来歴が自動で付きます。鍵の管理が不要です。
バイナリを配布しているなら Sigstore（cosign）を使う。 鍵を自分で保管せずに署名でき、CI に数行で組み込めます。
GitHub の Artifact Attestations を使う。 ワークフローから actions/attest-build-provenance を呼ぶだけで、成果物の来歴が付きます。
チェックサムだけでも置く。 署名まで手が回らない場合でも、SHA256SUMS を一緒に公開しておけば、少なくとも転送中の破損や取り違えは検出できます。

鍵を個人の端末に置いて手作業で署名する運用は勧めません。 鍵を失ったときに検証が続けられなくなり、引き継ぎもできなくなります。