2026年5月5日に確認すべき「GitHub Docs documentation update: Remove suggestion to use already deprecated options」の結論は、GitHub Docs上で非推奨オプションである deny-licenses の利用を推奨するように見える記述を整理し、Dependency review actionの現在の方針に合わせる動きだということです。すぐに全リポジトリのCIが止まる変更ではありませんが、.github/workflows や外部設定ファイルで deny-licenses を使っているチームは、将来の削除可能性を見据えて allow-licenses への移行方針を確認しておくべきです。GitHub公式のDependency review action READMEでは、deny-licenses は将来のメジャーリリースで削除される可能性がある非推奨オプションとして説明されています。(GitHub)
GitHub Docs documentation update: Remove suggestion to use already deprecated optionsの要点
今回の「GitHub Docs documentation update: Remove suggestion to use already deprecated options」は、GitHub Docsの記述をDependency review actionの実態に合わせるためのドキュメント更新です。中心になるのは、ライセンス制御に使われる deny-licenses です。
GitHub DocsのPR #42610では、Dependency review actionの設定ドキュメントとチュートリアルの2ファイルが対象になっています。変更内容は、deny-licenses に将来削除の可能性がある旨を追加すること、チュートリアル内の例を deny-licenses から allow-licenses に置き換えること、さらに「許可リストより拒否リストを選ぶべき」と読めるベストプラクティスを削除することです。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 対象サービス | GitHub Docs、GitHub ActionsのDependency review action |
| 主な対象オプション | deny-licenses |
| 変更の性質 | 機能追加ではなく、非推奨オプションを推奨しないためのドキュメント修正 |
| 影響を受けやすい人 | GitHub Actionsで依存関係レビューを必須チェックにしている開発チーム、セキュリティ担当、社内CIテンプレート管理者 |
| すぐやること | deny-licenses を使っているワークフローや設定ファイルを棚卸しする |
| 注意点 | deny-licenses を単純に allow-licenses へ名前だけ置き換えると、判定ロジックが大きく変わる |
重要なのは、これは「deny-licenses が今すぐ動かなくなる」という発表ではない点です。一方で、公式READMEで非推奨とされ、将来のメジャーリリースで削除される可能性が示されているため、長期運用するCI設定では放置しないほうが安全です。(GitHub)
そもそもDependency review actionとは
Dependency review actionは、プルリクエストで追加・更新される依存関係を確認し、脆弱な依存関係やライセンス上問題のある依存関係を検出するGitHub Actionsのアクションです。GitHub Docsでは、Dependency reviewはプルリクエストごとに依存関係の変更とセキュリティ影響を把握するための機能として説明されています。(GitHub Docs)
たとえば、次のような場面で使われます。
- npm、Maven、pipなどの依存パッケージ更新時に、既知の脆弱性を含むバージョンをブロックする
- プルリクエストで追加されたライブラリのライセンスを確認する
fail-on-severityを使い、一定以上の深刻度の脆弱性が含まれる場合にCIを失敗させる- ブランチ保護やルールセットと組み合わせ、Dependency review actionの成功をマージ条件にする
GitHub Docsでは、Dependency review actionが脆弱な依存関係を検出した場合、設定によってチェックを失敗させ、必要なステータスチェックとして設定されていればマージをブロックできると説明されています。(GitHub Docs)
何が変わるのか：deny-licensesの扱いが変わる
今回のGitHub Docs documentation updateで最も注目すべき点は、deny-licenses を「推奨される設定例」として扱わない方向へドキュメントを修正していることです。
deny-licenses は、指定したライセンスを持つ依存関係がプルリクエストで追加された場合にアクションを失敗させる設定です。一方、allow-licenses は、指定したライセンスだけを許可し、それ以外のライセンスを持つ依存関係を失敗させる設定です。
| オプション | 考え方 | 例 | 実務上の意味 |
|---|---|---|---|
deny-licenses | 指定したライセンスを拒否する | GPL系、AGPL系などを拒否 | 「禁止したいもの」を列挙する方式 |
allow-licenses | 指定したライセンスだけを許可する | MIT、Apache-2.0、BSD系などを許可 | 「使ってよいもの」を列挙する方式 |
allow-dependencies-licenses | 特定パッケージをライセンスチェックから除外する | レビュー済みパッケージをpurl形式で指定 | 例外管理に使う方式 |
Dependency review actionのREADMEでは、allow-licenses と deny-licenses は同時に指定できず、両方を指定するとエラーになる旨も説明されています。(GitHub)
なぜdeny-licensesの推奨が外されるのか
deny-licenses の問題は、拒否リスト方式だと「知らないリスク」を取りこぼしやすいことです。
たとえば、社内ルールで「強いコピーレフトライセンスは避ける」と決めている場合、GPL-2.0 と GPL-3.0 だけを deny-licenses に入れても、ほかの注意すべきライセンスや商用利用上の制約があるライセンスを漏らす可能性があります。実際、Dependency review action側のIssue #938では、ライセンス拒否リストは限定的なリスク低減にしかならないという問題意識が示され、4.x系で非推奨化し、将来の5.x系で削除する準備として扱う方針が議論されています。(GitHub)
許可リスト方式の allow-licenses は、運用開始時の設計は少し重くなります。しかし、組織として利用可能なライセンスを明確に定義できるため、サプライチェーン管理や監査の観点では扱いやすくなります。
対応すべきチームと影響範囲
今回の変更は、GitHub Docsの文章だけを読んでいる人よりも、実際にDependency review actionを運用しているチームに影響します。特に、社内テンプレートや複数リポジトリへ展開しているワークフローに deny-licenses が含まれている場合は、早めに確認してください。
| 対象 | 影響 | 対応優先度 |
|---|---|---|
.github/workflows/*.yml で deny-licenses を使っているリポジトリ | 将来のメジャーリリースで設定変更が必要になる可能性 | 高 |
外部設定ファイルで deny-licenses を使っているリポジトリ | 共通設定のため複数リポジトリに影響しやすい | 高 |
社内のGitHub Actionsテンプレートに deny-licenses を含めている組織 | 新規リポジトリへ非推奨設定を広げる可能性 | 高 |
| ライセンスチェックをしておらず、脆弱性チェックだけ使っているリポジトリ | 直接影響は小さい | 低 |
| GitHub Docsのサンプルを社内資料に転載しているチーム | 古い推奨が残る可能性 | 中 |
| ブランチ保護でDependency review actionを必須にしているチーム | 移行後の失敗がマージ停止につながる可能性 | 高 |
なお、GitHub DocsのPR #42610はGitHub上でOpenと表示されています。実際に本番のGitHub Docsへ反映済みかどうかは、利用しているGitHub Docsの該当ページや表示バージョンで確認してください。(GitHub)
まず確認すべき設定ファイル
最初に見るべき場所は、リポジトリ内のGitHub Actionsワークフローです。
grep -R "deny-licenses\|allow-licenses\|allow-dependencies-licenses" .github複数リポジトリを管理している場合は、GitHubのコード検索で次のような条件を使うと効率的です。
org:YOUR_ORG deny-licenses path:.github
org:YOUR_ORG dependency-review-action deny-licenses確認対象は、ワークフローだけではありません。Dependency review actionは外部設定ファイルを参照できるため、次のようなファイルも確認してください。
.github/dependency-review-config.yml
.github/dependency-review-config.yaml
.github/workflows/dependency-review.yml
.github/workflows/security.yml
社内で配布している再利用ワークフロー
組織共通のCIテンプレートDependency review actionのREADMEでは、設定方法としてワークフローファイルに直接書く方法と、config-file で外部設定ファイルを参照する方法が説明されています。外部設定ファイルを使っている場合、1つの設定変更が多くのリポジトリに影響するため、特に慎重に確認しましょう。(GitHub)
deny-licensesからallow-licensesへ移行するときの考え方
最も危険なのは、deny-licenses を allow-licenses に機械的に置き換えることです。両者は意味が逆に近いため、値をそのまま移すと意図しない判定になります。
たとえば、次の設定は「GPL-3.0とAGPL-3.0を拒否する」という意味です。
with:
fail-on-severity: moderate
deny-licenses: GPL-3.0, AGPL-3.0これを単純に次のようへ置き換えると、「GPL-3.0とAGPL-3.0だけを許可する」という意味になってしまいます。
with:
fail-on-severity: moderate
allow-licenses: GPL-3.0, AGPL-3.0これは多くの組織にとって、元の意図と逆です。allow-licenses に移行する場合は、拒否したいライセンスではなく、利用を許可するライセンスを列挙する必要があります。
たとえば、一般的なOSS利用ポリシーで許可対象を明確にするなら、次のような形を検討します。実際の可否は、必ず自社の法務・セキュリティポリシーに合わせて判断してください。
with:
fail-on-severity: moderate
allow-licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISCこの設定では、列挙したライセンス以外の依存関係が追加された場合にアクションが失敗します。つまり、開発者はプルリクエストの時点で「このライセンスは組織として許可されているか」を確認できます。
移行時の実務手順
deny-licenses を使っている場合は、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 判断ポイント |
|---|---|---|
| 1 | deny-licenses の利用箇所を洗い出す | ワークフロー、外部設定、社内テンプレートを含める |
| 2 | 現在の拒否リストの意図を確認する | セキュリティ目的か、法務・コンプライアンス目的か |
| 3 | 許可するライセンス一覧を作る | MIT、Apache-2.0など、組織として許可できるものを明文化する |
| 4 | 例外管理の方法を決める | 特定パッケージのみ許可する場合は allow-dependencies-licenses を検討する |
| 5 | 影響の小さいリポジトリでテストする | Dependabot PRや通常の依存関係更新PRで動作を見る |
| 6 | ブランチ保護・ルールセットと合わせて展開する | 必須チェックの場合、失敗時にマージが止まることを周知する |
特定の依存関係をレビュー済みとして例外扱いしたい場合は、allow-dependencies-licenses を使う選択肢があります。Dependency review actionのREADMEでは、パッケージをpurl形式で指定してライセンスチェックから除外できる設定として説明されています。(GitHub)
with:
fail-on-severity: moderate
allow-licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC
allow-dependencies-licenses: "pkg:npm/@example/[email protected]"例外は便利ですが、無制限に増やすとライセンスチェックの意味が薄れます。例外を追加するときは、理由、承認者、確認日、対象バージョンを社内のチケットや台帳に残す運用が現実的です。
設定変更で失敗しやすいポイント
deny-licenses から allow-licenses へ移行するときは、単なるYAML修正ではなく、ライセンスポリシーの見直しとして扱う必要があります。
| 失敗例 | 何が起きるか | 回避策 |
|---|---|---|
deny-licenses の値をそのまま allow-licenses に移す | 以前は拒否していたライセンスだけを許可してしまう | 許可したいライセンス一覧を新しく作る |
allow-licenses と deny-licenses を両方書く | Dependency review actionがエラーになる可能性 | どちらか一方だけを使う |
| 許可リストを狭くしすぎる | Dependabot PRや通常の依存関係追加が頻繁に失敗する | 主要な利用ライセンスを棚卸ししてから適用する |
| ブランチ保護を考慮せずに変更する | CI失敗がマージ停止につながる | 必須チェックの対象リポジトリから優先してテストする |
| 社内ドキュメントだけ古いまま残る | 新規プロジェクトが非推奨設定をコピーする | テンプレート、README、オンボーディング資料も更新する |
| 法務確認なしで許可リストを作る | 組織のライセンスポリシーとずれる | セキュリティ担当だけでなく法務・OSS管理担当も巻き込む |
特に注意したいのは、allow-licenses は「列挙していないものを拒否する」設定だという点です。拒否リスト方式より安全側に倒しやすい反面、最初の設計が雑だと開発体験を悪化させます。
GitHub Enterprise Server利用時の確認ポイント
GitHub Enterprise Serverを利用している場合は、GitHub.comと同じ感覚でライセンスチェックを前提にしないほうが安全です。Dependency review actionのREADMEでは、ライセンスチェックがGitHub Enterprise Serverではサポートされない旨の注記があります。これはAPIがライセンス情報を返さないためと説明されています。(GitHub)
そのため、GHES環境では次の観点で確認してください。
| 確認項目 | 見るべき内容 |
|---|---|
| 利用中のGitHub Enterprise Serverバージョン | Dependency review actionの対応状況 |
| ライセンス情報の取得可否 | allow-licenses や deny-licenses が期待どおり動くか |
| 代替運用 | SBOM、社内OSS審査、別ツールでのライセンススキャン |
| 必須チェック設定 | 動作しないチェックをマージ条件にしていないか |
GitHub.comで運用しているチームは、まず deny-licenses の棚卸しと allow-licenses への移行方針を検討するのが現実的です。一方、GHES利用チームは、Dependency review actionのライセンス関連オプションが自社環境で利用可能かを先に確認してください。
既存のGitHub Docsサンプルをコピーしている場合の注意
GitHub DocsのPR #42610は、チュートリアル内で deny-licenses を使っていた例を allow-licenses に変更する内容を含んでいます。あわせて、「許可リストより拒否リストを選ぶ」「許可するライセンスを指定するよりブロックするライセンスを選ぶ」といった趣旨のベストプラクティスを削除しています。(GitHub)
社内Wikiやオンボーディング資料に過去のGitHub Docsサンプルを転載している場合、古い内容が残っている可能性があります。特に次のような資料は見直しましょう。
- 新規リポジトリ作成時のGitHub Actionsテンプレート
- セキュリティチェック導入手順
- DependabotやDependency reviewの社内ガイド
- OSSライセンス確認フロー
- GitHub Actionsの再利用ワークフロー
公開ドキュメントだけでなく、開発者が日常的にコピーするテンプレートを更新することが重要です。古いテンプレートが残っていると、非推奨設定が新規プロジェクトへ再び広がってしまいます。
推奨される設定例
次の例は、脆弱性チェックとライセンス許可リストを組み合わせる基本形です。
name: Dependency Review
on:
pull_request:
permissions:
contents: read
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Dependency Review
uses: actions/dependency-review-action@v4
with:
fail-on-severity: moderate
allow-licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC外部設定ファイルで管理する場合は、ワークフロー側をシンプルにできます。
name: Dependency Review
on:
pull_request:
permissions:
contents: read
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Dependency Review
uses: actions/dependency-review-action@v4
with:
config-file: './.github/dependency-review-config.yml'設定ファイル側は次のように管理します。
fail-on-severity: moderate
allow-licenses:
- MIT
- Apache-2.0
- BSD-2-Clause
- BSD-3-Clause
- ISC
allow-dependencies-licenses:
- pkg:npm/@example/[email protected]組織で複数リポジトリを管理しているなら、外部設定ファイルや再利用ワークフローを使うと、ライセンスポリシーの変更を一元管理しやすくなります。ただし、一括変更は影響範囲も大きくなるため、最初は代表的なリポジトリで検証してから展開してください。
今回の更新で変わらないこと
今回のGitHub Docs documentation updateは、Dependency review actionのすべての設定を変更するものではありません。次の点は基本的に変わりません。
| 項目 | 変わらない内容 |
|---|---|
| 脆弱性チェック | fail-on-severity による深刻度ベースの判定は引き続き重要 |
| プルリクエストでの確認 | 依存関係変更をPR時点で検出する役割は変わらない |
| ブランチ保護との連携 | 必須ステータスチェックにしていれば失敗時にマージを止められる |
allow-licenses の役割 | 許可されたライセンスだけを通す設定として使う |
| 例外管理 | allow-dependencies-licenses による特定パッケージの例外指定は引き続き検討対象 |
つまり、対応の中心は「Dependency review actionをやめること」ではなく、「ライセンス制御を非推奨の拒否リスト方式から、より明確な許可リスト方式へ見直すこと」です。
次に取るべき行動
まず、リポジトリや組織全体で deny-licenses を検索してください。該当がなければ、今回の変更による直接的な作業は少ないはずです。ただし、社内テンプレートやドキュメントに古いサンプルが残っていないかは確認しておくとよいでしょう。
deny-licenses が見つかった場合は、すぐにキー名だけを置き換えず、現在の拒否リストが何を守ろうとしていたのかを整理してください。そのうえで、組織として許可するライセンス一覧を作り、allow-licenses で表現できるか検討します。例外が必要な依存関係は、個別にレビューして allow-dependencies-licenses で管理するのが現実的です。
今回のGitHub Docs documentation update: Remove suggestion to use already deprecated optionsは、単なる文言修正に見えます。しかし実務では、CIテンプレート、ライセンス審査、ブランチ保護、社内ドキュメントを見直すきっかけになります。まずは deny-licenses の利用箇所を洗い出し、開発を止めずに移行できる小さな検証リポジトリから着手しましょう。
コメント