Dependabotでnpm以外のマルウェア警告が増えた理由と有効化方法

Dependabotで、これまでnpm中心だったマルウェア警告がPyPIなどでも表示されるようになった理由は、GitHub Advisory DatabaseがOpenSSFの「malicious-packages」データを取り込み始めたためです。

2026年7月28日の変更により、Dependabotが照合できるマルウェア情報の範囲が拡大しました。すでに「Dependabot malware alerts」を有効にしているリポジトリでは、新しい対象が自動的に反映されるため、設定ファイルの修正は不要です。未設定の場合は、リポジトリの「Settings」から「Dependabot alerts」と「Dependabot malware alerts」を順番に有効化します。(The GitHub Blog)

Dependabotのマルウェア警告がPyPIなどへ拡大した理由

今回の変更で重要なのは、Dependabot本体の検査ロジックが単純に厳しくなったのではなく、照合元となるマルウェア情報が大幅に増えたことです。

GitHub Advisory Databaseは、オープンソースパッケージの脆弱性やマルウェア情報を収録するデータベースです。Dependabotはリポジトリの依存関係とこのデータベースを照合し、問題のあるパッケージやバージョンが見つかった場合に警告を出します。

2026年7月28日から、GitHub Advisory DatabaseはOpenSSFの「malicious-packages」リポジトリに登録されたマルウェア情報を取り込むようになりました。これにより、npmだけでなく、PyPIを含む複数のパッケージエコシステムへ監視範囲が広がっています。(The GitHub Blog)

OpenSSF malicious-packagesとは

OpenSSF malicious-packagesは、オープンソースのパッケージレジストリで発見された悪意あるパッケージの情報を、OSV形式で公開するプロジェクトです。

対象には、次のような攻撃が含まれます。

正規パッケージと似た名前を使うタイポスクワッティング
メンテナーのアカウント乗っ取り
社内パッケージと同名の公開パッケージを利用する依存関係混乱攻撃
インストール時に悪意あるバイナリを取得するパッケージ
認証情報や端末情報を外部へ送信するパッケージ

OpenSSF malicious-packagesは、OSV Schemaが対応するパッケージエコシステムを対象としており、GitHubがこの情報を取り込むことで、Dependabotが利用できるマルウェアデータも広がりました。(GitHub)

今回のデータの流れは、次のように整理できます。

段階	処理内容
OpenSSF	悪意あるパッケージの報告をOSV形式で収集
GitHub Advisory Database	OpenSSF malicious-packagesの情報を取り込み
Dependency graph	リポジトリ内のマニフェストやロックファイルから依存関係を特定
Dependabot	依存パッケージとマルウェア情報を照合
Malware alerts	パッケージ名や対象バージョンが一致した場合に警告を表示

つまり、急にPyPIプロジェクトの安全性が低下したというより、これまでDependabotから見えにくかったマルウェア情報が、GitHub Advisory Database経由で見えるようになったと考えるのが適切です。

Dependabotのマルウェア警告がPyPIなどへ拡大、設定確認のポイント

今回の変更による影響は、現在の設定状態によって異なります。

現在の状態	必要な対応
Dependabot malware alertsが有効	原則として作業不要。拡大された情報が自動反映される
Dependabot alertsのみ有効	Dependabot malware alertsも有効化する
Dependabot alertsが無効	Dependabot alertsを有効化した後、malware alertsを有効化する
多数の組織リポジトリを管理	Custom security configurationで一括設定する
`dependabot.yml`のみ設定済み	Settings画面でアラート機能が有効か別途確認する

特に注意したいのは、.github/dependabot.ymlを作成していても、マルウェア警告が自動的に有効になるとは限らない点です。

dependabot.ymlは主に、依存パッケージのバージョン更新スケジュールや更新プルリクエストを制御するファイルです。Dependabot alerts自体は、リポジトリまたはOrganizationの「Settings」で設定します。(GitHub Docs)

既存のDependabot設定には自動で反映される

すでにDependabot malware alertsを有効化している場合、OpenSSF malicious-packagesの取り込みに合わせて設定を書き換える必要はありません。

GitHubは、マルウェア警告が有効なリポジトリについて、拡大されたGitHub Advisory Databaseの情報を自動的に照合すると説明しています。新しいマルウェア情報が公開され、リポジトリ内の依存関係と一致すれば、新たな警告が作成されます。(The GitHub Blog)

警告は、主に次のタイミングで作成されます。

既存の依存パッケージがGitHub Advisory Databaseでマルウェアとして登録されたとき
既知の悪意あるパッケージを追加するコミットをデフォルトブランチへ反映したとき
依存パッケージを悪意あるバージョンへ更新したとき

Dependabot malware alertsは、リポジトリのデフォルトブランチに含まれる依存関係を基準に検出します。開発ブランチにしか存在しない依存関係や、Dependency graphに認識されていないパッケージは、期待どおりに警告されない可能性があります。(GitHub Docs)

npm以外の対象を確認する方法

GitHub Advisory Databaseでは、検索欄に次の条件を入力すると、マルウェアとして分類されたアドバイザリだけを表示できます。

type:malware

2026年7月28日のGitHub Changelogでも、マルウェア情報の確認方法としてtype:malwareフィルターが案内されています。(The GitHub Blog)

検索後は、エコシステムのフィルターを使って対象を絞り込めます。GitHub Advisory Database上では、npmに加えて、pip、RubyGems、NuGet、Go、Rustなど複数のマルウェア区分が表示されています。(GitHub)

PyPIは「pip」と表示されることがある

Pythonでは、パッケージの公開先を「PyPI」、パッケージ管理ツールやGitHub上のエコシステム名を「pip」と表現することがあります。

そのため、PyPIのパッケージを探しているのに「PyPI」というフィルターが見つからない場合は、pipを確認してください。

GitHubのDependency graphでは、Pythonの代表的な依存関係ファイルとして、次のようなファイルが扱われます。

requirements.txt
Pipfile.lock
Pipfile
setup.py
poetry.lock
pyproject.toml

ロックファイルには実際に使用するバージョンが記録されるため、直接依存だけでなく間接依存を正確に把握するうえでも重要です。(GitHub Docs)

Dependabot malware alertsを有効化する方法

リポジトリ単位で有効化する手順

設定変更には、通常、リポジトリの管理権限が必要です。

GitHubで対象リポジトリを開きます。
リポジトリ上部の「Settings」を開きます。
左側の「Security」セクションから「Advanced Security」を開きます。
「Dependabot alerts」の右側にある「Enable」を選択します。
「Dependabot malware alerts」の右側にある「Enable」を選択します。
「Security and quality」タブを開き、警告が表示されていないか確認します。

Dependabot malware alertsを有効にするには、前提として通常のDependabot alertsが有効になっている必要があります。マルウェア警告だけを単独で有効化することはできません。(GitHub Docs)

有効化後の警告は、次の場所から確認できます。

Security and quality
→ Findings
→ Dependabot
→ Malware

リポジトリだけでなく、OrganizationやEnterpriseの「Security and quality」からもマルウェア警告を横断的に確認できます。(GitHub Docs)

Organizationで一括有効化する手順

多数のリポジトリを管理している場合、リポジトリを一つずつ変更するよりも、Custom security configurationを利用した方が確実です。

基本的な流れは次のとおりです。

Organizationの「Settings」を開きます。
「Advanced Security」から「Configurations」を開きます。
「New configuration」を選択します。
「Custom configuration」を作成します。
「Dependency scanning」内で次の項目を有効にします。

Dependency graph
Dependabot alerts
Malware alerts

設定を保存します。
対象となる既存リポジトリへ設定を適用します。
必要に応じて、新規リポジトリのデフォルト設定に指定します。

新規リポジトリ用のデフォルト設定に指定しても、既存リポジトリへ自動適用されるとは限りません。Organizationへ後から移管されたリポジトリにも、適切なセキュリティ構成を手動で適用する必要があります。(GitHub Docs)

Organization全体で確実に有効化したい場合は、「設定を作った」だけで終わらせず、対象リポジトリへの適用状況まで確認することが重要です。

通常の脆弱性アラートとマルウェア警告の違い

Dependabotの通常アラートとマルウェア警告は、表示場所が似ていても対応方法が異なります。

比較項目	通常の脆弱性アラート	マルウェア警告
主な問題	正規パッケージに脆弱性がある	パッケージまたは特定バージョンに悪意あるコードが含まれる
典型的な対応	修正版へアップデート	削除、代替パッケージへの変更、影響調査
修正版	用意されている場合が多い	存在しない場合がある
自動修正PR	条件を満たせば作成可能	原則として自動修正PRの対象外
追加調査	脆弱性の悪用可能性を確認	実行履歴、通信、認証情報流出などを確認

GitHubのドキュメントでは、Dependabotによる修正プルリクエストは通常のDependabot alertsを対象としており、Dependabot malware alertsを解決するプルリクエストは自動作成しないと説明されています。(GitHub Docs)

そのため、マルウェア警告に対して「Dependabotが自動で安全なバージョンへ更新してくれる」と考えるのは危険です。

マルウェア警告が出たときの対応手順

マルウェア警告では、パッケージを削除するだけでなく、すでに実行された可能性を確認する必要があります。

影響を受けるファイルとバージョンを確認する

警告画面を開き、次の情報を確認します。

パッケージ名
該当バージョン
影響を受けるマニフェストまたはロックファイル
直接依存か間接依存か
修正版の有無
GitHubが提示する修復手順

Dependabot malware alertsには、影響を受けるファイルへのリンク、対象バージョン、修正版がある場合はその情報、推奨される対応方法などが表示されます。(GitHub Docs)

実行された環境を特定する

次に、問題のパッケージがインストールまたは実行された環境を確認します。

状況	優先する対応
ロックファイルに追加されただけで未実行	パッケージを削除し、ロックファイルを再生成
開発端末でインストール済み	端末の通信、プロセス、認証情報を確認
CIで実行済み	GitHub ActionsやCIのシークレット、トークンを確認
本番環境へデプロイ済み	インシデント対応として影響範囲を調査
コンテナイメージに含まれる	安全な依存関係でイメージを再ビルド

マルウェアがインストールスクリプトで動作するタイプの場合、アプリケーションを起動していなくても、npm installやpip installの時点でコードが実行されている可能性があります。

認証情報を必要に応じて更新する

問題のパッケージが実行された可能性がある場合は、次の情報が取得されていないか確認します。

GitHub Personal Access Token
npmやPyPIの公開用トークン
クラウドサービスのアクセスキー
CI/CD用のシークレット
SSH鍵
.envファイルの内容
データベース接続情報

漏えいの可能性を否定できない認証情報は、無効化またはローテーションします。パッケージを削除しても、すでに外部へ送信された認証情報までは無効になりません。

クリーンな環境で再構築する

対応後は、既存のキャッシュや生成物をそのまま使わず、次の作業を行います。

問題のパッケージをマニフェストから削除
ロックファイルを再生成
パッケージキャッシュを確認または削除
クリーンな環境で依存関係を再インストール
コンテナイメージやビルド成果物を再作成
CI/CDを再実行する前にシークレットを更新

特にCIのキャッシュに悪意あるパッケージが残っている場合、マニフェストを修正しても再利用される可能性があります。

誤検知が疑われる場合の確認方法

Dependabot malware alertsでは、社内パッケージと公開パッケージの名前、エコシステム、バージョンが一致した場合に、誤検知が発生する可能性があります。(GitHub Docs)

たとえば、社内専用のPythonパッケージとしてcompany-utilsのバージョン1.0.0を利用している一方、PyPI上に同名・同バージョンの悪意あるパッケージが存在すると、公開パッケージと誤認される可能性があります。

誤検知が疑われる場合は、次の点を確認します。

実際に取得したパッケージレジストリ
ロックファイルに記録された取得元
パッケージのハッシュ値
社内レジストリのログ
CIが参照しているレジストリ設定
公開レジストリへフォールバックする設定の有無

安全であることを確認できた場合は、警告をDismissできます。その際は、監査や将来の再確認に備えて、社内パッケージであることや取得元をコメントに記録しておくとよいでしょう。GitHubでは、Dismiss時のコメントをアラートのタイムラインへ残せます。(GitHub Docs)

根拠を確認しないまま、パッケージ名だけを見て一括Dismissするのは避けてください。

有効化しても警告が出ない場合の確認ポイント

Dependabot malware alertsを有効にしても警告が表示されない場合は、次の項目を順番に確認します。

2つの設定が両方有効か

次の両方が「Enabled」になっている必要があります。

Dependabot alerts
Dependabot malware alerts

通常のDependabot alertsが無効なままでは、マルウェア警告も機能しません。

Dependency graphにパッケージが表示されているか

DependabotはDependency graphで認識した依存関係を利用します。

リポジトリのDependency graphを開き、対象パッケージと実際のバージョンが表示されているか確認してください。表示されていなければ、マニフェストやロックファイルが認識されていない可能性があります。

デフォルトブランチに依存関係があるか

Dependabot malware alertsは、デフォルトブランチの依存関係を基準にします。

機能ブランチだけに悪意あるパッケージが存在し、まだデフォルトブランチへマージされていない場合、リポジトリの通常スキャンでは検出されない可能性があります。

リポジトリがアーカイブされていないか

Dependabotはアーカイブ済みリポジトリをスキャンしません。過去のアプリケーションを再利用する予定がある場合は、アーカイブ解除後に依存関係を確認する必要があります。(GitHub Docs)

メールだけで判断していないか

Dependabotを初めて有効化した場合、既存のすべての問題についてメール通知が届くとは限りません。

通知がなかったとしても、次の画面を直接確認してください。

Security and quality
→ Findings
→ Dependabot
→ Malware

GitHubは、初回有効化時に検出された既存の依存関係について、すべてを新着メールとして通知するわけではないと説明しています。(GitHub Docs)

公式ドキュメントの「npmのみ」という記載に注意

2026年8月1日時点では、GitHubのDependabot malware alertsに関する一部の概念ドキュメントに、「現在はnpmエコシステムで利用可能」という記載が残っています。(GitHub Docs)

一方、2026年7月28日のGitHub Changelogでは、OpenSSF malicious-packagesの取り込みにより、PyPIなどnpm以外へ対象が拡大したことが明記されています。また、実際のGitHub Advisory Databaseでも、pipを含む複数エコシステムのマルウェア情報を確認できます。(The GitHub Blog)

これは更新直後のドキュメント反映時差とみられます。対象範囲を判断するときは、次の順序で確認すると確実です。

最新のGitHub Changelog
GitHub Advisory Databaseのtype:malware検索
リポジトリの実際の設定画面
Security and qualityに表示される警告

まず確認すべき3つの項目

Dependabotのマルウェア警告拡大に対応するため、最初に次の3点を確認してください。

リポジトリで「Dependabot malware alerts」が有効になっているか
type:malwareで、自分が利用するエコシステムの情報を確認できるか
警告発生時の担当者と、認証情報ローテーションを含む対応手順が決まっているか

すでにマルウェア警告が有効なら、OpenSSF malicious-packagesによる対象拡大は自動反映されます。未設定なら、「Settings」からDependabot alertsとDependabot malware alertsを有効にしてください。

重要なのは、マルウェア警告を通常のバージョン更新通知として扱わないことです。警告が出た場合は、パッケージの削除だけでなく、インストール履歴、CI/CD、認証情報、デプロイ済み環境まで確認する必要があります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。