タグアーカイブ DevSecOps

GitHubが依存関係のライセンス遵守を自動化する新機能を発表

GitHubは2026年6月30日、オープンソースの依存関係におけるライセンス遵守を自動化する「License Compliance」機能を公開プレビューとして発表した。GitHub Advanced Security（GHAS）のCode Securityライセンスを持つEnterprise Cloudユーザーが対象だ。

この機能はPull Request上で新たに追加される依存関係のライセンスを自動スキャンし、組織のポリシーに反するものがあればアラートを出す。GitHub自身のOpen Source Program Office（OSPO）も数カ月前からこの機能に移行し、社内ツールを置き換えた実績がある。

ソフトウェア開発において依存関係のライセンス管理は、後回しにされがちな領域だ。しかし、ライセンス違反は訴訟リスクやコードの公開義務といった深刻な結果を招く。この記事では、GitHubの新機能の仕組みと、実際に運用する組織がどのようにポリシーを設計すべきかを解説する。

オープンソースライセンスの遵守が企業にとって重大な理由

ほぼすべてのソフトウェアには何らかのライセンスが付与されている。ライセンスはそのプロジェクトを利用する許可を与えるが、同時に遵守すべき義務も課す。義務の内容は、ドキュメントに原著作者のクレジットを記載するだけの緩やかなものから、プログラムを配布する際に自社の全ソースコードを公開しなければならない強力なものまで幅広い。

商用ソフトウェアにおけるリスク

商用のクローズドソース製品を販売する組織であれば、GPL系のライセンスを持つ依存関係をうっかり混入させると、自社のプロプライエタリなコード全体をオープンソース化せざるを得なくなる可能性がある。これはビジネスモデルを根底から覆す致命的な事態だ。

逆に、自社プロジェクトをオープンソースとして公開する予定があるなら、商用ライセンスや互換性のないオープンソースライセンスの依存関係を避ける必要がある。いずれにせよ、ライセンス義務を満たせない依存関係は排除しなければならない。後から該当ライセンスのコードを除去するには大きな工学的コストがかかるし、企業ソフトウェアにとって違反のビジネスリスクは甚大だ。高額な訴訟やレピュテーションの損傷に直結する。

従来のレビュー手法とその限界

これまでライセンスレビューは手作業か、サードパーティ製ツールで行われてきた。しかし、依存関係が増えるたびに人手でライセンスを確認するのは現実的ではない。ツールを使うにしても、開発フローとは別の場所でチェックが走るため、問題が見つかった時点では既にコードがマージされた後、というケースも少なくなかった。

GitHubのLicense Compliance機能はこの課題に直接アプローチする。Pull Requestの段階で新しい依存関係をスキャンし、ポリシーに合致しないライセンスがあれば、マージ前に開発者へフィードバックを返す。開発フローに組み込まれた「シフトレフト」なアプローチだ。

GitHubのLicense Compliance機能の仕組み

この機能は、リポジトリに適用するルールセット（ruleset）を通じて有効化される。カスタムプロパティを使って対象リポジトリを指定し、「Active」モードか「Evaluate」モードかを選択する仕組みだ。

ルールセットの対象となったリポジトリでは、依存関係を変更するPull Requestが作成されると自動スキャンが走る。新しい依存関係それぞれのライセンスを照会し、既に許可済みのライセンスやパッケージ固有の例外に該当すればチェックをパスする。問題がある場合は、直接の依存関係だけでなく推移的依存関係（依存関係がさらに依存しているパッケージ）についても、Pull Requestのコメントとしてアラートが投稿される。

開発者から見たフロー

開発者はアラートを受け取ったら、その依存関係が受け入れ可能かどうかを判断する。受け入れられないと判断すれば、コードを修正するかPull Requestをクローズして依存関係を除去する。一方、そのライセンスやパッケージを許可すべきだと考えた場合は、例外申請を上げることができる。申請は組織内のポリシーチームに通知され、ポリシーを修正するかどうかが判断される。

GitHub OSPOの運用実績

GitHub自身のOSPOは、この機能が社内公開される前からアーリーアダプターとして利用してきた。当初は組織全体のルールセットに「Evaluate」モードを適用し、Pull Requestにアノテーションを表示するだけでマージはブロックしない設定でスタートした。これにより、開発者が新しいワークフローに慣れる時間を確保しつつ、旧来の社内ツールと並行稼働させて挙動の差異を検証したという。

約1カ月の並行稼働を経て、アラートの大半が「通常とは異なるライセンス」「ライセンス情報の欠落」「明示的に禁止されたライセンス」に絞り込まれた段階で、Activeモードへ移行した。大規模で動きの速い企業でも、段階的なロールアウトによって摩擦を最小化できる好例といえる。

ポリシー設計の実践アプローチ

効果的なライセンスコンプライアンスを実現するには、適切なポリシー設計が不可欠だ。GitHub OSPOの経験から、以下の3段階で考えると整理しやすい。

重要なのは、ポリシーを「作って終わり」にしないことだ。新しいライセンスやパッケージ固有の例外は、ポリシーチームが継続的に審査し、必要に応じて追加していく。この運用プロセスが整っていないと、開発者は Pull Request がブロックされたまま放置される「ポリシー渋滞」に巻き込まれる。

ライセンス許可とパッケージ例外の使い分け

ポリシー修正には大きく2つの判断軸がある。「ライセンスそのものを許可する」か「特定のパッケージだけを例外として許可する」かだ。さらに、その許可を「Enterprise全体（組織全体）」に適用するか「特定のリポジトリのみ」に限定するかも決定する。

安全なライセンスで単に初出だっただけなら、Enterpriseレベルでライセンスを追加すれば済む。一方、商用ライセンスのパッケージで、特定のチームだけが購入済みのソフトウェアなら、そのリポジトリだけに例外を設定する。パッケージ例外にはワイルドカードマッチが使えるため、例えば @github-ui/* のような形で名前空間単位の許可も可能だ。

緊急時のオーバーライドと開発者教育

ライセンスポリシーによってPull Requestがブロックされる仕組みは強力だが、クリティカルな修正を緊急でマージしなければならない場面も想定しておく必要がある。GitHub OSPOは「ブレークグラス（緊急時オーバーライド）」の手順を整備している。

仕組みはシンプルだ。ルールセットの条件はカスタムプロパティの値を参照しているため、そのプロパティ値を切り替えるだけで一時的にポリシー適用を無効化できる。GitHub OSPOのこれまでの運用では、このオーバーライドを使ったのは1度だけだったという。頻繁に使うものではないが、いざという時に選択肢があることが重要だ。

開発者へのトレーニングとドキュメント

ツールを導入するだけでは不十分だ。開発者が「なぜライセンス遵守が自分ごとなのか」を理解していなければ、例外申請のプロセスは形骸化する。GitHub OSPOは社内向けのドキュメントとトレーニングを提供し、ライセンスコンプライアンスが全員の責務であるという認識を浸透させている。

開発者が情報に基づいた依存関係の選択をできるようになれば、後からの修正作業や法的トラブルを未然に防げる。ライセンス遵守は「コンプライアンス部門だけの仕事」ではなく、サプライチェーン全体で取り組むべき課題だ。

依存関係管理のこれから

ソフトウェアサプライチェーンのセキュリティとコンプライアンスは、近年急速に注目を集めている領域だ。SBOM（Software Bill of Materials）の普及や、米国大統領令によるソフトウェアサプライチェーンセキュリティの強化など、規制面からの要請も強まっている。

GitHubのLicense Compliance機能は、こうした流れの中で「Pull Request時点でライセンスをチェックする」というプラクティスを標準化しようとする試みだ。開発フローに自然に溶け込む形で提供されるため、導入障壁は従来のサードパーティツールよりも低い。

現時点ではパブリックプレビューであり、対象はGitHub Enterprise CloudでGHAS Code Securityライセンスを保有するユーザーに限られる。しかし、GitHub自身が大規模な組織で実績を積んでいる点は、導入を検討する企業にとって心強い材料だろう。

この記事のポイント

• GitHubが依存関係のライセンス遵守をPull Request上で自動チェックする新機能を公開プレビューとして発表した
• ルールセットを通じてリポジトリ単位で適用し、Evaluateモードから段階的に導入できる
• GitHub自身のOSPOがアーリーアダプターとして社内で運用実績を積んでいる
• ライセンス違反は訴訟リスクやソースコード公開義務といった深刻な結果を招くため、開発フローへの組み込みが重要
• ポリシー設計は「基本ライセンスの登録 → Evaluateモード → Activeモード」の3段階で進めるのが現実的

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

www.aandgweb.co.jp

GitHubがシークレットスキャニングで受信箱ゼロを達成した方法

20,000件のアラートと向き合う、実践の全容

GitHubが社内の15,000以上のリポジトリを対象にシークレットスキャニングを実施したところ、20,000件を超える認証情報の露出を検出した。数字だけ見ると途方もないが、9カ月後には未対応のアラートをゼロに持ち込んでいる。セキュリティ運用の現場で「受信箱ゼロ（inbox zero）」を達成した事例として注目すべきプロジェクトだ。

GitHub Blogの記事によれば、同社はシークレット管理の取り組みを数年前から開始し、自社開発中のシークレットスキャニング機能をパイロット適用したところ、想定を大きく上回る数のシークレットが浮上したという。単に検出するだけでなく、どれが本物のリスクで、誰が対応すべきかを見極め、安全に修正するフェーズへと進めた点が鍵を握る。

本記事ではGitHubの内部事例をもとに、シークレット管理の現実的な進め方をひもとく。新規にシークレットスキャニングを導入した組織が直面する「どうやって既存のシークレットを片付ければいいのか」という問いに対する、具体的な戦略と教訓をまとめた。

ノイズの切り分け、18,000件が一瞬で消えた理由

20,000件を超えるアラートが出たからといって、同じ数の重大なインシデントが存在するわけではない。GitHubが最初に取り組んだのは、本当に対処すべきアラートとノイズの仕分けだった。

わずか5リポジトリで9割を占めたテスト用シークレット

データを掘り下げると、アラート全体の約18,000件がたった5つのリポジトリに集中していた。しかも、そのすべてがテスト用のフィクスチャや無効化済みの認証情報、実在しないが有効に見えるダミーシークレットだった。シークレットスキャニングを自社開発するGitHubにとって、テスト用の本物らしいシークレットが大量に必要なのは自然なことだ。

ここで同社が取った判断は明確だ。専用テストリポジトリに含まれ、一度も実運用で使われた形跡がなく、既知のテストパターンに一致するシークレットは、まとめて「解決済み」として一括クローズした。わずか数日で約18,000件のノイズが消え、残ったのは2,000件あまりの本物のアラートだけになった。

テスト用シークレットと本物のクレデンシャルを区別する基準を事前に定めておけば、大規模な一括処理が可能になる。数字の見た目に惑わされず、まずは分類から始めるのが現実的な最初の一手だ。

コードだけではない、シークレットの潜む場所

シークレットはソースコードにだけ存在すると思いがちだが、GitHubの経験はそれを覆した。サポートチケット、バグ報奨金レポート、インシデント対応のメモ、wikiページにもシークレットは散らばっていた。

サポートチケットには顧客がうっかりトークンを含めてしまうケースがあり、バグ報奨金の報告には研究者が完全な再現手順の一環としてAPIリクエストごとトークンを提出する。インシデントの調査記録にも、緊急時にコピーされた認証情報が残ることがある。いずれもコードリポジトリの外にあるため、従来のスキャン対象から漏れやすい領域だ。

GitHubはカスタマーサポート、セキュリティインシデント対応チーム、バグ報奨金プログラムと連携し、それぞれのワークフローに共通のプレイブックを整備した。修正作業の過程で新規の課題やコミットにシークレットを載せてしまう二次被害を防ぐ工夫も、あわせて徹底されている。

スキャン対象をコードリポジトリだけに絞っていると、これら周辺領域のシークレットはいつまでも検出されない。組織全体のワークフローを見直し、サポートやバグ報奨金の運用にもシークレット対策を組み込む必要がある。

段階的な取り組みで9カ月後にゼロへ

GitHubは2万件超のアラートを少数のセキュリティエンジニアだけで片付けようとはしなかった。新規の負債を止めたうえで、既存の負債を反復可能かつ計測可能なワークフローで減らしていく、運用バックログの処理と変わらないアプローチを取っている。主なフェーズは次の6段階だ。

フェーズ1、全社への有効化と強制で新規流入を遮断

既存のシークレットを片付ける前に、新たなシークレットの蓄積を止める必要がある。GitHubは全エンタープライズと組織に対してシークレットスキャニングとプッシュプロテクションを一括で有効化した。GitHub Advanced Securityの組織レベル設定があったため、15,000以上のリポジトリを一つひとつ手動で設定する必要はなかったという。

設定は強制適用され、個々のリポジトリやチームがこっそりオプトアウトすることは許されていない。プッシュプロテクションによって新規シークレットがソース上に流入するのを根本でブロックし、バックログが増え続ける状況を断ち切った。

フェーズ2、分類とトリアージで取捨選択

2万件超のアラートをリポジトリ別、シークレットタイプ別、経過期間別に分解し、前述のとおり約18,000件を一括クローズした。残った2,000件あまりについて、GitHubは難しい判断に直面する。

課題の中にシークレットが含まれている場合、本文を編集してリビジョン履歴を消すべきか、それとも監査証跡を残すべきか。リポジトリにコミットされたシークレットは、git履歴を書き換えるべきかどうか。大規模な履歴書き換えは強制プッシュによってプルリクエストを破壊し、コミットのSHAを無効化し、開発者の作業を中断させる副作用がある。

「もう使っていないリポジトリなら削除してしまえばいいのでは」という声も出たが、GitHubの回答は原則としてノーだった。削除されたリポジトリは監査証跡もろとも消える。もしそのリポジトリのシークレットが過去に漏洩していた場合、インシデント対応に必要な証拠を失ってしまう。シークレットをローテーションしたうえで、必要に応じてアーカイブし、履歴は残すという方針を取った。

可能なかぎり露出したシークレットを先にローテーションまたは無効化し、そのうえで履歴書き換えの要否を判断する。無効化済みのシークレットが履歴に残っていても安全かどうかはケースバイケースだ。この種の判断が、プロダクトセキュリティチームが日々直面する難題の一つであると記事は述べている。

フェーズ3、実効性の検証で本物を見極める

リポジトリに置かれた認証情報は、何年も前にローテーション済みかもしれないし、いまも本番システムにアクセスできるかもしれない。違いがわからなければ優先順位はつけられない。

当時のシークレットスキャニングにはネイティブの有効性チェック機能がなかったため、GitHubは独自の検証アプローチを構築した。目的は絞り込まれている。クレデンシャルがまだ機能するかどうかを確認し、適切な場合はアラートの転送先や通知すべき所有者を特定するための最小限のメタデータを収集するにとどめた。

たとえばGitHubトークンなら、GET /userのような影響の小さいエンドポイントに1回だけ認証リクエストを送る。不明瞭なレスポンスは結論不能と扱い、リポジトリや組織などのプライバシーに関わるリソースへの追加リクエストは避けた。この検証作業はプライバシーおよび法務チームとの密接な連携のもとで進められた。

手動での検証を進める一方、プロダクトチームが有効性チェックをシークレットスキャニングにネイティブ実装し、以降の作業は大幅に加速した。現在では有効性チェックがGitHubシークレットスキャニングの標準機能として組み込まれている。

フェーズ4、所有者の特定と責任体制の確立

認証情報が生きているとわかっても、誰がそれをローテーションできるのかを特定できなければ意味がない。GitHubが発行するパーソナルアクセストークンについては、プロダクトチームと協力してトークンの作成者や作成日時、スコープといったメタデータをアラート上に直接表示できるようにした。トークンそのものを使わずに所有者を割り出せる仕組みだ。

問題はそれ以外のシークレットと、明確な所有者が存在しないリポジトリだった。GitHubにはEngineering Fundamentalsという社内のエンジニアリング基準プログラムがあり、サービスに対して永続的な所有権を義務づけている。しかし、すべてのリポジトリがサービスときれいに紐づくわけではない。この課題は、GitHub Custom Propertiesを使ったリポジトリ所有権の明確化と、認証情報管理ツール上の全シークレットに永続的な所有者を割り当てる取り組みへと発展した。所有者を特定できなければシークレットのローテーションは不可能だからだ。

フェーズ5、ロングテールへの手動トリアージ

検証とメタデータの充実を経ても、最終的には人間の判断を要するアラートが残る。それぞれについて、この認証情報が何へのアクセスを許可するのか、すでにローテーション済みか、接続先システムの所有者は誰か、修正パスは何か、という問いを一つずつ解いていく作業だ。

GitHubはクローズするアラートすべてに対し、正確な処分結果（無効化済み、テスト用、誤検知など）を記録し、修正課題へのリンクや承認されたセキュリティ例外の情報といった関連コンテキストをコメントとして残した。このフェーズは、自動化されたシグナルだけでは不十分な領域を埋めるために、複数チームの密接な連携を必要とした。

フェーズ6、仕組み化と説明責任で持続可能に

パターンが見えてきた段階で、GitHubは作業をスケーラブルな体制へと昇華させた。

• アラートを社内の脆弱性管理プラットフォームに集約し、一元的な追跡とレポートを実現
• シークレットタイプ別に修正プレイブックを文書化し、各チームが自律的に対応できるように整備
• リポジトリ所有権に基づいてアラートを適切なチームへ自動通知する仕組みを構築

最後の締めくくりは説明責任の確立だ。GitHubはシークレット修正をEngineering Fundamentalsプログラムに組み込み、セキュリティに関する基本要件として全チームを評価対象にした。明確な期待値を設定し、各チームが自分たちの状況を可視化できるダッシュボードを用意したことで、シークレット衛生は組織全体の共有責任へと変わった。着手から9カ月後、未対応アラートはゼロになった。

6つのフェーズは独立しているわけではなく、相互に補完し合う。フェーズ1で新規流入を止めなければバックログは減らず、フェーズ4の所有者特定ができなければフェーズ5の手動トリアージは停滞する。全体を一連のパイプラインとして設計した点が、9カ月での完遂を支えた。

GitHubが得た8つの教訓

今回のプロジェクトを通じてGitHubが得た教訓は、同様の課題に直面する組織にとって実践的な指針となる。以下に8つを整理した。

数字に怯えない

初期のアラート件数は2万件を超えていたが、実に9割は実害のないノイズだった。生の数字がそのまま実際の作業規模を表すことはほとんどない。まずは分類から始めるべきだ。

例外なく全社に強制適用する

部分的な展開は死角を生む。GitHubはエンタープライズレベルでシークレットスキャニングとプッシュプロテクションを有効化し、誰にもオプトアウトを許さなかった。

エスカレーションの前に検証する

検出されたシークレットのすべてが生きているわけではない。有効性チェックによって優先順位をつけ、本当に危険なものから手を付けるのが鉄則だ。

メタデータが作業時間を大幅に削減する

GitHub発行の認証情報については、トークンの作成者やスコープといったメタデータが調査時間を劇的に短縮した。サードパーティプロバイダにも同様のメタデータ提供を求め、自前で補完する層を用意するのが望ましい。

所有者不在のシークレットは修正できない

永続的な所有権の基盤に早期に投資すること。リポジトリにもクレデンシャルにも、必ず責任者を紐づける仕組みが必要だ。

検出後のワークフローを自動化する

検出はスタート地点にすぎない。本当の運用課題は、アラートの転送、所有者の追跡、そしてクローズまでのループを回し切ることにある。ワークフロー層への投資が成否を分ける。

セキュリティチームだけの課題にしない

数千件のアラートをセキュリティチームだけで修正するのは不可能だ。GitHubはシークレット衛生をエンジニアリングの基本要件に組み込み、全チームの評価指標に据えた。リーダー層がダッシュボードを注視する状況になれば、各チームは自然と修正の時間を確保する。

判断基準を文書化する

すべてのシークレットにきれいな修正パスがあるわけではない。ローテーションで十分なケース、履歴の書き換えが必要なケース、残余リスクを受け入れるケースを、どう判断するかをあらかじめ文書化しておくことが重要だ。

多くの手作業は製品機能に置き換わった

今回のプロジェクトでGitHubが手動で実施していた有効性チェックや所有者特定、一括トリアージの多くは、現在シークレットスキャニングのネイティブ機能として利用できる。同社の記事は、読者に対して「私たちが構築したものの大半を再発明する必要はない」と明言している。

新規にシークレットスキャニングを導入するなら、まず全社への有効化とプッシュプロテクションの強制適用から始め、バックログをリポジトリとシークレットタイプでトリアージし、ノイズと判断できるものは迷わず一括クローズする。その後、有効なシークレットを検証し、所有者にアラートをルーティングし、他のエンジニアリング作業と同様に修正状況を追跡する。この流れは、組織の規模を問わず適用できる現実的なアプローチだ。

この記事のポイント

• アラート件数に惑わされず、まずはテスト用や無効化済みのノイズを分類して一括除去する
• シークレットはコード以外にも存在する。サポートチケットやバグ報奨金レポートも対象に含める
• 新規流入を止める強制適用と、既存バックログの段階的処理を並行して進める
• 有効性検証とメタデータ活用で、本当に対処すべきアラートに集中する
• シークレット衛生を組織全体の評価指標に組み込み、セキュリティチームだけの負荷にしない

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

www.aandgweb.co.jp