GitHub Advanced SecurityのInnersource security advisoriesがGA｜影響範囲と管理者対応

GitHub Advanced Securityを利用し、社内パッケージや共通ライブラリを複数のリポジトリで再利用している企業は、今回の一般提供開始を優先的に確認すべきです。

結論から言えば、Innersource security advisoriesは、社内で把握した脆弱性情報をEnterprise内だけに公開し、影響するリポジトリへDependabotアラートや修正版への更新PRを届ける仕組みです。メールやチャットで脆弱性を周知し、各開発チームに影響確認を依頼する運用を、依存関係の情報に基づいて自動化できます。

公式Changelogの掲載日は2026年7月8日です。本記事では、日本時間2026年7月9日時点で確認できる公式情報を基に、保護対象、管理者設定、監査・検知への影響、対応の優先順位を整理します。(The GitHub Blog)

ただし、GAになったからといって自動的に有効になるわけではありません。ライセンス、GitHub App、依存関係グラフ、Dependabot、プライベートレジストリへのアクセスなどを確認しなければ、アドバイザリを登録しても期待どおりに検知・修正できない可能性があります。

GitHub Advanced Securityの「Innersource security advisories are generally available」とは

「Innersource security advisories are generally available」は、GitHub Enterprise内で利用しているコンポーネントの脆弱性を、外部に公開せずに管理・通知する機能が一般提供されたことを示します。

対象となるのは、社内で開発したプライベートパッケージだけではありません。企業が独自に把握したオープンソースコンポーネントの脆弱性についても、Enterprise内限定のアドバイザリとして登録できます。

登録された情報は、同じEnterpriseが所有するリポジトリの依存関係と照合されます。影響するバージョンを利用しているリポジトリでは、Dependabotアラートに「Innersource」ラベルが表示されます。修正版を指定しており、Dependabotによる更新が可能な場合は、バージョン更新のプルリクエストも作成できます。(GitHub Docs)

作業	手動中心の運用	Innersource security advisoriesを利用した運用
脆弱性の周知	メール、チャット、社内Wikiで一斉通知	Enterprise内限定のアドバイザリとして登録
影響リポジトリの特定	各チームが個別に検索	依存関係グラフを基にDependabotが照合
開発者への通知	担当者がIssueやチケットを作成	対象リポジトリにDependabotアラートを表示
修正版への更新	各チームが手動でバージョン変更	条件を満たせば更新PRを自動作成
対応状況の集約	スプレッドシートなどで管理	Security overview、監査ログ、Webhookで追跡

この機能の本質は、脆弱性を新たに発見することではありません。すでに把握している社内向け脆弱性情報を、影響するリポジトリへ確実に届けるための仕組みです。

そのため、Code scanningやSecret scanningの代替にはなりません。脆弱性の発見経路は、コードレビュー、セキュリティ診断、インシデント調査、研究者からの報告など、別途用意する必要があります。

保護対象と対象外を整理

Innersource security advisoriesが機能するには、アドバイザリを登録するだけでなく、対象リポジトリの依存関係をGitHubが認識できる状態になっている必要があります。

保護対象になるための条件

確認項目	保護対象になる条件	管理者が確認する場所
Enterprise	アドバイザリを登録したEnterpriseが所有している	EnterpriseおよびOrganization設定
ライセンス	GitHub Advanced SecurityまたはGitHub Code Securityの有効なライセンスがある	Enterpriseのライセンス設定
リポジトリ	依存関係グラフが有効になっている	Repository settingsまたはSecurity configuration
依存パッケージ	GitHubがパッケージ名と利用バージョンを認識できる	Dependency graph
アラート	Dependabot alertsが有効になっている	Code security設定
自動更新	更新PRが必要な場合はDependabot updatesも利用できる	Dependabot設定
パッケージ取得	プライベートパッケージの場合はレジストリへアクセスできる	Dependabot secrets、レジストリ設定

Dependabotは、マニフェストファイルやロックファイルなどから依存関係グラフを作成し、登録された脆弱性の対象バージョンと照合します。そのため、実際のビルドに含まれている依存関係と、GitHub上の依存関係グラフが一致しているかが重要です。(GitHub Docs)

対象外または検知漏れが起きるケース

次のケースでは、アドバイザリを登録しても通知されない可能性があります。

• 別のEnterpriseやEnterprise外のリポジトリ
• 依存関係グラフが無効なリポジトリ
• Dependabot alertsが無効なリポジトリ
• GitHubが対応していないパッケージエコシステム
• 独自形式の依存関係ファイルだけを使っているプロジェクト
• ビルド時に追加され、依存関係グラフへ送信されていないコンポーネント
• アドバイザリのパッケージ名やバージョン範囲が実態と一致していないケース

特に、コンテナイメージのビルド途中で追加されるライブラリや、社内ビルドツールが動的に取得する依存パッケージは注意が必要です。通常のマニフェスト解析だけで把握できない場合は、Dependency submission APIなどを使い、ビルド時の依存関係をGitHubへ送信する運用を検討します。

配信範囲はEnterprise単位

Innersource security advisoriesの配信境界は、1つのEnterprise全体です。特定のOrganizationや開発チームだけを対象にする設定はありません。

機密性の高い脆弱性を登録する場合は、次の情報をアドバイザリに含める必要があるか事前に判断してください。

• 攻撃コードの詳細
• 本番環境の構成情報
• 顧客名やシステム名
• 未修正の回避策に関する機密情報
• 脆弱性を発見した内部担当者の個人情報

技術的な再現手順をすべて記載するのではなく、影響判定と更新に必要な情報へ絞ることが重要です。

また、アクティブなInnersource advisoryは、1つのEnterpriseにつき最大2,000件です。上限に近づいた場合は、不要になったアドバイザリをwithdrawして整理する必要があります。

ライセンスが失効した場合やGitHub Code Securityが無効になった場合は、登録済みアドバイザリが削除されるわけではありません。ただし、表示とアラートの伝播が停止し、ライセンスを再有効化すると再び利用できる状態になります。(GitHub Docs)

今回のChangelogと管理手順は、GitHub Enterprise Cloud向けの公式資料として公開されています。GitHub Enterprise Serverを利用している組織は、同じ機能や手順が利用できると仮定せず、使用中のバージョンのリリースノートまたはGitHub Supportで対応状況を確認してください。

管理者が必要な設定と導入手順

導入作業は、セキュリティ担当者だけで完結しません。Enterprise owner、GitHub App管理者、パッケージ管理者、リポジトリ管理者の役割分担が必要です。

推奨する導入順序は次のとおりです。

優先順	作業	完了条件
最初	ライセンスと利用環境を確認	対象Enterpriseで必要なライセンスが有効
次	社内パッケージの利用状況を棚卸し	パッケージ、利用リポジトリ、管理者が分かる
次	依存関係グラフとDependabotを確認	対象リポジトリで依存関係とアラートが確認できる
次	Enterprise所有のGitHub Appを準備	必要な権限だけを付与してインストール済み
次	OSV形式のデータを作成	パッケージ名、影響範囲、深刻度、修正版が正しい
次	REST APIで同期	非同期ジョブが正常終了している
最後	テスト用アドバイザリで検証	アラート、PR、監査記録、withdrawを確認できる

Enterprise所有のGitHub Appを作成する

アドバイザリの作成、更新、withdrawには、Enterprise所有のGitHub Appを使用します。

GitHub Appには、EnterpriseレベルのEnterprise innersource vulnerabilities権限を付与します。APIから登録・更新・withdrawを行う場合は、書き込み権限が必要です。

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

1. Enterprise所有のGitHub Appを登録する
2. Enterprise innersource vulnerabilitiesの読み書き権限を設定する
3. 対象EnterpriseへGitHub Appをインストールする
4. Installation access tokenを生成する
5. トークンを使ってREST APIを呼び出す

OAuth AppやPersonal access tokenでは、このAPIを利用できません。GitHub AppのInstallation access tokenが必要です。(GitHub Docs)

また、App Managerに指定されたユーザーはGitHub Appの登録情報を管理できますが、それだけではEnterpriseへのインストールやアンインストールを行えません。作業計画にはEnterprise ownerを含めてください。(GitHub Docs)

権限を広げすぎないことも重要です。この用途専用のGitHub Appを作成し、他の管理APIやリポジトリ内容への不要な権限を付けない構成が適しています。

OSV形式でアドバイザリを作成する

登録データは、OSV形式を基に作成します。GitHubはOSVスキーマ1.xに対応し、1.4.0の利用を推奨しています。

少なくとも、次の情報を正確に定義する必要があります。

フィールド	内容	間違えた場合の影響
id	社内で一意の脆弱性ID	更新時に別のアドバイザリとして扱われる可能性がある
severity	CVSS v3またはCVSS v4の深刻度	優先順位を誤る
affected.package	エコシステムとパッケージ名	対象リポジトリを検出できない
rangesまたはversions	影響を受けるバージョン	誤検知または検知漏れが発生する
fixed	修正済みバージョン	更新PRを生成できない
summary、details	開発者向けの説明	対応方法を判断できない

バージョン範囲にはECOSYSTEMまたはSEMVERを使用できます。GIT形式の範囲はサポートされていません。

また、同じ範囲内でfixedとlast_affectedを併用しないようにします。社内パッケージのバージョニングがSemVerに従っていない場合は、範囲指定だけに頼らず、影響バージョンを列挙する方法も検討してください。(GitHub Docs)

REST APIで登録し、完了状態まで確認する

アドバイザリの作成、更新、withdrawには、次の同期用エンドポイントを使用します。

POST /enterprises/{enterprise}/innersource-vulnerabilities/sync

処理結果は非同期で返されます。正常に受け付けられた場合のステータスは202 Acceptedです。

ここで注意したいのは、202が返った時点では処理完了ではないことです。レスポンスに含まれるジョブ情報を保存し、次のステータス確認用エンドポイントを呼び出します。

GET /enterprises/{enterprise}/innersource-vulnerabilities/sync/status/{job_id}

処理中は202、完了すると200が返り、作成、更新、withdraw、エラーなどの結果を確認できます。1回のリクエストで同期できる脆弱性は最大100件です。

短時間に大量のリクエストを送ると、Secondary rate limitの対象になる可能性があります。大量移行では100件単位に分割し、ステータス確認、再試行、待機処理を実装してください。(GitHub Docs)

運用証跡として、最低限次の情報を保存します。

• 社内の脆弱性管理番号
• APIへ送信した日時
• GitHub Appの識別情報
• job_id
• APIが返した作成・更新・withdraw件数
• エラー内容
• 再試行の履歴
• 最終的な処理状態

DependabotとSecurity configurationを確認する

アドバイザリを同期しても、対象リポジトリでDependabot alertsが無効になっていれば、開発者へ通知できません。

リポジトリ数が多い場合は、個別設定ではなくSecurity configurationを使って、次の機能をEnterpriseまたはOrganization単位で統一します。

• Dependency graph
• Dependabot alerts
• Dependabot security updates
• 必要に応じたDependency submission
• GitHub Advanced SecurityまたはGitHub Code Securityの関連機能

導入前には、設定が「有効」になっているかだけでなく、実際のDependency graphに社内パッケージが表示されているか確認してください。

設定画面で有効に見えても、パッケージ名やバージョンがグラフへ登録されていなければ、Innersource advisoryとの照合は行えません。

プライベートレジストリへのアクセスを設定する

修正版がプライベートレジストリにある場合、Dependabotがそのレジストリへアクセスできなければ更新PRを作成できません。

パッケージの保存場所に応じて、次の設定を確認します。

• OrganizationまたはRepositoryのDependabot secrets
• レジストリの読み取り用資格情報
• GitHub Packagesのアクセス権
• 社内ネットワークからのみ利用できるレジストリへの接続経路
• 必要に応じたDependabot用セルフホステッドランナー
• トークンの期限とローテーション手順

レジストリへ接続できない場合でも、依存関係グラフの情報によってアラートが表示されることはあります。しかし、利用可能なバージョンの確認や更新PRの作成は制限されます。(GitHub Docs)

検知と修正の流れはどう変わるか

Innersource security advisoriesを導入すると、脆弱性情報は次の流れで開発チームへ届きます。

社内で脆弱性を確認
  ↓
OSV形式のアドバイザリをREST APIで同期
  ↓
Enterprise内限定のアドバイザリを作成
  ↓
Dependency graphとパッケージ名・バージョンを照合
  ↓
対象リポジトリに「Innersource」Dependabotアラートを表示
  ↓
修正版と更新条件がそろえばDependabotが更新PRを作成

この流れでは、アドバイザリの品質が検知精度を大きく左右します。

たとえば、実際のパッケージ名がcompany-authであるにもかかわらず、アドバイザリにリポジトリ名のauth-libraryを指定すると、同じコンポーネントを指していても照合できません。

検知漏れを防ぐ確認ポイント

症状	主な原因	対応
アラートが1件も出ない	パッケージ名やエコシステムが不一致	Dependency graph上の表記をそのまま確認する
一部リポジトリだけ通知されない	マニフェストやロックファイルが未登録	デフォルトブランチと依存関係グラフを確認する
ビルド環境では使っているのに検出されない	動的に追加される依存関係がある	Dependency submissionを導入する
影響しないリポジトリにも通知される	バージョン範囲が広すぎる	introduced、fixed、個別バージョンを見直す
アラートは出るがPRが作成されない	修正版未指定、更新機能無効、レジストリへ接続不可	fixed、Dependabot updates、認証設定を確認する
修正版を公開したのに更新できない	レジストリ上のバージョンとアドバイザリが不一致	実際に取得できるバージョン番号を確認する

本番導入前には、実在する脆弱性を使うのではなく、検証用の社内パッケージとバージョン範囲を用意し、意図したリポジトリだけにアラートが出ることを確認するのが安全です。

監査ログとセキュリティ監視への影響

Innersource security advisoriesを運用する場合、監査対象は大きく3つに分かれます。

• アドバイザリを登録・更新したAPI操作
• GitHub Appの作成、インストール、権限変更
• Dependabotアラートの作成、解決、dismiss、withdraw

監査で記録すべき観測点

観測点	確認できること	推奨する保存先
API同期ジョブ	何件を作成・更新・withdrawしたか	脆弱性管理システム、SIEM
API Request events	どのGitHub AppがAPIを呼び出したか	Enterprise audit log streaming
GitHub Appイベント	Appの作成、インストール、権限変更	Enterprise audit log
Dependabotアラートイベント	アラートの作成、解決、却下、再オープン	Audit log、Security overview
dependabot_alert Webhook	アラートのリアルタイム連携	SIEM、チケット管理、通知基盤

Dependabotに関しては、監査ログで次のようなイベントを確認できます。

• repository_vulnerability_alert.create
• repository_vulnerability_alert.dismiss
• repository_vulnerability_alert.resolve
• repository_vulnerability_alert.withdraw
• repository_vulnerability_alert.reopen
• repository_vulnerability_alerts.enable
• repository_vulnerability_alerts.disable

GitHub Appについては、integration.create、integration_installation.create、integration_installation.version_updatedなどのイベントが監査対象になります。(GitHub Docs)

一方、2026年7月9日時点の公式監査ログイベント一覧では、Innersource advisoryの作成、更新、withdrawだけに特化した専用イベント名は明示されていません。

そのため、「専用の監査イベントが必ず記録される」という前提では設計せず、次の情報を組み合わせて証跡を残します。

1. REST APIが返すjob_idと処理結果
2. GitHub AppのInstallation access tokenを発行した仕組みのログ
3. Enterprise audit log streamingのAPI Request events
4. GitHub Appのインストール・権限変更イベント
5. 発生したDependabotアラートの監査イベント
6. 社内の脆弱性管理番号と変更承認記録

なお、api.requestイベントは標準状態ですべての監査画面に表示されるわけではありません。Enterpriseの監査ログ設定でAPI Request Eventsを有効にし、audit log streamingを利用する構成が必要です。(GitHub Docs)

監視ルールとして設定したい項目

SIEMや監視基盤へ監査ログを送っている場合は、次の変更を検知対象に加えます。

• 専用GitHub Appの権限が追加された
• GitHub Appが想定外のOrganizationへインストールされた
• Dependabot alertsが無効化された
• 大量のInnersourceアラートが短時間に発生した
• 高深刻度のアラートが一定時間未対応になっている
• アラートが理由なしでdismissされた
• API同期ジョブでエラーが繰り返された
• アドバイザリが想定外にwithdrawされた

大量のアラートが発生した場合は、実際に広範囲の脆弱性が存在するケースだけでなく、バージョン範囲の指定ミスも疑う必要があります。

対応が必要か判断する基準

すべてのGitHub Advanced Security利用企業が、同じ優先度で導入する必要はありません。

優先度	該当する組織	推奨対応
高	社内パッケージを複数のOrganizationや多数のリポジトリで共有している	導入プロジェクトを開始し、1パッケージで検証する
高	脆弱性発生時、影響リポジトリの特定を各チームへ依頼している	依存関係グラフの整備を最優先する
高	非公開の脆弱性情報をEnterprise内だけで通知したい	GitHub App、権限、監査設計を進める
中	共通ライブラリはあるが、利用リポジトリが少ない	手動運用と比較し、検証環境で費用対効果を確認する
中	Dependency graphの網羅性が分からない	導入前に依存関係の精度を調査する
低	社内パッケージを共有していない	即時導入は不要だが、今後の利用予定を確認する
対象外の可能性	必要なライセンスがない、または対象外の環境を利用している	契約と製品対応状況を確認する

次の質問に1つでも「はい」があれば、対応優先度は高いと判断できます。

• 共通ライブラリの脆弱性をメールやチャットで通知しているか
• どのリポジトリが特定バージョンを使っているか、すぐに一覧化できないか
• 複数のOrganizationで同じ社内パッケージを利用しているか
• 修正版を公開しても、各開発チームの更新状況を追跡できないか
• 外部公開前の脆弱性情報を社内だけで共有する必要があるか
• 脆弱性対応の監査証跡を一元化したいか

優先して実施すべき対応

最初から全リポジトリへ展開すると、アラートの誤配信や大量発生が起きた際に原因を切り分けにくくなります。次の順番で進めると安全です。

最優先：利用条件と依存関係を確認する

まず、次の3点を確認します。

1. 対象EnterpriseでGitHub Advanced SecurityまたはGitHub Code Securityが有効か
2. 社内パッケージがDependency graphに正しい名称とバージョンで表示されているか
3. 対象リポジトリでDependabot alertsが有効か

この段階で社内パッケージがDependency graphに表示されなければ、GitHub AppやAPIを先に構築しても十分な効果は得られません。

次に：1つのパッケージで試験運用する

検証対象は、次の条件を満たすパッケージが適しています。

• 複数のテスト用リポジトリから参照されている
• パッケージ管理者が明確である
• 影響あり・影響なしのバージョンを用意できる
• 修正版をレジストリへ公開できる
• 本番環境へ影響しない

検証では、次の結果を確認します。

• 影響バージョンを使うリポジトリだけにアラートが出る
• アラートに「Innersource」ラベルが表示される
• 影響外のバージョンにはアラートが出ない
• 修正版を指定すると更新PRが作成される
• API同期ジョブの結果を保存できる
• Dependabotの監査イベントを確認できる
• withdraw後の状態変化を確認できる

最後に：運用ルールと責任者を決める

本番展開前に、少なくとも次の責任を明確にします。

役割	主な責任
脆弱性管理者	深刻度、影響範囲、公開タイミングを承認する
パッケージ管理者	影響バージョンと修正版を確認する
GitHub Enterprise管理者	GitHub App、権限、Security configurationを管理する
リポジトリ管理者	アラートや更新PRへ対応する
監査・SOC担当	ログ、Webhook、未対応アラートを監視する

あわせて、次の状態に対する手順をRunbookへ記載します。

• 誤ったバージョン範囲を登録した
• アラートが想定より多く発生した
• 修正版の公開が遅れている
• GitHub Appのトークンが漏えいした
• API同期ジョブが失敗した
• ライセンスが失効した
• アドバイザリをwithdrawする必要が生じた

導入時に失敗しやすいポイント

失敗例	問題	防止策
GAになったため自動で有効だと思う	アラートが一切発生しない	ライセンス、Dependency graph、Dependabotを個別に確認する
202 Acceptedを成功完了と判断する	後続処理のエラーを見落とす	ステータスAPIをポーリングし、最終結果を保存する
Personal access tokenを使う	APIを認証できない	Enterprise所有のGitHub AppとInstallation access tokenを使う
リポジトリ名をパッケージ名として登録する	依存関係と一致しない	Dependency graphに表示される名称を使用する
バージョン範囲を広く指定する	大量の誤検知が発生する	影響あり・なしの境界バージョンでテストする
GIT範囲を使用する	サポート外の形式になる	SEMVER、ECOSYSTEMまたは個別バージョンを使う
修正版を指定しただけでPRが出ると思う	更新PRが作成されない	レジストリ、Dependabot updates、資格情報も確認する
App Managerだけで導入を進める	Enterpriseへのインストールで止まる	Enterprise ownerを作業担当に含める
Organization単位で限定配信できると思う	意図した公開範囲と異なる	Enterprise単位の運用として情報開示範囲を設計する
古いアドバイザリを放置する	2,000件の上限に達する	定期的に棚卸しし、不要なものをwithdrawする
専用監査イベントだけを待つ	API操作の証跡が不足する	ジョブ結果、API Request events、Appイベントを組み合わせる

まとめ：まず依存関係の見える化から始める

Innersource security advisoriesは、社内パッケージの脆弱性情報をEnterprise内だけで共有し、影響リポジトリへの通知と更新を自動化する機能です。

特に、共通ライブラリを複数のOrganizationやリポジトリで利用している企業では、手動連絡による通知漏れや影響調査の遅れを減らせます。

一方で、導入効果はDependency graphの精度に左右されます。GitHub AppとREST APIだけを構築しても、依存関係が正しく登録されていなければ検知できません。

最初に実施すべきことは、次の3点です。

• 必要なライセンスと対象環境を確認する
• 社内パッケージがDependency graphに表示されるか確認する
• 対象リポジトリでDependabot alertsが有効か確認する

そのうえで、検証用のパッケージを1つ選び、アドバイザリ登録、アラート発生、更新PR、監査ログ、withdrawまでを一通り試します。検知と監査の両方を確認できてから、対象パッケージとリポジトリを段階的に広げるのが安全です。