あけましておめでとうございます！
開発本部 SINIS for X 開発チームの西野（@fingerEase24）です。
今年も弊テックブログ共々どうぞよろしくお願いいたします。
さて、以前弊テックブログにて、『チームでライブラリバージョンを最新に保つには？！ ライブラリガーデニングのすゝめ』という記事を公開しました。
記事にある通り、私たちのチームではGitHubのDependabotを用いて定期的に依存ライブラリのアップデートを行うガーデニング活動を継続しているのですが、それに伴って発生し得るセキュリティリスクについてどう考え、どう対策しているかをお話ししようと思います。
セキュリティ上のリスク
広く知られている通り、依存しているライブラリが長らくアップデートされていないことは典型的な技術負債であり、特にセキュリティアップデートを適用しないことはセキュリティ上のリスクに繋がります。
一方で、ライブラリをアップデートすることがセキュリティ上のリスクに繋がる可能性も存在します。
昨今、サプライチェーン攻撃によりサードパーティライブラリに悪意のあるコードが混入させられる事例が多く発生しています。
参考: 2025年9月に発生したnpmパッケージに対するサプライチェーン攻撃
悪意がない場合でも、新たなバージョンにバグや脆弱性が混入している可能性は常に存在します。
こういった不適切なバージョンがそうであると判明する前にアップデートを行なってしまった場合、サービスに対する損害を被る事態になりかねません。
特に、ガーデニングのように週次でアップデートを行う場合、リリースされて間もないバージョンを適用することになるためそのようなリスクは上昇します。
対策
Dependabotのcooldownオプションを利用することで、リリースから一定の期間が経過したバージョンのみを更新対象とする制限を設けました。
以下のように簡単に設定できます。
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
day: "monday"
time: "10:00"
timezone: "Asia/Tokyo"
cooldown:
default-days: 7
ここでは例として遅延期間を1週間としています。
この期間を何日に設定するかについては正解はなく、サービスの特性やチームの方針などによって信頼性をどのように考えるか次第で決めるのが良いでしょう。
まずはある程度決め打ちで設定し、その期間では短すぎる/長すぎることによって信頼性が十分に担保できないことが見込まれるようであれば変更するといった運用を想定しています。
なお、この設定はセキュリティアップデートには適用されないため、セキュリティアップデートを適用しないことによるリスクが発生する心配もありません。
実際の例として、最近だとNext.jsのReact Server Componentsにおける脆弱性が発見され、以下のようにcooldown期間を待たずしてセキュリティアップデートのPRが作成されました。
対応方針を考えるにあたっては以下の記事を参考にさせていただきました。
まとめ
依存ライブラリの管理は難しい問題です。
第三者の提供するコードに依存する以上、そこには必ずリスクが発生します。
新たな依存ライブラリを導入することに加えて、そのバージョンを更新すること/しないことによって生じるリスクについても理解し、常に評価する姿勢を忘れないようにしたいですね。
もしチームで定期的に依存ライブラリの更新を行なっている場合は、遅延を入れることでリスクを軽減することも是非検討してみてください。
テテマーチでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ herp.careers
エンジニアチームガイドはこちら！ tetemarche01.notion.site
