GitHubのSBOMでライセンス表示が以前と変わっていても、依存パッケージ自体の利用条件が変更されたとは限りません。GitHubは2026年8月13日、dependency graphのライセンス情報について、ClearlyDefined中心から、npm・NuGet・PyPIなどのレジストリ情報を優先する方式への変更を発表しました。ClearlyDefinedは、補完する情報源として引き続き利用されます。(The GitHub Blog)
表示が変わったときに最初に行うべきことは、依存パッケージの更新やチェックの無効化ではありません。過去と現在のSBOMを同じパッケージ・同じバージョンで比較し、変更理由を確認してから、Dependency Reviewや社内のライセンス判定を再評価することです。
この記事では、判定元変更の対象、バージョン別に確認すべき理由、SBOMの比較手順、自動チェックで見落としやすい点を解説します。
GitHubのライセンス判定元変更で何が変わったのか
エコシステムごとのレジストリ情報を優先する
今回の変更対象は、GitHub dependency graphが扱う依存パッケージのライセンス情報です。依存関係インサイト、SBOM、GitHub Advanced SecurityのOSSライセンスコンプライアンス機能、Dependency Review Actionに影響します。GitHubが公表した優先参照先は、次のとおりです。(The GitHub Blog)
| パッケージエコシステム | ライセンス情報の優先参照先 |
|---|---|
| npm | npmjs.org |
| NuGet | nuget.org |
| Python | pypi.org |
| RubyGems | rubygems.org |
| Rust | crates.io |
| Go | pkg.go.dev |
| Maven | deps.dev |
| Dart | pub.dev |
| PHP | packagist.org |
この一覧は、GitHubがライセンス情報を取得する参照先を示しています。利用者がnpmの接続先やNuGetのフィード設定を変更する、という話ではありません。
ライセンス履歴をバージョン範囲で管理する
ライセンス履歴については、バージョンごとに個別のデータを登録する方式ではなく、バージョン範囲に対応づけて管理する方式になりました。これにより、各バージョンを一つずつ登録しなくても、新しいバージョンにライセンス情報を適用しやすくなります。(The GitHub Blog)
例えば、仮にあるライブラリが「1.xではMIT、2.xからApache-2.0」という履歴を持つ場合、1.8.0を利用しているプロジェクトと2.1.0を利用しているプロジェクトは、別々に確認する必要があります。
調査時に最新版のページだけを見ると、利用中の旧バージョンとは異なる条件を参照しかねません。ライセンス台帳にも、パッケージ名だけでなく、確認した具体的なバージョンを残す運用にしましょう。
SBOMの表示変更と実際のライセンス変更を切り分ける
SBOMは、ソフトウェアの依存関係と、そのバージョン、識別子、ライセンスなどを記録した一覧です。GitHubでは、dependency graphの現在の状態をSPDX形式でエクスポートできます。(GitHub Docs)
そのため、過去のSBOMとの差分を調べる際は、「使っている部品が変わったのか」と「部品に付随する情報が変わったのか」を分けて整理すると、調査対象を絞り込めます。
次の表は、差分調査の判断例です。表示だけで原因を確定するものではありません。
| 見つかった差分 | 考えられる原因 | 最初に確認すること |
|---|---|---|
| 同じバージョンで、不明だったライセンスが表示された | ライセンス情報が補完された可能性 | 新しい表記が社内の許可条件に合うか |
| 同じバージョンで、別のライセンス表記になった | 情報源の変更やメタデータの修正の可能性 | 当該バージョンの公開情報と同梱ライセンス |
| バージョン更新と同時にライセンスも変わった | 実際にライセンスが切り替わった可能性 | 更新前後の配布物、リリース情報、ライセンス文書 |
| 複数ライセンスの表記が単一になった | 参照情報や集計対象が異なる可能性 | 同梱コードやサブコンポーネントの扱い |
特に、ライセンス表記が短くなったことを、確認対象が減った証拠にしないことが重要です。
ClearlyDefinedでは、コンポーネント全体として宣言されているライセンスと、内部のファイルやサブコンポーネントから検出されたライセンスを区別しています。パッケージ全体の表記だけでは、同梱ファイル側の情報まで説明できない場合があります。(ClearlyDefined)
GitHubのSBOMを再確認する手順
過去のSBOMを上書きせずに保存する
まず、過去に取得したSBOMがあれば、そのまま保存してください。現在のファイルで上書きすると、表示がどのように変わったのかを説明しにくくなります。
比較用の記録には、取得日時、対象リポジトリ、対象のリリースやコミット、依存関係を収集した方法を添えておくと便利です。社内ツールで判定していた場合は、そのツールの設定や当時の承認記録もまとめます。
過去のSBOMがない場合は、現在の出力を基準として保存します。「以前は別のライセンスだった」と推測で記録せず、確認できた事実と未確認事項を分けましょう。
現在のSBOMをGitHubから取得する
GitHubの画面では、次の手順でSBOMを取得できます。(GitHub Docs)
- 対象リポジトリを開き、［Insights］を選択します。
- 左側の［Dependency graph］を開きます。
- ［Dependencies］タブの［Export SBOM］を選択します。
- 生成されたファイルを、過去のSBOMとは別の名前で保存します。
ここで取得できるのは、dependency graphの現在の状態です。過去の出力と比較するときは、途中で依存パッケージの追加・削除・更新が発生していないかも確認してください。(GitHub Docs)
同じパッケージ・同じバージョンを対応づける
JSONファイル全体をそのまま比較するだけでなく、パッケージごとの比較表にすると確認しやすくなります。
GitHubのSBOMの例では、パッケージ名はname、バージョンはversionInfoに記録されます。また、externalRefsには、パッケージを識別するPURLが含まれる場合があります。PURLを確認すると、同名でも異なるエコシステムのパッケージを取り違えにくくなります。(GitHub Docs)
比較表は、次のような列で作ると実務に使いやすくなります。
| 比較する項目 | 確認する目的 |
|---|---|
| パッケージ名・エコシステム・PURL | 同じ対象を比較しているか確認する |
| バージョン | 構成変更と情報変更を切り分ける |
| 変更前・変更後のライセンス表記 | 判定に使われる値の差分を確認する |
| 変更前・変更後の社内判定 | 許可・要確認・禁止などの扱いが変わるか確認する |
| 確認根拠・確認日・承認者 | 後から判断理由を説明できるようにする |
SPDXでは、licenseDeclaredはパッケージの作成者が宣言したライセンス、licenseConcludedはSBOM作成者が判断したライセンスを表す項目です。両方ある場合は別々に確認し、異なる項目を比較して「変更された」と判断しないようにします。(SPDX)
差分があるパッケージを元の資料と照合する
差分が見つかったら、対象バージョンのレジストリ情報、配布物に同梱されたLICENSEやCOPYING、対応するソースコードのタグなどを照合します。メタデータと同梱ファイルが食い違う場合は、推測でどちらかを採用せず、公開者への確認が必要です。ClearlyDefinedのガイドラインでも、こうした情報の不一致は公開者への問い合わせ対象とされています。(ClearlyDefined)
この確認では、最新ブランチのLICENSEだけで済ませないことが重要です。調べる対象は、実際に使っているバージョンと配布物です。
下流のライセンス判定を再実行する
元の情報を確認したら、GitHubのSBOMを取り込んでいる社内ツール、CI、ライセンス台帳などでも判定をやり直します。
確認対象は「新たに不合格になったもの」だけではありません。以前は要確認だった依存関係が自動承認へ変わった場合も、その変化が意図したものか確認してください。
監査記録には、単に「ライセンス変更」と書くより、「依存バージョンは変更なし。SBOM上のライセンス情報が更新され、当該版の配布物と照合して再承認」のように、確認できた経緯を残すほうが有用です。
Dependency Review Actionで確認すべき設定と挙動
ライセンス不明でもActionが成功する場合がある
Dependency Review Actionの公式説明では、依存関係のライセンスを検出できない場合は通知されますが、それだけではActionは失敗しません。したがって、チェック成功を「すべての依存関係のライセンスが確認済み」と読み替えないようにしてください。(GitHub)
例えば、あるPRで追加する依存関係が、以前はライセンス不明だったとします。その後、Apache-2.0と判定できるようになり、設定が「MITのみ許可」だった場合は、再評価で結果が変わる可能性があります。
この場合は、パッケージの利用条件がその時点で変わったのではなく、不明だった情報が埋まり、既存のルールに照らして判定できるようになった可能性を調べます。
また、Dependency Review ActionはPRの依存関係の変更を検査する仕組みです。既存の依存関係全体を棚卸しする作業と、PRのチェックを再実行する作業は分けて考えましょう。(GitHub)
許可リストと例外設定を点検する
既存のワークフローでは、特に次の設定を確認します。
license-check：ライセンスチェックを無効にしていないか。allow-licenses：社内で承認したライセンスやSPDX式を適切に指定しているか。allow-dependencies-licenses：特定のパッケージを、ライセンスチェックから除外していないか。
これらは役割が異なります。パッケージ単位の除外設定は、そのパッケージのライセンスを確認済みにする機能ではありません。(GitHub)
現行の公式READMEでは、deny-licensesは非推奨とされています。また、allow-licensesとdeny-licensesは併用できません。既存設定を見直す際は、禁止リストを追加し続けるだけでなく、許可リスト方式で運用できるか検討してください。(GitHub)
設定が外部ファイルに分離されている場合もあります。ワークフローのwithだけでなく、config-fileで指定された設定ファイルも確認します。(GitHub Docs)
原因が分からないままチェック全体を無効化するのは避けましょう。例外が必要な場合は、対象、根拠、承認者、再確認期限を記録して管理する方法が適しています。
Enterpriseのライセンスポリシーも別途確認する
EnterpriseのOSSライセンスコンプライアンス機能を導入している場合は、企業全体のライセンスポリシーと、リポジトリに適用されるルールセットも確認対象です。この機能では、dependency graphで検出された間接依存も評価に使われ、パッケージやライセンスの例外を管理できます。Actionの設定だけを直して完了にしないようにしましょう。(GitHub Docs)
ライセンス表示を読むときに間違えやすいポイント
NOASSERTIONは「制約なし」ではない
SPDXのNOASSERTIONは、ライセンスについて判断できなかった、調査していない、情報を提示していない、といった状態を表します。「自由に利用できる」「ライセンス上の制約がない」という意味ではありません。(SPDX)
社内ツールが空欄やNOASSERTIONを自動的に許可へ分類している場合は、確認が必要な項目として分離する設計を検討してください。情報がない状態と、確認したうえで許可した状態を同じ扱いにしないことが重要です。
ANDとORを同じ意味で処理しない
SPDXのライセンス式では、ANDとORの意味が異なります。
MIT OR Apache-2.0は、提示されたライセンスから選択できることを表します。一方、MIT AND Apache-2.0は、両方への対応が必要であることを表します。例外条項を表すWITHも別の演算子です。(SPDX)
独自スクリプトで「文字列にMITが含まれていれば許可」と判定している場合、こうした違いを取り落とします。表記を比較する際も、ライセンス名だけを抜き出して並べ替えるのではなく、式の意味を保持して扱いましょう。
リポジトリのLICENSE表示とは別の仕組みである
GitHubのリポジトリ画面に表示されるプロジェクト自身のライセンスと、dependency graphに表示される依存パッケージのライセンスは、確認対象が異なります。
リポジトリのライセンス検出について、GitHubはLicenseeがLICENSEファイルを既知のライセンスと比較する仕組みを説明しています。依存パッケージの表示が変わったからといって、自分のリポジトリのLICENSEを書き換える必要が生じたわけではありません。(GitHub Docs)
パッケージ公開者はレジストリ側のメタデータも確認する
自分たちでパッケージを公開している場合は、リポジトリのREADMEだけでなく、利用者に配布されるパッケージのメタデータと内容も点検します。
代表的なエコシステムでは、次の項目が確認箇所になります。
| エコシステム | 確認するメタデータ・ファイル |
|---|---|
| npm | package.jsonのlicense。独自ライセンスなどでSEE LICENSE INを使う場合は、指定ファイルの同梱状態。(npm公式ドキュメント) |
| NuGet | .nuspecのlicense。SPDX式を指定する形式と、パッケージ内のライセンスファイルを指定する形式の内容。(Microsoft Learn) |
| Python／PyPI | 対応する配布物のLicense-Expression、License-File、実際に含まれるライセンス関連ファイル。(Python Packaging) |
Pythonでは、License-Expressionはそのメタデータを含む配布アーカイブに適用される情報です。プロジェクト全体や、別の配布ファイルにも同じ内容が適用されると決めつけないようにします。(Python Packaging)
修正後は、リポジトリ上の記述だけで完了とせず、公開先の表示と利用者が取得する配布物まで確認し、SBOMを再取得して結果を確かめてください。
まずは主要リポジトリのSBOM差分を確認する
今回の変更への対応で重要なのは、ライセンス表示の差分を見つけたときに、依存パッケージが変わったのか、ライセンス情報だけが変わったのかを説明できる状態にすることです。
まず、本番サービスや配布製品に使っている主要リポジトリを一つ選び、過去のSBOMを保全したうえで現在のSBOMを取得してください。同じパッケージ・同じバージョンのライセンス表記を比較し、差分があるものから元の資料と照合します。
その結果をDependency Review、社内の許可ルール、ライセンス台帳に反映すれば、表示変更を理由の分からない警告として扱うのではなく、確認可能な情報更新として管理できます。
コメント