「最新版を使えばいい」は本当に正しい？Dependabotを使って“pin + 自動更新”にする理由
依存ライブラリやGitHub Actions、Terraform Providerのバージョン管理をしていると、よく出てくるのが次の考え方です。 新しいバージョンが出たら、常に最新版へ上げればいいのでは？ 一見すると合理的です。 実際、古いバージョンを長期間使い続けるより、継続的にアップデートした方が、脆弱性や非互換の問題を後回しにしにくくなります。 ただし、実際の開発運用では、 「バージョンを固定しない」ことと「常に新しい状態を保つ」ことは別です。 むしろ、 バージョンは固定し、Dependabotで自動的に更新PRを作る という運用の方が、安全性と更新頻度を両立しやすくなります。 今回は、実際の開発チームで出た「pinするべきか、しないべきか」という議論をベースに、Dependabotをどう使うべきか整理します。 きっかけは「そもそもpinしなくていいのでは？」という疑問 あるプロジェクトで、GitHub ActionsやTerraform Providerのバージョンを更新する話が出ました。 その中で、 理想的には何もpinしない方がいい。新しいバージョンが出たら常にアップグレードすればいいのでは？ という意見が出ました。 この考え方自体は間違っていません。 目標としては、 依存関係を古いまま放置しない というのが正しいです。 ただし、その目標を実現する方法として「pinしない」を選ぶと、別の問題が出てきます。 そこで出てきたのが、 「pinしない」のではなく、「pin + automated bumps」にしよう という考え方です。 つまり、 バージョンは固定する。しかし、更新作業は自動化する。 これがDependabotを使う理由です。 GitHub Actionsでは、floating tagがリスクになる たとえばGitHub Actionsでは、次のような指定をすることがあります。 これは分かりやすく、一般的な書き方です。 ただし、v4 のようなタグは、厳密には「特定のコードそのもの」を表しているわけではありません。 タグが別のコミットを指すように変更されれば、同じ @v4 という記述でも、実際に実行されるコードが変わる可能性があります。 CI/CDで実行されるActionは、ビルド環境やデプロイ権限にアクセスすることがあります。 そのため、これはサプライチェーンセキュリティの観点でも重要です。 より厳密に管理するなら、特定のコミットSHAに固定します。 こうすると、同じ設定から実行されるコードが勝手に変わることはありません。 ただし問題があります。 固定しただけでは、そのバージョンは永遠に古くなっていきます。 そこでDependabotを使います。 新しいバージョンが出たら、 という流れにします。 つまり、 固定することで再現性を確保し、Dependabotで鮮度を維持する […]
記事を読む →
