OpenSSF Scorecard / ビルドの守り方

Dependency-Update-Tool
依存の更新が自動化されているか

Dependabot や Renovate のような、依存の更新を自動で提案する仕組みが設定されているかを見るチェックです。設定ファイルの有無だけを見ており、実際に更新されているかまでは見ていません。

何を見るチェックか

Scorecard は、依存を自動更新するツールの設定ファイルがあるかを探します。

対象になるのは、たとえば次のものです。

  • .github/dependabot.yml(Dependabot)
  • renovate.json / .renovaterc.json / package.json の renovate 欄(Renovate)
  • .pyup.yml(PyUp)
  • Sonatype Lift などの設定

1つでも見つかれば 10点、無ければ 0点です。中間はありません。

設定ファイルの存在だけを見ており、 実際に更新の Pull Request が出ているか、それがマージされているかは見ていません。

点が低いと何を意味するか

点が低いということは、依存の更新が手動で行われている可能性がある、という意味です。

これが効いてくるのは、依存の側に脆弱性が公開されたときです。

  • 自動化されていれば、公開の直後に更新の Pull Request が出る
  • 手動なら、メンテナーが気づくまで動きません

依存の脆弱性は、そのプロジェクトの利用者にも連鎖します。 更新の速さは、プロジェクト単体の問題ではなく下流に伝わる速さでもあります。

ただし、依存がほとんど無いプロジェクトでは、そもそも更新する対象がありません。 その場合、この項目の低さに実害はほぼありません。

誤解しやすい点

この項目は「設定ファイルがあるか」しか見ていません。中身も結果も見ていません。

そのため、次のような食い違いが普通に起こります。

  • 設定はあるが、出た Pull Request が何十件も放置されている。 それでも 10点です。「更新されている」証明にはなりません。
  • 設定は無いが、メンテナーが毎月手で更新している。 それでも 0点です。実態は健全でも評価されません。
  • 依存が0個のライブラリ。 更新する対象が無いのに 0点になります。 小さく、外部依存を持たないことを設計方針にしているライブラリは珍しくありません。

また、自動更新には副作用もあります。 ボットの Pull Request をよく見ずにマージし続けると、 Code-Review の「作成者以外の承認」が形骸化します。 コミット数だけが増えて Maintained が高く見える、という状態にもなります。

この項目は、単独ではほとんど何も語りません。 依存の数、Advisory への対応履歴と合わせて読んでください。

採用する側が確認すべきこと

  1. そのプロジェクトの依存の数を見る。 package.json や composer.json を開いて、依存が数個なら この項目の低さは気にしなくてよいでしょう。

  2. 設定があるなら、Pull Request の状態を見る。 Pull requests タブでボットの PR が溜まっていないかを確認します。 溜まっているなら、設定はあっても機能していません。

  3. 過去の Advisory への反応を見る。 これが最も確実です。過去に依存由来の脆弱性が出たとき、 どのくらいで修正版が出ているかを見ます。

  4. 自分のプロジェクトに入れる。 相手が自動化していなくても、あなたが使っているバージョンを上げるのはあなたの側です。 自分のリポジトリに Dependabot / Renovate を入れておけば、 相手が修正版を出した時点で気づけます。

メンテナーなら何を改善できるか

.github/dependabot.yml を1つ置くだけで満たせます。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

  # ★GitHub Actions も対象にする。
  #   Pinned-Dependencies で SHA 固定した場合、これが無いと古いまま止まる。
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

運用のこつ。

  • open-pull-requests-limit を設定する。 上限が無いと PR が溢れ、見なくなります
  • パッチ更新はまとめる(groups)。 1件ずつ PR が来ると疲れます
  • CI を必須にする。 ボットの PR も CI が通ってからマージする形にすれば、 中身を見ないマージでも壊れにくくなります
  • Pinned-Dependencies と必ずセットにする。 固定だけして自動更新を入れないと、古い依存が固定されたまま残ります

依存が無いライブラリであれば、この項目は無理に満たさなくてかまいません。 その場合は README に「外部依存を持たない方針である」と書いておくと、 利用者が 0点 の意味を正しく読めます。

あわせて読む