本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

GitHubのセキュリティ構成 有料のCode Securityが有効になる操作

目次 · 6項目

GitHubの組織で、リポジトリのセキュリティ機能をまとめて設定する「セキュリティ構成(security configuration)」を使うと、数十のリポジトリに同じ設定を一度に当てられます。便利な反面、設定を誤ると、有料の機能が一度に多くのリポジトリで有効になります。プライベートのリポジトリでは、機能を有効にしたリポジトリにコミットしている人数に応じて費用が発生します。

2026年10月30日、GitHubのドキュメントのリポジトリ(github/docs)で、有料の「GitHub Code Security」を無効のまま保つ手順に、警告が加わりました。11月3日には、公開リポジトリでの既定の状態についての誤った記述が直されています。本記事では、2026年11月7日に確認した原稿と、11月11日に照合した公開中のページをもとに、2つの更新の意味と、構成を作るときの確認の順番を整理します。

有料になるのは、どの機能か

ドキュメントによると、GitHub Advanced Securityのライセンスは2つの区分(SKU)に分かれています。秘密情報の検出を担う「GitHub Secret Protection」と、コードの脆弱性の検出(コードスキャン)などを担う「GitHub Code Security」です。

ドキュメントの請求の説明によると、GitHub.comのプライベートのリポジトリと、GHE.com・GitHub Enterprise Serverのすべてのリポジトリでは、これらの機能を使うには支払いが必要です。数え方は、機能を有効にしたリポジトリに、過去90日以内にプッシュされたコミットがある人(active committer)1人につき1ライセンスです。GitHub Appのボットは数えません。GitHub.comの公開リポジトリでは、コードスキャン、シークレットスキャン、依存関係のレビューを無料で使えます。

GitHubの製品ページ(2026年11月11日確認)では、Secret Protectionが active committer 1人あたり月19米ドル、Code Securityが同じく1人あたり月30米ドルと案内されています。なお、AI Scanとエージェントによる自動修正(agentic autofix)は、このライセンスとは別に「Code Security AI credits」を消費し、公開リポジトリでも対象になると、請求の説明に書かれています。

一方、依存関係グラフ(dependency graph)とDependabotアラートは、ドキュメントで「すべてのプランに含まれる」とされています。

「Not set」で有効に切り替わる

有料の機能を外したいリポジトリには、製品の最上位の設定を無効にしたセキュリティ構成を作って当てる、というのがドキュメントの勧める方法です。10月30日の更新で、その手順は次のように書き直されました。

Code Securityを無効のまま保つには、「Code scanning」の欄の「Default setup」と「Prevent direct alert dismissals」を Disabled にする。「Dependency graph」と「Dependabot alerts」は、すべてのプランに含まれるので有効のままでよい。

そのうえで、警告が加わっています。

「Code scanning」の欄の「Prevent direct alert dismissals」を Not set に変えると、Code Securityが自動で Enabled に切り替わる。意図せず有料の機能を有効にしないよう、組織の管理者はこの欄の「Default setup」と「Prevent direct alert dismissals」を Disabled のままにし、保存して当てる前に、Code Securityの最上位の設定をもう一度確かめる必要がある。

「Not set」は、文字どおりには「この構成では決めない」という選択です。それが、製品の最上位の設定を「有効」に変えてしまう、という点が警告の中身です。保存の直前に見直さなければ、無料の範囲のつもりで作った構成が、Code Securityを有効にした構成になります。

構成の名前についても、「No Code Security」や「Secret Protection and Supply chain only」のように、何を含まないかが一目でわかる名前にするよう書かれています。

GitHubのセキュリティ構成でCode Securityが有効に切り替わる操作の図。Code scanningの欄のPrevent direct alert dismissalsをNot setにすると、Code Securityの最上位の設定が自動でEnabledになる。無効のまま保つには、Default setupとPrevent direct alert dismissalsをDisabledにする。依存関係グラフとDependabotアラートはすべてのプランに含まれ、公開リポジトリでも既定では有効ではない

公開リポジトリでも、既定では有効ではない

11月3日の更新は、別の誤りを直したものです。リポジトリのセキュリティ設定のページには、以前「依存関係グラフは公開リポジトリでは常に有効」という記述がありました。これが次のように直されています。

依存関係グラフ、Dependabotアラート、プッシュ保護(push protection)は、公開リポジトリであっても既定では有効になっていない。

依存関係グラフの説明の冒頭も「既定では有効になっていない(Not enabled by default)」に変わり、対象の一覧にあった「公開リポジトリ(既定で有効)」の注記が消えました。リポジトリのセキュリティ設定のページには、Dependabotアラートを使うには依存関係グラフを先に有効にする必要がある、とも書かれています。GitHub Enterprise Server向けの説明では、公開リポジトリは依存関係グラフを有効にするとDependabotアラートが自動で有効になる、と直されています。

「公開リポジトリなら最初から見張られている」と考えて何も設定していなければ、脆弱な依存関係の知らせは届いていない可能性があります。

さらに、2026年11月10日のGitHub Changelogで、12月8日から、過去1年間に活動のないリポジトリのDependabotアラートを止める(既存のアラートは削除せずに保管する)と告知されました。プッシュがあれば自動で再開します。Dependabotアラートを有効にするセキュリティ構成を強制(enforce)しているリポジトリは、止める対象から外れます。github.comのすべてのプランが対象で、GitHub Enterprise Serverは対象外です。

構成を作るときの確認の順番(編集部の提案)

ここからは、2つの更新をもとにした編集部の提案です。実際の組織で構成を作り、自動で切り替わる動きや請求を確かめたわけではありません。

  1. いまの使用量を見る。 組織の設定の「Security configurations」の「Repositories」タブで、現在のライセンスの使用量が表示されると書かれています。有料の機能がどのリポジトリで有効になっているかを先に把握します。
  2. 無料の範囲の構成を作る。 Secret ProtectionとCode Securityの最上位を無効にし、「Default setup」と「Prevent direct alert dismissals」を Disabled に、依存関係グラフとDependabotアラートを有効にします。
  3. 保存の直前に最上位を見直す。 個々の項目を変えたあとで、Code Securityの最上位が Disabled のままかを確かめてから保存します。名前は「No Code Security」のように、含まないものがわかるものにします。
  4. 新しいリポジトリの既定にするかを決める。 構成の「Policy」の「Use as default for newly created repositories」で、公開・非公開と内部・すべてのリポジトリのいずれかの既定にできます。公開リポジトリでも依存関係グラフは既定で有効ではないため、既定の構成で有効にしておくと漏れを減らせます。止めたくない場合は「Enforce configuration」で強制する方法もあります。ドキュメントによると、強制されるのは有効・無効を決めた機能だけで、Not setの機能は強制されません。
  5. 当てたあとに使用量をもう一度見る。 手順1と同じ画面で、有料のライセンスの数が増えていないことを確かめます。

GitHub Enterprise CloudとGitHub Enterprise Server向けのドキュメントには、今後の有効化を防ぐために、Enterpriseの管理者に、Advanced Securityを使えないようにするポリシーと、リポジトリの管理者が機能を切り替えられないようにするポリシーを頼む方法も書かれています。なお、「Not set」の警告は組織のセキュリティ構成の手順のページにあり、Enterpriseのレベルで作る構成について同じ記述は見つけられませんでした。

無料で使える脆弱性の評価は、Code Security Risk Assessmentの記事で扱いました。Secret Protectionの新しい検出対象については、Actionsのログのシークレットスキャンの記事を参考にしてください。

確認した範囲

2026年11月7日に、GitHubのドキュメントのリポジトリ(github/docs)のコミット 234a5ac(2026年10月30日、「Warn about automatic Code Security enablement in security configurations」)と 5d9f6a9(2026年11月3日、「Fix docs stating dependency graph and Dependabot alerts are on by default for public repos」)の差分、main にある「Managing your paid use of GitHub Advanced Security」「Creating a custom security configuration」「GitHub Advanced Security license billing」の原稿を確認しました(資料調査)。2026年11月11日に、docs.github.com の公開中のページが原稿と同じであること、GitHubの製品ページ(github.com/enterprise/advanced-security)の料金、2026年11月10日のGitHub Changelogを確認しました。構成の作成、自動で切り替わる動き、請求は試していません。

開発の体制に合わせたGitHubの権限やセキュリティ機能の設計は、グリームハブの開発・AI・自動化のご相談で承っています。リポジトリの数や公開範囲によって進め方が変わるため、お問い合わせからご相談ください。

参考資料

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事のテーマを、自社の次の一歩へ

自社での進め方を、具体的に。

つくりたい仕組み、既存システム、運用の条件を整理し、実現に向けた次の一歩を考えます。

  • 実現したい仕組み
  • 既存環境との接続
  • 運用の条件
開発・運用の構想を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る