Logo

OSS依存管理の完全ガイド：Snyk & Dependabotで脆弱性を自動検出し、安全な開発環境を構築

2024/01/29に公開

はじめに

近年、OSS（オープンソースソフトウェア）の活用は急速に拡大し、開発の効率化に欠かせないものとなっています。しかし、外部ライブラリを取り入れることで、脆弱性の混入やライセンス違反のリスクが生じることも事実です。
特に、脆弱性を含んだパッケージを放置すると、プロジェクト全体のセキュリティが脅かされる可能性があるため、適切な管理が求められます。

本記事では、以下のポイントに焦点を当て、プロジェクトのセキュリティを向上させる方法を解説します。

  • Snyk / Dependabot の自動スキャン導入（定期的な脆弱性チェック）
  • 既存のパッケージに含まれる脆弱性の洗い出しとアップデート提案
  • 使用中のライブラリの適切なバージョン管理戦略の策定
  • 重大な脆弱性を含むパッケージのアラート通知設定（Slack / Teams 連携）
  • npm audit / yarn audit / pnpm audit の活用とレポート作成
  • パッケージの不要な依存関係を削減し、攻撃リスクを低減
  • OSS ライセンスの適切な管理（ライセンス違反のチェック）
  • 既存のプロジェクトで利用しているライブラリの EOL（End of Life）チェック
  • 新規導入するパッケージのセキュリティ評価基準を策定

1. Snyk / Dependabot の自動スキャン導入

Snyk や Dependabot は、依存関係の脆弱性を自動的に検出・修正するためのツールです。これらを活用することで、アプリケーションのセキュリティを向上させ、脆弱性の影響を最小限に抑えることができます。

Snyk の導入と活用

Snyk は、依存関係の脆弱性をスキャンし、修正提案を行う SaaS 型のセキュリティツールです。GitHub、GitLab などと統合することで修正のプルリクエストを行うなど修正に関する時間を大幅に短縮できます。

手順

  1. Snyk アカウントを作成し、GitHub / GitLab / Bitbucket などと連携
  2. リポジトリをスキャンし、既存の依存関係の脆弱性を検出
  3. snyk monitor を使用して、定期的にスキャンを実行
  4. CI/CD に統合して、ビルド時にスキャンを自動実行

例） GitHub Actions に追加

name: Snyk Security Scan
on: push
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Snyk Test
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Dependabot の導入手順

  1. Dependabot の基本機能（GitHub の設定画面から有効化）

これは 「Security updates」 として提供されている機能で、GitHub のリポジトリ設定から簡単に有効化できます。

  • GitHub のリポジトリに移動
  • Settings → Security → Code security and analysis
  • "Dependabot security updates" を 有効化 ✅
    • これで GitHub Security Advisories と連携し、既存の依存関係に 重大な脆弱性が発見された場合、自動で PR が作成されます。
  1. Dependabot の dependabot.yml を使った詳細なアップデート管理

Security updates だけでは 「新しいバージョンが出たら自動でアップデートする」 という用途には向きません。そこで、 .github/dependabot.yml を使うことで、定期的に依存関係をチェックし、脆弱性がなくても PR を作成 できます。

version: 2
updates:
  - package-ecosystem: "npm"  # npm の場合（yarn, pip, maven なども対応）
    directory: "/"            # ルートディレクトリ
    schedule:
      interval: "weekly"      # 毎週チェック（daily, monthly も可）
    open-pull-requests-limit: 5  # 最大5件のPRを開く

2. 既存のパッケージに含まれる脆弱性の洗い出しとアップデート提案

リポジトリ内の依存関係に対する脆弱性スキャンは、Snyk や Dependabot などのツールを活用して自動化できます。これにより、以下のような情報を取得し、脆弱性の対応を迅速に進められます。

  1. スキャンの仕組み
    Snyk や Dependabot は、リポジトリ内の package.json や yarn.lock（または package-lock.json）を解析し、依存しているライブラリのバージョンをチェックします。
    これらのツールは、脆弱性データベース（CVE, GitHub Advisory Database など） と照らし合わせて、以下のような情報を提供します。
  • 依存パッケージの既知の脆弱性
  • 影響を受けるファイルやモジュール
  • 影響度（深刻度）: Low / Medium / High / Critical
  • 修正可能なバージョンの推奨
  • 影響範囲（直接依存 / 間接依存）
  1. 開発チームの対応フロー
    スキャンの実施

  • snyk test や GitHub の Dependabot Alerts を定期的にチェック

    • CI/CD パイプラインにスキャンを組み込む

  • 影響範囲の確認

    • 直接依存しているか、それとも他のライブラリ経由で依存しているか確認
    • 影響度がCritical / High のものは優先対応

  • アップデートの実施

    • 可能なら推奨バージョンへアップデート（yarn upgrade / npm update など）
    • 互換性の問題がないかテスト
    • 変更をリリースに適用

  • 監視の継続

    • 定期的なスキャンの継続（CI/CD に組み込む）
    • 脆弱性情報のウォッチ（Snyk や GitHub Security Advisories）

使用中のライブラリの適切なバージョン管理戦略の策定

ライブラリの適切なバージョン管理戦略は、プロジェクトの安定性やセキュリティを維持するために不可欠です。以下のポイントを詳しく解説します。

  1. セマンティックバージョニング（SemVer）の理解と適用
    セマンティックバージョニング（SemVer）は、ライブラリのバージョン管理において一般的なルールです。これを適切に適用することで、アップデート時の影響を最小限に抑えることができます。
  • MAJOR.MINOR.PATCH の形式で管理される
    • MAJOR（メジャー）: 破壊的変更（非互換の変更）がある場合に増加
    • MINOR（マイナー）: 後方互換性を保った新機能の追加時に増加
    • PATCH（パッチ）: バグ修正（既存機能の修正のみ）で増加
  • アップデート時の影響を考慮
    • ^1.2.3（Caret）: 1.x.x の範囲で更新可能（2.0.0 には更新されない）
    • ~1.2.3（Tilde）: 1.2.x の範囲で更新可能（1.3.0 には更新されない）
    • 1.2.3（完全指定）: 指定バージョンのみ使用
  • 運用例
    • ライブラリの更新時には メジャーバージョンアップ（MAJOR）を慎重に検討
    • package.json で dependencies は ^ を利用し、devDependencies は ~ を使用することで、開発環境の変化を抑える
  1. ロックファイル（package-lock.json / yarn.lock）を活用
    ロックファイルを利用することで、異なる環境でのインストール時に 一貫したバージョン管理 が可能になります。
  • package-lock.json（npm）/ yarn.lock（Yarn）によって、各依存関係の厳密なバージョンを記録
  • チーム開発では ロックファイルをGitにコミット し、バージョンの統一を維持

運用例

  • CI/CD 環境で npm ci または yarn install --frozen-lockfile を使用し、確定したバージョンを再現
  • ロックファイルが意図しない変更を含んでいないかレビュー時に確認
  1. 定期的なアップデートチェック
    ライブラリのアップデートを怠ると、セキュリティ脆弱性やバグがプロジェクトに影響を与える可能性があります。定期的なアップデートチェックが重要です。

ツールを活用した自動チェック

  • Dependabot（GitHub）: package.json の更新を自動検出し、Pull Requestを作成
  • Snyk: 依存ライブラリの脆弱性をスキャンし、対策を提案
  1. 変更履歴（Changelog）を把握
    ライブラリの更新によって、APIの仕様変更や非互換が発生する可能性があります。アップデート前に Changelog（変更履歴） を確認する習慣をつけましょう。
  • CHANGELOG.md / GitHub Releases / npmのリリースノートを確認
  • メジャーバージョンアップの際は特に注意（Breaking Changes の影響を確認）
  • canary や beta タグが付いたバージョンには慎重に対応

運用例

  • 大規模なアップデートは別ブランチでテストし、互換性を確認
  • 影響範囲の大きいアップデートは 事前にIssueやドキュメントを確認 し、段階的に適用

重大な脆弱性を含むパッケージのアラート通知設定（Slack / Teams 連携）

脆弱性が検出された際に即座に対応できるようにするため、Slack や Microsoft Teams への通知を設定します。

Snyk での Slack 通知設定

  1. Snyk のダッシュボードから Integrations に移動
  2. Slack を選択し、ワークスペースと連携
  3. 通知のトリガー（High / Critical の脆弱性など）を設定
  4. 指定のチャンネルに通知が送信されることを確認

Dependabot での GitHub Actions 経由の通知

  1. dependabot.yml に assignees や reviewers を設定
  2. GitHub Actions で on: pull_request のトリガーを設定
  3. slack-notify-action を使用して、PR 作成時に通知を送信

これにより、脆弱性の発見から対応までのスピードを向上させることができます。

npm audit / yarn audit / pnpm audit の活用とレポート作成

npm audit の使用方法

npm audit は、package-lock.json を解析し、既知のセキュリティ問題があるかを確認するツールです。

npm audit

このコマンドを実行すると、影響を受けるパッケージ、脆弱性の深刻度（低・中・高・重大）、影響範囲、修正可能な方法が一覧表示されます。

脆弱性の自動修正

  • 影響の少ない更新のみを適用する（互換性のあるアップデートのみ）
npm audit fix
  • メジャーバージョンのアップグレードを強制適用する（リスクがあるが即時解決向け）
npm audit fix --force

npm audit を CI/CD パイプラインで実行することで、継続的にセキュリティ監査を行えます。

npm audit --json > audit-report.json

この JSON レポートを解析し、セキュリティ問題が発生した際にアラートを出す仕組みを構築できます。

yarn audit の使用方法

  • 基本的な使い方
    Yarn を使用している場合、yarn.lock をもとに依存関係の監査を行います。
yarn audit
  • JSON レポートの出力
    Yarn でも JSON 形式で監査結果を出力し、CI/CD で利用できます。
yarn audit --json > audit-report.json
  • 特定の深刻度以上の問題でエラーにする
    特定のレベル（low / moderate / high / critical）以上の脆弱性が検出されたときにプロセスを失敗させることが可能です。
yarn audit --level critical

pnpm audit の使用方法

  • 基本的な使い方
    pnpm audit も npm や yarn と同様に、依存関係のセキュリティチェックを行います。
pnpm audit
  • JSON レポートの出力
    CI/CD で監査結果を保存し、監視する場合に活用できます。
pnpm audit --json > audit-report.json
  • CI/CD でプロセスを失敗させる
    特定の脆弱性が検出された場合にビルドを失敗させるために、エラーハンドリングを活用できます。
pnpm audit --json > audit-report.json || exit 1

CI/CD での自動監査の設定例

GitHub Actions を使って、定期的に npm audit を実行し、脆弱性が検出された場合にアラートを送る方法です。

name: Security Audit

on:
  schedule:
    - cron: '0 0 * * *' # 毎日 00:00 に実行

jobs:
  security-audit:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Install dependencies
        run: npm ci

      - name: Run npm audit
        run: npm audit --json > audit-report.json || exit 1

      - name: Upload audit report
        uses: actions/upload-artifact@v3
        with:
          name: audit-report
          path: audit-report.json

この設定では、npm audit を毎日実行し、脆弱性がある場合に GitHub Actions のジョブが失敗するように設定しています。

不要な依存関係の削減と攻撃リスクの低減

依存関係の管理は、セキュリティの観点からも、プロジェクトのメンテナンスの観点からも非常に重要です。不要な依存関係を削除することで、以下のメリットがあります。

不要な依存関係がもたらすリスク

  • セキュリティリスク
    • 依存パッケージに脆弱性が含まれている可能性がある
    • 依存関係の深いライブラリほど、脆弱なバージョンを含む可能性が高まる
    • サプライチェーン攻撃（開発者アカウントの乗っ取りなど）により、悪意のあるコードが含まれるリスクがある
  • 管理コストの増大
    • パッケージのアップデートやメンテナンスが複雑化する
    • 使用しないパッケージが増えると、ビルド時間やアプリのパフォーマンスにも悪影響を与える
    • 依存関係の競合が発生しやすくなり、デバッグコストが上昇する

不要な依存関係の特定方法

depcheck は、プロジェクト内で 実際に使われていない依存関係 を特定できるツールです。

npx depcheck

実行すると下記がそれぞれ検知されます。

  • Unused dependencies（dependencies内で未使用）
  • Unused devDependencies（devDependencies内で未使用）
  • Missing dependencies（依存関係が見つからない）

不要な依存関係を手動で削除するには：

npm uninstall <package>

または

yarn remove <package>

依存関係の適正化

重複したパッケージを整理して、パッケージの構造を最適化できます。

npm dedupe

OSS ライセンスの適切な管理

OSS（オープンソースソフトウェア）ライセンスの適切な管理は、商用プロジェクトにおいて法的リスクを回避しつつ、安全にOSSを活用するために重要です。以下に詳しく説明します。

OSSライセンス管理の重要性

商用プロジェクトでOSSを利用する際、以下の点を確認する必要があります。

  • ライセンスの適合性
    • プロジェクトで使用可能なライセンスかどうか（例: MIT, Apache-2.0 は商用利用可能、GPL-3.0 は制約が強い）
    • ライセンスごとに求められる義務（例: クレジット表記、ソースコード公開の義務）
  • ライセンス違反リスクの回避
    • OSSライセンスに違反すると、法的措置を取られる可能性がある
    • 特にGPL（GNU General Public License）は、ソースコード公開義務があるため要注意
  • ライセンスの変更や更新の追跡
    • OSSのアップデート時にライセンスが変更される場合がある
    • 定期的な監査が必要

npm-license-crawler の活用

npm-license-crawler は、node_modules に含まれる全パッケージのライセンス情報を取得し、CSV や JSON 形式で出力できるツールです。

以下のような特徴があります。

  • license-checker よりも依存関係の非推奨警告が少ない
  • JSON や CSV 形式で結果を出力しやすい
  • 指定したライセンスをフィルタリング可能
  • CI/CD でのライセンス監査に適している

すべてのパッケージのライセンスを表示する

npx npm-license-crawler

例（出力イメージ）：

└─ zod@3.23.8
   ├─ licenses: MIT
   ├─ repository: https://github.com/colinhacks/zod
   ├─ licenseUrl: https://github.com/colinhacks/zod/raw/master/LICENSE
   └─ parents: exapmle

JSON 形式でライセンス情報を取得

npx npm-license-crawler --json licenses.json

例（出力イメージ）：

"zod@3.23.8": {
    "licenses": "MIT",
    "repository": "https://github.com/colinhacks/zod",
    "licenseUrl": "https://github.com/colinhacks/zod/raw/master/LICENSE",
    "parents": "example"
}

CSV 形式でライセンス情報を取得

npx npm-license-crawler --csv licenses.csv

例（出力イメージ）：

"zod@3.23.8","MIT","https://github.com/colinhacks/zod","https://github.com/colinhacks/zod/raw/master/LICENSE","example"

既存のライブラリの EOL（End of Life）チェック

EOL（End of Life）とは？

EOL（End of Life）とは、ソフトウェアやライブラリの開発・サポートが終了することを指します。EOLを迎えたライブラリは以下のリスクを伴います。

  • セキュリティリスク：新たに発見された脆弱性が修正されない
  • 互換性の問題：新しいバージョンのNode.jsや他のライブラリとの互換性がなくなる
  • 機能追加の停止：新機能や最適化のアップデートが行われない

プロジェクト内のパッケージの現在のバージョンと最新バージョンを確認

このコマンドは、プロジェクト内のパッケージの現在のバージョンと最新バージョンを確認できます。

npm outdated

出力例

Package                      Current   Wanted   Latest  Location                                  
@hookform/resolvers            3.9.0   3.10.0    4.1.3  node_modules/@hookform/resolvers          
@types/react                 18.3.11  18.3.18  19.0.10  node_modules/@types/react                 
@types/react-dom              18.3.1   18.3.5   19.0.4  node_modules/@types/react-dom             
class-variance-authority       0.7.0    0.7.1    0.7.1  node_modules/class-variance-authority     
eslint                        8.57.1   8.57.1   9.21.0  node_modules/eslint                       
eslint-config-prettier         9.1.0    9.1.0   10.0.2  node_modules/eslint-config-prettier       
eslint-plugin-prettier         5.2.1    5.2.3    5.2.3  node_modules/eslint-plugin-prettier       
eslint-plugin-tailwindcss     3.17.5   3.18.0   3.18.0  node_modules/eslint-plugin-tailwindcss    
postcss                       8.4.47    8.5.3    8.5.3  node_modules/postcss                      
prettier-plugin-tailwindcss    0.6.8   0.6.11   0.6.11  node_modules/prettier-plugin-tailwindcss  
react                         18.3.1   18.3.1   19.0.0  node_modules/react                        
react-dom                     18.3.1   18.3.1   19.0.0  node_modules/react-dom                    
react-hook-form               7.53.1   7.54.2   7.54.2  node_modules/react-hook-form              
tailwind-merge                 2.5.4    2.6.0    3.0.2  node_modules/tailwind-merge               
tailwindcss                   3.4.14   3.4.17    4.0.9  node_modules/tailwindcss                  
typescript                     5.4.3    5.4.3    5.8.2  node_modules/typescript                   
zod                           3.23.8   3.24.2   3.24.2  node_modules/zod

各カラムの意味

  • Current（現在インストールされているバージョン）
  • Wanted（package.jsonの範囲内でインストール可能な最新バージョン）
  • Latest（リポジトリに存在する最新バージョン）

上記の結果が出た場合は下記のような対応が必要となります。

  • マイナーバージョンのアップデート

    • npm update を実行（Wanted のバージョンまで自動更新）
    • 破壊的変更の可能性が低いため、基本的には問題なく適用可能

  • メジャーバージョンのアップデート（慎重に）

    • react, react-dom, tailwindcss はメジャーアップデートがあるため、変更点を確認する
    • 影響範囲を調査しつつ、アップデートする場合は npx npm-check-updates -u で package.json を更新し、npm install

EOLになっているかを調べる

npm outdated や npm-check-updates だけでは、ライブラリがEOLかどうかは判別できません。以下の方法を組み合わせて確認します。

  1. 公式ドキュメントやリリースノートを確認
    ライブラリの公式サイトやGitHubのリリースノートで「EOL」の告知がないかチェックしましょう。

例：React のリリースノート

https://github.com/facebook/react/releases

例：Node.js のEOLスケジュール

https://nodejs.org/en/about/releases/

  1. GitHubリポジトリのアクティブ状況をチェック

GitHubのコミット履歴やIssueを見て、メンテナンスされているかを確認できます。

  • 最終コミットが1年以上前
  • Issueが放置されている
  • 「This project is no longer maintained」の記述がある

こうした状況があれば、EOLの可能性が高いです。

  1. npm trendsやLibraries.ioを使って調査
    ライブラリのトレンドや更新頻度を調べるツールも活用できます。
  • npm trends（パッケージの人気度を比較）

https://npmtrends.com/

  • Libraries.io（EOLや更新頻度をチェック）

https://libraries.io/

EOLのライブラリをどうするか

EOLになったライブラリが見つかった場合の対応策を考えます。

  1. 推奨ライブラリがあるか調べる
    公式が代替ライブラリを推奨している場合、そのライブラリへの移行を検討します。

例）
moment.js（EOL） → date-fns もしくは luxon

  1. メンテナンスされているフォークを探す
    人気のあるライブラリの場合、メンテナンスされているフォーク（派生版）が存在することがあります。GitHubのリポジトリを調べて、活発なフォークがないか確認します。

  2. どうしても更新できない場合
    npm audit を使って脆弱性の影響を特定し、必要なら手動パッチを適用
    package-lock.json で問題のあるバージョンを固定し、影響範囲を限定する

新規導入するパッケージのセキュリティ評価基準の策定

新規に OSS パッケージを導入する際には、以下のポイントを考慮すると安全性を向上できます。

メンテナンス状況

OSSパッケージのセキュリティや品質を担保するためには、適切にメンテナンスされていることが重要です。以下の点を確認すると、安心して利用できるか判断できます。

  • 最終更新日
    • GitHub のリポジトリで last commit を確認。
    • 1年以上更新されていない場合は、メンテナンスが停止している可能性がある。
  • Issue や Pull Request の対応状況
    • Issues タブで未解決の重大なバグが放置されていないか確認。
    • Pull Requests のマージ速度を確認し、開発が活発かどうかチェック。
  • メンテナーの活動状況
    • コア開発者が定期的にコミットしているか確認。
    • 主要メンテナーが離脱した場合、新たな開発者が引き継いでいるかを見る。

ダウンロード数

利用者が多いパッケージは、コミュニティによる検証が進んでおり、比較的安全である可能性が高いです。

  • npm trends

    • npm trends を使うと、複数のパッケージの人気度を比較できる。
    • 競合パッケージと比較し、適切な選択を行う。

  • npm-stat

    • npm-stat を使って、特定の期間のダウンロード数を確認。
    • 急激にダウンロード数が減少していないかもチェックする。

例）Reactの2020年〜2024年までのダウンロード推移。
順調にダウンロード数は増えており問題ないパッケージと考えられる。

Image from Gyazo

既知の脆弱性

導入前にセキュリティスキャンを実施し、既知の脆弱性がないかチェックします。

  • npm audit
  • GitHub Dependabot
  • Snyk

まとめ

OSSパッケージを活用する際には、単にインストールして終わりではなく、継続的なセキュリティチェックと適切な管理が不可欠です。
今回紹介した Snyk / Dependabot による自動スキャン や npm audit / yarn audit の活用 を取り入れることで、脆弱性を未然に防ぎ、安全な開発環境を維持できます。

また、ライブラリのEOLチェックやライセンス管理の徹底も重要なポイントです。
定期的な監査とアラート通知の仕組みを導入し、チーム全体でセキュリティ意識を高めることが、長期的な安定運用につながります。

セキュアな開発環境を実現するために、今すぐ実践できる対策から取り組んでみてください。

関連する弊社の支援サービス

記事に関するお問い合わせ📝

記事の内容に関するご質問、ご意見などは、下記よりお気軽にお問い合わせください。
ご質問フォームへ

技術支援などお仕事に関するお問い合わせ📄

技術支援やお仕事のご依頼に関するお問い合わせは、下記よりお気軽にお問い合わせください。
お問い合わせフォームへ

関連する技術ブログ

弊社の支援サービス