Mike Anderson

Posted on Jun 10

組織向け GitHub セキュリティ・ハードニング完全ガイド

#github #security #devsecops #supplychain

多くのエンジニアリング組織にとって、GitHub はアイデンティティ基盤であり、ソフトウェアサプライチェーンであり、CI/CD基盤であり、シークレットの保管場所であり、デプロイの実行基盤であり、本番環境への変更を制御する仕組みでもあります。

つまり、GitHub は本番環境の制御プレーンとして保護する必要があります。

このガイドは、組織全体の GitHub セキュリティを強化する CISO の視点で書かれています。単なる高レベルのベストプラクティス集ではありません。実際に適用し、監査し、継続的に改善できる実践的なハードニング・ベースラインです。

目的はシンプルです。

GitHub のガバナンスが緩かったことを理由に、ソースコード、ワークフロー、シークレット、ビルドシステム、リリースプロセス、本番環境が侵害される状態を作らないこと。

このガイドの使い方

このガイドは、次の3つのレイヤーで利用します。

レイヤー	対象読者	目的
経営・リーダー向けベースライン	CISO、Head of Engineering、Platform リーダー	なぜ GitHub を Tier-0 のエンジニアリング制御プレーンとして扱うべきかを定義する
セキュリティ標準	Security、Platform Engineering、AppSec、DevSecOps	必須統制、証跡、例外、責任分担を定義する
運用ランブック	SOC、リポジトリオーナー、リリースエンジニア	オンボーディング、監視、検知、インシデント対応、四半期レビューを支援する

このガイドで使う統制用語は、次の意味で解釈してください。

用語	意味
Must / Required	文書化された例外が承認されていない限り、必須のベースライン統制
Should / Recommended	強く期待される統制。逸脱する場合は理由を文書化する
May / Optional	リポジトリ分類とリスクに応じて判断する任意統制
Exception	オーナー、補完統制、レビュー日を持つ、期限付きでリスク承認された逸脱

すべての必須統制は、最終的に次の形へ対応付ける必要があります。

Control ID → Requirement → Owner → Enforcement → Evidence → Monitoring → Exception path

Section 29 では、各 GitHub 設定がどこにあり、何を設定し、どの証跡を保持すべきかを示す運用向けの enforcement map を提供しています。

これにより、この標準が「誰も証明できず、運用もできない長いチェックリスト」になることを防ぎます。

前提

このガイドは、次の前提に基づいています。

GitHub Organization または GitHub Enterprise Cloud を利用している。
リポジトリには、本番アプリケーションコード、Infrastructure as Code、自動化、CI/CDワークフロー、内部ツールが含まれる。
GitHub Actions を有効化済み、または利用予定である。
開発者は通常の変更に Pull Request を利用する。
一部のリポジトリは AWS、Azure、GCP、Kubernetes、パッケージレジストリ、デプロイツールと連携する可能性がある。
強制可能で、監査可能で、現実的に運用できる統制を目指している。

GitHub Enterprise、GitHub Advanced Security、GitHub Secret Protection、GitHub Code Security、またはプラン固有の機能に依存する統制については、展開前に自社の GitHub プランで利用可能かを確認してください。

GitHub 機能・ライセンス確認マトリクス

この標準を適用する前に、利用中の GitHub プランと Enterprise 設定でどの機能が使えるかを確認してください。GitHub の機能提供範囲は時間とともに変わります。一部の統制は、GitHub Enterprise Cloud、GitHub Enterprise Server のバージョン、GitHub Secret Protection、GitHub Code Security、GitHub Advanced Security、または同等のサードパーティツールに依存します。

統制領域	推奨される GitHub 機能	利用可否の確認	利用できない場合の補完統制
エンタープライズ・アイデンティティ	SAML SSO、SCIM、Enterprise Managed Users	Enterprise / Organization の identity settings	IdP 主導のアクセスレビューと手動プロビジョニング解除SLA
組織横断のリポジトリガバナンス	Organization または Enterprise rulesets	private repository と対象プランでの ruleset 利用可否	API/IaC で管理するリポジトリ単位の branch protection
シークレット流入防止	Secret scanning と push protection	Secret Protection / GHAS / プラン機能	pre-commit scanning、CI secret scanning、利用可能な server-side check
コードセキュリティ	CodeQL/code scanning、default setup、security overview	Code Security / GHAS / 対象言語	承認済みサードパーティ SAST を required check として統合
依存関係セキュリティ	Dependabot alerts、dependency review、security updates	Repository security settings と対象パッケージエコシステム	PR ブロック機能を持つサードパーティ SCA と SBOM レビュー
監査ログ監視	Audit log export/API/streaming	Enterprise と Organization audit log settings	SIEM 取り込みと完全性確認を伴う定期エクスポート
CI/CD アイデンティティ連携	GitHub Actions OIDC	クラウドプロバイダーと GitHub Actions の利用可否	承認済みブローカーからの短命クレデンシャル。静的シークレットは例外扱い
アーティファクト来歴	GitHub artifact attestations または外部署名/来歴	Actions と release workflow の対応状況	Sigstore/cosign/in-toto/SLSA互換の外部来歴管理
ランナー分離	Runner groups、ephemeral runners、hosted runner controls	Enterprise Actions runner settings	専用クラウドアカウント/プロジェクトと短命ランナーインスタンス

展開ルール:

ネイティブ機能が利用できないことを理由に、セキュリティ目的を弱めてはいけません。必要な GitHub 機能を有効化するか、承認済みのサードパーティ統制を使うか、補完統制付きの期限付き例外を文書化してください。

1. ガバナンスモデル: GitHub を Tier-0 エンジニアリング基盤として扱う

多くの組織が犯す最初の間違いは、GitHub を「開発部門だけが所有する開発ツール」として扱うことです。

それでは不十分です。

GitHub には正式なオーナーシップモデルが必要です。

領域	説明責任を持つオーナー	運用オーナー	セキュリティ上の期待値
Enterprise と Organization 設定	CISO / Head of Engineering	Platform Engineering	中央ポリシー、アクセス制御、監査可能性
リポジトリ所有	Engineering leadership	Repo maintainers	安全な変更管理とコードオーナーシップ
GitHub Actions	Platform Engineering	DevOps / DevSecOps	管理された CI/CD 実行
シークレットとトークン	Security + Platform	App teams	管理されていない長命クレデンシャルをなくす
OAuth / GitHub Apps	Security	Platform Engineering	承認済み連携のみ許可
Self-hosted runners	Platform Engineering	Infrastructure / DevOps	分離、監視、一時的ランナーを可能な限り利用
Security alerts	AppSec / DevSecOps	Repo owners	SLA 内の修復
Audit logs	SOC / SecOps	Security Engineering	SIEM 取り込みと検知カバレッジ

Security は統制標準を所有します。Engineering は実装を所有します。Platform Engineering はガードレールを所有します。Repo owner は自分のリポジトリの準拠責任を持ちます。

この分担は重要です。責任が曖昧なままだと、GitHub セキュリティは「誰も完全には管理していない設定の集合」になってしまいます。

2. ベースライン・セキュリティポリシー

設定を変更する前に、まず文書化されたベースラインが必要です。これは Organization settings、rulesets、CI/CD 統制、監査レビューを通じて適用される標準になります。

GitHub セキュリティ最小ベースライン

組織が所有するすべての GitHub リポジトリは、次のベースラインを満たす必要があります。

すべてのユーザーは企業のアイデンティティ統制を通じて認証する。
すべてのユーザーに MFA を必須とする。
Organization へのアクセスは、個別付与ではなくグループとチームを通じて付与する。
Organization の base permissions は実務上可能な最低レベルに設定する。
Outside collaborators は制限し、定期的にレビューする。
リポジトリの作成、削除、移管、可視性変更を制限する。
本番ブランチには Pull Request、承認、status checks、署名付きコミットを必須とする。
利用可能な場合は、secret scanning と push protection を有効化する。
稼働中のリポジトリには code scanning と dependency scanning を有効化する。
GitHub Actions は承認済みソースと安全なワークフローパターンに制限する。
Self-hosted runners は信頼レベルとワークロードの機微性に応じて分離する。
GitHub secrets 内の長命クラウドクレデンシャルは、対応可能な場合 OIDC federation に置き換える。
Classic PAT の利用を制限する。Fine-grained PAT には承認、有効期限、最小権限を求める。
OAuth Apps と GitHub Apps は Organization データへアクセスする前に承認を必須とする。
Audit logs はレビューし、SIEM へエクスポートする。
Repository administrators が承認済み例外なしにセキュリティ統制をバイパスできないようにする。
Break-glass access を用意し、監視し、テストする。
例外は期限付きで、リスク承認され、レビューされる。

このベースラインは意図的に厳格です。目的は開発速度を落とすことではありません。侵害されたアカウント、不正なワークフロー、漏えいしたトークン、不注意なリポジトリ設定が本番インシデントに発展することを防ぐためです。

最小統制カタログ形式

上記のベースラインは、エンタープライズ展開前に統制カタログへ変換する必要があります。

次の形式を使います。

項目	必須内容
Control ID	`GH-ID-01`、`GH-ACT-03`、`GH-MON-02` などの安定した識別子
Requirement	明確な必須要件
Applies To	Enterprise、Organization、リポジトリ分類、ワークフロー、runner group、integration など
Risk Addressed	アカウント乗っ取り、ソース改ざん、シークレット漏えい、サプライチェーン侵害など
Owner	説明責任を持つチームまたは役割
Enforcement	GitHub setting、ruleset、IdP policy、CI check、API automation、または手動プロセス
Evidence	export、screenshot、API result、SIEM event、policy-as-code output、ticket など
Monitoring	detection、dashboard、audit review、alert など
Exception Path	承認者、有効期限、補完統制、レビュー頻度

スターター統制:

Control ID	Requirement	Evidence
GH-ID-01	Organization access には SSO を必須とする	SSO enforcement configuration、IdP group mapping、access review record
GH-ID-02	Members、owners、billing managers、outside collaborators には MFA を必須とする	MFA enforcement setting、non-compliant user report
GH-ORG-01	文書化された例外で `Read` が承認されていない限り、base permissions は `No permission` とする	Organization settings export
GH-REPO-01	本番ブランチには PR review、status checks、CODEOWNERS review、force-push protection を必須とする	Ruleset または branch protection export
GH-ACT-01	Third-party Actions は制限し、full-length commit SHA へ固定する	Actions policy、workflow scan results
GH-ACT-02	Default `GITHUB_TOKEN` permissions は read-only とし、workflow permissions は明示する	Organization Actions setting、workflow lint output
GH-ACT-03	クラウドデプロイには OIDC または承認済み短命クレデンシャルを使う	Cloud trust policy、workflow file、deployment evidence
GH-RUN-01	Self-hosted runners は trust zone ごとに分離し、untrusted fork code を実行させない	Runner group policy、network policy、job history
GH-SEC-01	利用可能な場合、secret scanning と push protection を有効化する	Security configuration export、push protection metrics
GH-MON-01	GitHub audit logs は SIEM へエクスポートするか、承認済みプロセスでレビューする	SIEM ingestion evidence、audit log export job
GH-IR-01	GitHub セキュリティインシデントでは audit logs、workflow logs、release metadata、access evidence を保存する	Incident ticket and evidence package

3. アイデンティティとアカウントセキュリティ

アイデンティティは最初の制御プレーンです。攻撃者が広いリポジトリ権限やワークフロー権限を持つ開発者アカウントを取得すると、ソースコードの窃取、不正コードの注入、シークレットの持ち出し、リリースの改ざんが可能になる場合があります。

3.1 SSO を強制する

エンタープライズ環境では、必要に応じて SAML SSO または Enterprise Managed Users を利用します。

セキュリティ要件:

すべての Organization access に SSO を強制する。
Corporate identity provider を信頼できる唯一の情報源として扱う。
個人メールアカウントが管理外の本番アイデンティティにならないようにする。
対応している場合、機微な操作には再認証を要求する。
Emergency recovery codes と break-glass accounts は文書化された手順のもとで管理する。

推奨実装:

GitHub アイデンティティのライフサイクルを集中管理したい場合は Enterprise Managed Users を使う。
個人 GitHub アカウントを使いつつ集中アクセスガバナンスを求める場合は、SAML SSO と SCIM provisioning を使う。
Identity provider groups を GitHub teams へ対応付ける。
ユーザー削除は手動クリーンアップだけに頼らず、identity lifecycle automation で行う。

運用ルール:

HR がユーザーを無効化したら、GitHub access も手動チケットを待たずに削除されるべきです。

3.2 MFA を強制する

MFA は次の対象に必須とします。

Organization members
Enterprise owners
Organization owners
Billing managers
Outside collaborators
対応可能な service / automation accounts

推奨する認証方式:

Passkeys / hardware security keys
TOTP authenticator apps
補助的な選択肢として GitHub Mobile

より強い方式が利用できる場合、SMS は避けます。

最小ポリシー:

MFA なしのユーザーに Organization repositories へのアクセスを維持させない。
期限までに MFA 登録を完了しないユーザーは削除または停止する。
Break-glass accounts は hardware-backed MFA を使い、管理された vault に保管する。

3.3 Organization Owners を削減する

Organization owner は高リスクロールです。

最小標準:

Organization owners は非常に少数に保つ。
named accounts のみを使う。
MFA と SSO を必須にする。
owner membership を毎月レビューする。
日常的な repository administration には owner access を使わない。
実務上可能な場合は custom roles または delegated repository administration を使う。

推奨目標:

小規模から中規模の組織では Organization owners を 2〜4 名に抑える。
Enterprise owners と日常的な repository maintainers を分離する。
Break-glass owner access は緊急復旧時にのみ使う。

Owner account monitoring には次を含めます。

New owner added
Owner removed
SSO enforcement changed
MFA requirement changed
Actions policy changed
PAT policy changed
OAuth policy changed
Repository visibility changed
Audit log export disabled
Secret scanning disabled

3.4 休眠・孤立アクセスを無効化する

少なくとも毎月、次をレビューします。

最近活動がない dormant users
IdP group に対応付いていないユーザー
退職者
契約終了日を過ぎた contractor
Outside collaborators
direct repository access を持つユーザー
admin または maintain role を持つユーザー
service accounts

対応標準:

退職者のアクセスは即時無効化する。
明示的な承認がない限り、30日間非アクティブなユーザーを削除する。
contractor extension には business owner approval を必須とする。
access review 完了の証跡を記録する。

4. チームとアクセスモデル

整理されたチームモデルは、アクセス権限の拡散を防ぎます。

4.1 Teams を主要なアクセス付与手段にする

一時的な例外を除き、ユーザーをリポジトリへ直接付与することは避けます。

チーム設計は次のパターンに従います。

org
├── platform-admins
├── platform-developers
├── security-admins
├── security-readonly
├── app-payments-admins
├── app-payments-maintainers
├── app-payments-developers
├── app-payments-readonly
├── data-platform-maintainers
├── data-platform-developers
├── data-platform-readonly
└── contractors-project-x-readonly

チーム名は次の形式にします。

<domain-or-system>-<role>

例:

app-payments-developers
app-payments-maintainers
app-payments-readonly

同じアプリケーション名やプラットフォーム名が繰り返されているのは意図的です。同じシステムに対するアクセス階層を分離し、ユーザーへの直接付与ではなくチーム経由で権限を付与できるようにするためです。

admins と maintainers を両方使う場合は、違いを必ず定義してください。GitHub では Maintain と Admin は異なる repository permission level です。チーム名は意図する GitHub role と明確に対応させるべきです。

各チームには次を持たせます。

明確な business owner
明確な technical owner
定義された repository access
定義された permission level
可能な場合は IdP group mapping
review frequency
temporary teams の expiry date

4.2 最小権限の Repository Roles を使う

推奨ロールモデル:

Role	Use Case	Security Guidance
Read	Auditors、support、security reviewers	non-engineering access のデフォルト
Triage	write access なしで issue management を行う	support teams に有用
Write	PR 経由で貢献する developers	標準的な developer access
Maintain	破壊的な admin 領域を除き repo settings を管理する repo maintainers	慎重に使う
Admin	full control が必要な repo owners	最小化し毎月レビューする

「 senior だから」という理由で Admin を付与してはいけません。運用上その権限が必要な場合にのみ付与します。

4.3 Base Permissions を No Permission または Read にする

本番組織では、Organization base permission を次に設定します。

No permission

すべての members に internal repositories の読み取りを意図的に許可する場合に限り、Read を使います。

広範な Write base permissions は使わないでください。

4.4 Outside Collaborators を制御する

Outside collaborators は、アクセスドリフトの典型的な原因の一つです。

最小統制:

Outside collaborators を招待できるのは Organization owners または承認済み delegated admins のみにする。
Repository admins が governance approval なしに outside collaborators を招待できないようにする。
Outside collaborators には MFA を必須にする。
アクセスは期限付きにする。
アクセスは sponsor と紐付ける。
少なくとも毎月レビューする。
sensitive repositories への外部アクセスには security approval を必須にする。

必要な証跡:

Business justification
Sponsor
Repository list
Permission level
Expiry date
Approval record
Removal confirmation

5. Organization Settings のハードニング

これらの設定は、危険な管理操作を減らします。

5.1 Repository Creation

リポジトリ作成者を制限します。

推奨ポリシー:

リポジトリを作成できるのは、承認済みの platform、engineering leadership、または delegated repository creator teams のみにする。
default repository visibility は private または internal にする。
public repositories には承認を必須にする。
repository naming standards を適用する。
新規リポジトリは、本番利用前に security controls へオンボーディングする。

新規リポジトリチェックリスト:

Owner assigned
Data classification assigned
Visibility approved
Ruleset applied
Code owners configured
Security scanning enabled
Dependabot configured
Secrets scanning enabled
Actions policy inherited
Branch protection or ruleset active
Repository archived if not used

5.2 Repository Visibility Changes

可視性変更を制限します。

要件:

Developers と repository admins が承認なしに private repository を public に変更できないようにする。
ソースコードの public release には security、legal、engineering approval を必須にする。
sensitive repositories は public visibility を禁止する。

監視対象:

Private to public changes
Internal to public changes
Repository transfer
Repository deletion
Repository archival
Fork policy changes

5.3 Repository Deletion and Transfer

リポジトリ削除と移管は、Organization owners または厳しく管理された platform team に制限します。

運用要件:

リポジトリは backup/export と承認なしに削除しない。
組織外への transfer には security approval を必須にする。
Archived repositories は security-relevant history を保持する。

5.4 Default Repository Settings

推奨デフォルト:

Setting	Required State
Default visibility	Private または internal
Base permissions	No permission
Repository creation	Restricted
Repository deletion	Restricted
Repository visibility changes	Restricted
Outside collaborator invitations	Restricted
Forking of private repositories	必要な場合を除き disabled
GitHub Actions	approved sources に restricted
Secret scanning	Enabled
Push protection	Enabled
Dependabot alerts	Enabled
Code scanning	active repositories で supported の場合 enabled

6. Repository Security Baseline

統制を適用する前に、すべてのリポジトリを分類します。

6.1 Repository Classification

シンプルな分類モデルを使います。

Classification	Examples	Minimum Control Level
Critical	Production apps、auth systems、payment systems、IaC、deployment automation	Strict
High	Internal services、APIs、data pipelines	Strong
Medium	Internal tools、non-sensitive services	Standard
Low	Documentation、examples	Basic

6.1.1 Repository Classification Decision Criteria

リポジトリ分類は、アプリケーション名やチーム規模だけではなく、リスクドライバーに基づいて決めます。

次の基準を使います。

Risk Driver	Critical Indicator	Required Treatment
Production authority	Repository が production を deploy、modify、rollback できる	Critical として扱う
Cloud/IAM control	Repository が IAM、Terraform、Kubernetes、CI/CD、policy-as-code を管理する	Critical または High として扱う
Secret exposure impact	Repository が production secrets、OIDC roles、deployment environments へアクセスできる	Critical として扱う
Customer or regulated data	Repository が customer、payment、health、identity、regulated data を処理する	Critical または High として扱う
Supply-chain impact	Repository が packages、images、SDKs、libraries、release assets を公開する	Critical または High として扱う
Security control impact	Repository が auth、authorization、logging、detection、WAF、EDR、security tooling に影響する	Critical として扱う
External exposure	Repository が internet-facing services または public APIs を支える	少なくとも High として扱う
Open-source visibility	Repository が public、または public release 予定	public repository controls を適用する

判断ルール:

リポジトリが production、credentials、identity、cloud infrastructure、release artifacts、customer data に影響できる場合、High 未満に分類しない。

各リポジトリの必須メタデータ:

Field	Required
Business owner	Yes
Technical owner	Yes
Security owner or reviewer	Critical と High では Required
Data classification	Yes
Repository classification	Yes
Production impact	Yes / No
Deployment authority	Yes / No
OIDC/cloud role access	Yes / No
Public exposure	Yes / No
Package/release publishing	Yes / No
Last review date	Yes
Exception status	Yes / No

Critical repositories には次を必須とします。

protected branches への direct pushes 禁止
Signed commits
Required pull request reviews
Code owners
Required status checks
Required security scans
Restricted administrators
Unapproved Actions 禁止
Public forks 禁止
Unreviewed workflow changes 禁止
Full audit logging and alerting

6.2 CODEOWNERS

必須レビューのオーナーシップには CODEOWNERS を使います。

例:

# Global owners
* @org/platform-maintainers

# Security-sensitive areas
/.github/workflows/ @org/devsecops @org/platform-security
/terraform/ @org/cloud-security @org/platform-engineering
/k8s/ @org/platform-engineering @org/cloud-security
/auth/ @org/security-engineering @org/app-auth-maintainers
/payment/ @org/payments-maintainers @org/appsec

ルール:

CODEOWNERS は個人だけでなく teams を使う。
Security-sensitive directories には security または platform review を必須にする。
Workflow changes には DevSecOps または platform review を必須にする。
CODEOWNERS file changes には platform/security owners の承認を必須にする。

6.3 Repository Admin Reduction

Repository admin rights は制限します。

最小ポリシー:

Developers は通常 Write。
Maintainers は Maintain。
Admin は repository owners と platform/security administrators に限定する。
Critical repositories の Admin access は毎月、それ以外は四半期ごとにレビューする。
Direct user admin grants は teams ベースへ移行する。

7. Branch Protection and Rulesets

GitHub rulesets は、リポジトリとブランチ全体に一貫したポリシーを適用するための標準手段として使います。

広範な適用には organization rulesets を使います。特定リポジトリにより厳しい統制が必要な場合にのみ repository rulesets を使います。

7.1 Required Rules for Default Branches

適用対象:

main
master
release/*
hotfix/*
production

最小必須統制:

Require pull request before merge
標準リポジトリでは少なくとも 1 approving review
Critical repositories では少なくとも 2 approving reviews
Require review from CODEOWNERS
新しいコミットが push されたら stale approvals を dismiss
Require conversation resolution before merge
Require status checks to pass
実務上可能な場合、Require branch to be up to date before merge
Require signed commits
Block force pushes
Block branch deletion
Restrict who can push
Restrict who can bypass
運用上適切な場合、Require linear history

7.2 Required Status Checks

推奨 required checks:

Unit tests
Build
Linting
SAST / CodeQL or equivalent
SCA / dependency scan
Secret scan check
Infrastructure repositories では IaC scan
Container images を build する場合は container image scan
必要な場合は license policy check
Pull requests に対する dependency review
.github/workflows/ に対する workflow policy check

Critical repositories では、required security checks が失敗した場合に merge を許可してはいけません。

7.3 Signed Commits

Signed commits は、なりすましや不正な commit injection のリスクを下げます。

Organization standard:

Protected branches では signed commits を必須にする。
Developers は SSH signing、GPG、または GitHub が対応する S/MIME を使って Git commit signing を設定する。
Bot accounts は verified signing keys を使う。
Unsigned commits は protected branches に受け入れない。
例外は legacy migration 目的の文書化された承認に限定する。

SSH signing の開発者設定例:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

検証:

git log --show-signature -1

運用上の注意:

Required signed commits は、bot が正しく設定されていない場合、既存の自動化を壊すことがあります。その場合は branch rule を弱めるのではなく、自動化を修正してください。

7.4 Require Verified Commit Email

Rulesets や enterprise policy で対応している場合、commit metadata が承認済みドメインと一致するようにします。

推奨標準:

業務上の commit は承認済み corporate email domains を使う。
承認がない限り、本番 commit history に personal email addresses を含めない。
sensitive repositories では unknown または disposable domains からの commit を防ぐ。

7.5 Block Dangerous File Paths

Rulesets、code owners、CI checks を使い、機微なパスを保護します。

.github/workflows/**
.github/actions/**
terraform/**
k8s/**
helm/**
Dockerfile
docker-compose.yml
scripts/deploy/**
Makefile
package.json
package-lock.json
pom.xml
build.gradle
requirements.txt
go.mod
Cargo.toml

リスク:

workflow、package manifest、Terraform file、deployment script を変更する Pull Request は、application code が無害に見えても supply chain attack になり得ます。

7.6 Ruleset Evidence Requirements

Rulesets と branch protections は監査可能であるべきです。

各 protected branch または ruleset について、次を保持します。

Evidence	Purpose
Ruleset name and ID	どの policy が適用されているかを証明する
Target repositories and branches	カバレッジを確認する
Required reviewers and approval count	review control を確認する
Required status checks	CI/security gates を確認する
CODEOWNERS requirement	ownership review を確認する
Bypass actors	誰が control を override できるかを確認する
Enforcement mode	evaluate-only ではなく active enforcement であることを確認する
Last modified timestamp	change review を支援する
Export/API snapshot	audit evidence を支援する

Ruleset drift は自動検知するべきです。次の場合はアラートします。

ruleset が disabled または deleted になった。
required status check が削除された。
bypass actor が追加された。
repository が organization ruleset から除外された。
protected branch pattern が弱められた。
critical repository に enforced ruleset が一致していない。

8. Pull Request Security Workflow

Pull Request は単なるコラボレーション機能ではありません。信頼されたブランチへコードが入る前のセキュリティチェックポイントです。

8.1 Pull Request Requirements

production-impacting repositories では、次を必須にします。

linked issue または change ticket
変更内容の説明
risk impact
testing evidence
production changes の rollback plan
sensitive components に対する security review
required status checks
code owner approval

推奨 Pull Request template:

## What changed?

## Why is this change needed?

## Security impact
- [ ] No security impact
- [ ] Auth / authorization changed
- [ ] Secrets / credentials changed
- [ ] Network exposure changed
- [ ] Data handling changed
- [ ] CI/CD workflow changed
- [ ] Infrastructure changed

## Testing performed

## Rollback plan

## Reviewer checklist
- [ ] Code owner reviewed
- [ ] Tests passed
- [ ] Security-sensitive paths reviewed
- [ ] No secrets introduced
- [ ] Dependencies reviewed

8.2 Merge Controls

推奨 merge policy:

Repository Type	Merge Method
Critical production	protected rules とともに squash または merge commit
Libraries / shared packages	release model に応じて squash または rebase
IaC repositories	traceable PR metadata を持つ squash
Audit-sensitive repositories	merge commit の方が review context を保持しやすい場合がある

組織で使わない merge methods は無効化します。これにより、履歴の混乱や一貫性のない運用を減らせます。

8.3 Administrator Bypass

管理者が branch protection や rulesets をデフォルトで bypass できないようにします。

bypass が必要な場合:

bypass actors を break-glass team に限定する。
reason code を必須にする。
SOC/SecOps に alert する。
ticket を自動作成する。
bypass events を 24時間以内にレビューする。
事後理由を文書化する。

9. GitHub Actions Security

GitHub Actions は強力であり、同時に危険でもあります。本番自動化として扱ってください。

悪意ある workflow は次を実行できる可能性があります。

repository contents の読み取り
secrets の exfiltration
poisoned packages の公開
releases の変更
cloud resources の作成
production への deploy
self-hosted runners の悪用
build environments からの token 窃取

9.1 Enterprise and Organization Actions Policy

推奨ポリシー:

すべての public actions をデフォルトで許可しない。
GitHub-authored actions を許可する。
verified creator actions は review 後にのみ許可する。
third-party actions の approved allowlist を維持する。
third-party actions は full-length commit SHA pinning を必須にする。
reusable workflows は approved repositories に制限する。
CI/CD が不要な repositories では Actions を無効化する。
forks からの workflows には approval を必須にする。
default GITHUB_TOKEN permissions は read-only にする。
各 workflow で明示的な permissions を必須にする。

9.1.1 GitHub Actions Threat Model and Abuse Cases

Actions の統制は、現実的な悪用パスと結び付けるべきです。

Abuse Case	Example Attack Path	Required Controls
Workflow file tampering	攻撃者が `.github/workflows/**` を変更して secrets を exfiltrate する	CODEOWNERS、platform/security review、workflow linting、ruleset enforcement
Third-party Action compromise	public Action tag が移動する、または upstream Action が侵害される	Full-length SHA pinning、approved Action allowlist、scheduled review
Overprivileged `GITHUB_TOKEN`	workflow が広い repo write permissions を受け取り、code/releases を変更する	read-only default token、明示的な `permissions:`、job ごとの最小権限
OIDC trust abuse	誤った branch/repo の workflow が production cloud role を assume する	org、repo、branch、environment、workflow による cloud trust restriction
Fork PR secret exposure	untrusted fork code が privileged context で実行される	code execution には `pull_request` を使う、secret exposure を避ける、`pull_request_target` を制限する
Cache poisoning	untrusted job が privileged job に読まれる cache を汚染する	trust level ごとの cache 分離、untrusted branches から privileged restore を避ける
Artifact poisoning	攻撃者が deployment 用の modified build artifact をアップロードする	provenance、attestations、artifact signing、deployment verification
Runner label abuse	job が意図せず privileged self-hosted runner を選択する	runner groups、label governance、branch/environment restrictions、monitoring
Deployment bypass	workflow が approval や change ticket なしに deploy する	GitHub Environments、required reviewers、deployment protection rules、ticket validation

最小設計原則:

Untrusted code は build と test できても、production secrets、privileged tokens、trusted runner access、deployment authority を受け取ってはいけません。

9.2 Pin Actions to Commit SHA

third-party actions を、次のような mutable tag だけに固定してはいけません。

uses: vendor/action@v1

full-length commit SHA を使います。

uses: vendor/action@3df4b6a7d3d8e0e3b8d96f0c0f00000000000000

運用ルール:

Tags can move.
Branches can move.
Full commit SHA が最も安全な参照です。
dependency management または scheduled review を通じて pinned SHAs をレビューし更新する。

9.3 Set Workflow Permissions Explicitly

広い default token permissions に依存してはいけません。

安全なデフォルト:

permissions:
  contents: read

job が必要とする権限だけを付与します。

package publishing の例:

permissions:
  contents: read
  packages: write
  id-token: write

pull request 作成の例:

permissions:
  contents: write
  pull-requests: write

セキュリティルール:

すべての workflow は permissions: を明示する必要があります。

9.4 Use OIDC Instead of Long-Lived Cloud Secrets

GitHub secrets に保存された長命 cloud keys は高リスクです。

推奨パターン:

GitHub Actions → OIDC token → Cloud IAM federation → short-lived cloud credentials

OIDC の利用先:

AWS IAM roles
Azure federated credentials
GCP Workload Identity Federation
Vault federation
OIDC 対応の cloud deployment systems

AWS trust condition の例:

{
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:ORG/REPO:ref:refs/heads/main"
  }
}

最小 OIDC 統制:

organization で制限する。
repository で制限する。
branch、tag、または environment で制限する。
対応している場合は workflow で制限する。
environment ごとに role を分離する。
untrusted branch からの pull request workflow が production roles を assume できないようにする。

クラウド別の実装メモ:

Cloud / Platform	Recommended Constraint	Notes
AWS	`aud` を `sts.amazonaws.com`、`sub` を承認済み repo/ref/environment pattern に制限する	environment ごとに IAM role を分ける。すべての repositories への wildcard は避ける。AWS はすべての custom OIDC claim pattern に対応するわけではないため、trust policy は慎重に設計する
Azure	organization/repository/ref または environment に scoped した federated identity credentials を使う	実務上可能なら staging と production で app registrations または managed identities を分離する
GCP	repository、branch、tag、environment の attribute conditions を持つ Workload Identity Federation を使う	最小権限の service accounts を特定の deployment workflows に bind する
Vault / Secret Broker	approved workflow identity claims に trust を制限し、短命 secrets のみ発行する	狭い TTL と audit trails を持つ dynamic credentials を優先する
Package registries	対応している場合は trusted publishing / OIDC を使う	package release workflows には長命 publishing tokens を避ける

必要な cloud-side evidence:

trust policy または federated credential configuration
mapping された GitHub repository、branch、tag、environment、または workflow
IAM role/service account permissions
session duration または token TTL
federation を使った最後の successful deployment
残存する static cloud key の exception record

9.5 Protect Deployment Environments

deployment approval gates には GitHub Environments を使います。

Production environment requirements:

Required reviewers
有用な場合は wait timer
Branch restrictions
Environment-specific secrets
Deployment history review
feature branches からの direct deployment 禁止
OIDC trust は production environment に制限

例:

jobs:
  deploy:
    environment: production
    permissions:
      contents: read
      id-token: write

9.6 Control Workflow Triggers

次の triggers には注意します。

pull_request_target
workflow_run
repository_dispatch
schedule

高リスクパターン:

on: pull_request_target

重要な理由:

pull_request_target は base repository の context で実行され、誤用すると secrets へアクセスできる場合があります。強力な分離なしに、この trigger の下で untrusted pull request code を checkout して実行してはいけません。

より安全な方法:

untrusted code validation には pull_request を使う。
pull_request_target は labeling など metadata operations のみに使う。
privileged context で pull request の script を実行しない。
untrusted fork workflows に secrets を公開しない。

9.7 Protect Workflow Files

.github/workflows/** へのすべての変更には、信頼された platform/security team の承認を必須にします。

Required CODEOWNERS:

.github/workflows/ @org/devsecops @org/platform-engineering
.github/actions/ @org/devsecops @org/platform-engineering

Required checks:

Workflow linting
OIDC policy validation
Action pinning validation
Permission minimization check
Secret usage review

9.8 Reusable Workflows

安全なデフォルトには reusable workflows を使います。

推奨パターン:

中央の security-approved CI workflow repository
application repositories は reusable workflows を呼び出す
deployment logic を標準化する
OIDC permissions を中央でレビューする
security scanning を一貫させる

例:

jobs:
  secure-build:
    uses: org/platform-workflows/.github/workflows/secure-build.yml@<commit-sha>
    permissions:
      contents: read
      security-events: write

10. Self-Hosted Runner Security

Self-hosted runners は GitHub における最も高リスクな領域の一つです。

runner はコードを実行します。runner が internal systems、cloud metadata、deployment credentials、shared workspace data へネットワークアクセスを持つ場合、悪意ある workflow が内部侵害の経路になります。

10.1 Avoid Persistent Shared Runners for Untrusted Code

最小標準:

public repository workflows を internal self-hosted runners で実行しない。
fork pull requests を privileged self-hosted runners で実行しない。
異なる trust zones で同じ persistent runner を共有しない。
runners を flat internal networks に置かない。
runners に standing cloud credentials を持たせない。
sensitive workflows では可能な限り ephemeral runners を使う。

10.2 Runner Trust Zones

runner groups を分離します。

Runner Group	Allowed Workloads	Network Access	Notes
public-untrusted	Public repo validation	No internal access	GitHub-hosted runners を優先
internal-build	Internal CI builds	Limited package/cache access	production access なし
staging-deploy	Staging deployment	Staging only	OIDC scoped to staging
production-deploy	Production deployment	Production deployment endpoints only	approval required
security-scanning	SAST/SCA/container scans	Scanner-specific access	broad secrets なし

10.3 Runner Hardening

必須統制:

可能な場合は ephemeral runners を使う。
各 job または job group 後に runner を再構築する。
可能な場合は non-root で実行する。
不要な tools を無効化する。
必要な宛先を除き outbound internet を制限する。
cloud metadata endpoints へのアクセスを制限する。
secrets を disk に保存しない。
job 完了後に workspace を削除する。
OS、runner、workflow logs を central logging へ転送する。
runner images を定期的に patch する。
group ごとに runner registration tokens を分離する。
runner registration tokens を rotate する。
unexpected runner registration and removal を監視する。

10.4 Network Segmentation

Production deployment runners には、deployment に必要なネットワークアクセスだけを与えます。

悪いパターン:

runner → entire VPC / entire corporate network

より良いパターン:

runner → deployment API / artifact registry / secret broker / Kubernetes API through controlled endpoint

10.5 Runner Detection Coverage

監視対象:

New self-hosted runner added
Runner group policy changed
Runner assigned to additional repositories
Workflow using unexpected runner labels
Job running on production runner from non-production branch
Unusual outbound connections from runner
Access to metadata IP
Unexpected process execution
Secret exfiltration patterns
Large artifact uploads

11. Secrets Management

GitHub 内の secrets は厳格に管理する必要があります。workflow が誤って設計されると、secrets が露出する可能性があるためです。

11.1 Use the Right Secret Scope

最も狭い scope を使います。

Scope	Use Case	Guidance
Repository secret	単一 repository のみ	repo-specific secret では推奨
Environment secret	deployment environment	production secrets では推奨
Organization secret	shared non-production または shared tooling	selected repositories に制限
Enterprise secret	enterprise-wide use	慎重に使う

絶対に必要な場合を除き、production secrets を broad organization secrets として保存しないでください。

11.2 Replace Static Secrets with Federation

優先順位:

OIDC federation
Vault や cloud secret manager などの secret broker with short-lived credentials
Environment-scoped GitHub secrets
Repository-scoped GitHub secrets
selected repositories に制限された Organization secrets
長命 cloud keys は例外扱いのみ

11.3 Enable Secret Scanning and Push Protection

次を有効化します。

Secret scanning
Push protection
対応している場合は validity checks
internal token formats 用 custom secret scanning patterns
security team と repository owners への alerts

Push protection は、secrets が repository に入る前に多くをブロックするため重要です。

11.4 Secret Rotation

次の場合に secrets を rotate します。

exposure 直後
access 権限を持つユーザーの退職時
repository transfer 時
integration decommission 時
high-risk secrets の定期スケジュール
suspicious workflow execution 後

最小証跡:

Secret owner
Purpose
Scope
Created date
Last rotated date
Repositories with access
Rotation procedure
Emergency revocation procedure

12. Personal Access Tokens

Personal access tokens は、適切に統制されない場合、SSO、MFA、最小権限の迂回経路になりやすいものです。

12.1 Restrict Classic PATs

ポリシー:

organization resources への classic PAT access を制限する。
可能な場合は classic PAT をブロックする。
例外には承認を必須にする。
Fine-grained PAT を優先する。
expiration を必須にする。
least-privilege scopes を必須にする。
active tokens を定期的にレビューする。

Classic PATs は broad、long-lived、governance が難しいためリスクが高いです。

12.2 Fine-Grained PAT Standard

Fine-grained PATs には次を必須にします。

specific repository access
required permissions only
expiration date
business justification
owner
approval
review date

禁止事項:

no-expiry tokens
broad all-repository access
production automation に personal accounts が所有する tokens を使うこと
GitHub Apps または OIDC で置き換えられる用途に tokens を使うこと

12.3 Service Accounts and Automation

自動化の優先順位:

minimal permissions の GitHub App
OIDC federation
expiry 付き fine-grained PAT
Classic PAT は例外のみ

Automation accounts は次を満たす必要があります。

明確な名前
owner
対応可能な場合は MFA
documented purpose
access review
approved secret manager に credential を保存
human shared use を避ける

12.4 PAT Containment Procedure

PAT が漏えい、または侵害が疑われる場合:

token を直ちに revoke する。
token owner を特定する。
token がアクセス可能だった scopes と repositories を特定する。
token activity の audit logs をレビューする。
repository clone、push、release、workflow、package、secret access events を確認する。
token がアクセスできた downstream secrets を rotate する。
release integrity が不確かな場合は artifacts を rebuild する。
incident ticket を作成する。
再発防止の detection または prevention rule を追加する。
post-incident review を完了する。

13. OAuth Apps and GitHub Apps

サードパーティ連携は重要な data access path です。

13.1 Restrict OAuth App Access

Organization で OAuth App access restrictions を有効化します。

ポリシー:

ユーザーが承認なしに OAuth Apps に organization resources へのアクセスを許可できないようにする。
OAuth App requests は Security または Platform Engineering がレビューする。
Approved apps には business owner を必須にする。
Approved apps には documented scopes を必須にする。
未使用 apps は削除する。
broad access を持つ apps は四半期ごとにレビューする。

レビューチェックリスト:

app の owner は誰か。
どの repositories にアクセスできるか。
どの scopes を要求しているか。
write access が必要か。
private repositories にアクセスするか。
repository data を外部に保存するか。
vendor は承認済みか。
vendor は SOC 2 / ISO 27001 または同等の証跡を持つか。
より安全な GitHub App alternative はあるか。

13.2 Prefer GitHub Apps Over OAuth Apps

GitHub Apps は selected repositories と specific permissions に制限しやすいため、通常 OAuth Apps よりスコープ管理が容易です。

ポリシー:

Organization integrations には OAuth Apps より GitHub Apps を優先する。
enterprise-wide access が正当化されない限り、selected repositories のみに install する。
broad write permissions を避ける。
installations を四半期ごとにレビューする。
unused installations を削除する。

13.3 App Inventory

app inventory を維持します。

Field	Required
App name	Yes
Type	OAuth App / GitHub App
Owner	Yes
Business purpose	Yes
Permissions	Yes
Repository access	Yes
Vendor risk status	Yes
Approval date	Yes
Review date	Yes
Removal procedure	Yes

14. Repository Content and Secret Exposure Controls

14.1 Prevent Sensitive Data in Repositories

保存してはいけないもの:

Production secrets
Private keys
Customer data
Database exports
Access tokens
secrets を含む .env files
Cloud credentials
SSH private keys
Unredacted logs
アクセス制御されていない vulnerability scan exports with exploitable details
アクセス制御されていない incident data

.gitignore、pre-commit hooks、push protection、CI scanning を組み合わせて使います。

.gitignore ベースライン例:

.env
.env.*
*.pem
*.key
*.p12
*.pfx
id_rsa
id_ed25519
secrets.*
credentials.*
*.kubeconfig

14.2 Pre-Commit Controls

推奨する developer-side controls:

pre-commit install

推奨 hooks:

Secret scanning
YAML validation
JSON validation
Terraform formatting
Dependency lockfile check
Large file check
Private key detection

developer controls は有用ですが、それだけでは不十分です。server-side push protection と CI scanning も必要です。

15. Code Security and Dependency Security

15.1 Code Scanning

対応言語では code scanning を有効化します。

最小標準:

active repositories では CodeQL または approved SAST tool を有効化する。
production code では critical findings がある pull requests を失敗させる。
findings は repository owners に assign する。
false positives は文書化する。
suppressions には justification を必須にする。
security team は SLA compliance を追跡する。

Severity SLA の例:

Severity	SLA
Critical	7 days
High	14 days
Medium	30 to 60 days
Low	Risk-based backlog

15.2 Dependency Security

次を有効化します。

Dependabot alerts
Dependabot security updates
Dependency review on pull requests
Lockfile maintenance
必要に応じた license review

Dependency review は、次を導入する pull requests をブロックするべきです。

known critical vulnerabilities
disallowed licenses
unmaintained critical packages
suspicious package source changes
dependency confusion risk

15.3 Package Registry Controls

GitHub Packages または外部 registries では次を行います。

publishers に MFA を必須にする。
最小権限の automation tokens を使う。
可能な場合は provenance または signed artifacts を必須にする。
package を publish できる主体を制限する。
package deletion と version overwrite attempts を監視する。
可能な場合は immutable versioning を使う。
dev、staging、production package namespaces を分離する。

16. Software Supply Chain Controls

16.1 Artifact Attestations

critical builds では artifact attestations を使います。

目的:

artifact がどこから来たかを証明する。
どの workflow が build したかを証明する。
どの repository と commit が生成したかを証明する。
downstream verification を支援する。

対象:

Container images
Release binaries
Packages
Deployment artifacts

最小ポリシー:

Critical production artifacts には provenance を必須にする。
deployment systems は deployment 前に provenance を検証するべき。
実現可能な場合、Kubernetes admission control は critical workloads の provenance を強制する。

16.2 Signed Releases and Tags

推奨統制:

release branches を保護する。
release tags を保護する。
release process が対応する場合、production releases には signed tags を必須にする。
release を作成できる主体を制限する。
release assets を upload できる主体を制限する。
release creation、deletion、asset changes を監視する。

16.3 Secure Build Separation

次を分離します。

PR validation → build → test → security scan → release → deploy

untrusted pull request code に production secrets または deployment roles へのアクセスを許可してはいけません。

17. Forks, Public Repositories, and Open Source Exposure

17.1 Private Repository Forks

Private forks は、sensitive code をより弱い統制下へコピーする可能性があります。

ポリシー:

private repository forking はデフォルトで無効化する。
必要な場合にのみ forks を承認する。
fork access をレビューする。
stale forks を削除する。
fork workflows に production secrets を許可しない。
forks からの Actions execution を制限する。

17.2 Public Repository Controls

Public repositories は、ミスが即座に外部公開されるため、より厳格なレビューが必要です。

最小統制:

公開前の security review
公開前の legal/IP review
公開前の full history secret scan
dependency and license review
CODEOWNERS enabled
Branch protection enabled
internal-only documentation を含めない
customer data、credentials、endpoints、private architecture details、exploit details を含めない

17.3 Open Source Contribution Safety

public repositories では次を行います。

forks からの pull requests は untrusted として扱う。
forked PR workflows に secrets を公開しない。
code execution には pull_request を使う。
厳密に制限された用途を除き pull_request_target を避ける。
first-time contributors の workflows 実行前に maintainer approval を必須にする。

18. GitHub Pages, Wikis, Discussions, and Issues

これらの機能は、ソースコードが管理されていてもデータを露出させる可能性があります。

ポリシー:

必要がない限り GitHub Pages を無効化する。
Pages source branches を制限する。
custom domains と DNS ownership をレビューする。
必要がない限り Wikis を無効化する。
必要がない限り Discussions を無効化する。
data-handling warnings を含む issue templates を使う。
issues に secrets、customer data、incident details、vulnerability details を記載させない。
vulnerability intake には private vulnerability reporting または security advisories を使う。

19. Copilot and AI Coding Controls

GitHub Copilot や AI coding tools を有効化する場合、データ露出リスクを持つ開発ツールとして統制します。

最小統制:

approved use cases を定義する。
secrets、customer data、private keys、regulated data を prompts に貼り付けることを禁止する。
利用プランで利用可能な enterprise policy settings を設定する。
AI-generated code は human-written code と同様に developers がレビューする。
AI-assisted code には SAST/SCA scanning を必須にする。
AI-assisted development により導入された insecure code patterns を追跡する。
license and dependency risks をレビューする。

運用ルール:

AI-generated code は secure coding、review、testing、security scanning を迂回できません。

20. Audit Logging and SOC Monitoring

GitHub logs は cloud control-plane logs と同様に監視する必要があります。

20.1 Export Audit Logs

GitHub audit logs を SIEM または central log lake へ送信します。

必要な log sources:

Enterprise audit log
Organization audit log
GitHub Actions workflow events
Repository events
Secret scanning alerts
Code scanning alerts
Dependabot alerts
Authentication and SSO events
OAuth and GitHub App events
Runner events
Branch/ruleset changes
Repository visibility changes

20.2 High-Value Detection Use Cases

次の events を監視します。

Detection	Why It Matters
Organization owner added	privilege escalation の可能性
SAML SSO disabled or modified	identity control bypass
MFA requirement disabled	account protection weakened
Repository changed from private/internal to public	source/data exposure
Secret scanning disabled	prevention/detection weakened
Actions policy weakened	CI/CD attack surface increased
New self-hosted runner added	execution foothold の可能性
Runner group expanded	workflow compromise blast radius の拡大
New OAuth App approved	third-party data access
Classic PAT used against org	token governance bypass
Branch protection or ruleset disabled	change-control bypass
Force push to protected branch	history tampering
Release asset modified	supply chain compromise
Workflow file changed	CI/CD execution path changed
Large clone/download activity	source exfiltration の可能性

20.2.1 Production Detection Specification Template

高価値の GitHub 検知は、単なるチェックリスト項目ではなく managed detection として展開するべきです。

テンプレート:

rule_id: GH-DET-0001
name: Organization Owner Added
threat_scenario: Privilege escalation or persistence through GitHub organization ownership
data_sources:
  - GitHub organization audit log
  - Identity provider logs
  - Change management tickets
severity: Critical
confidence: High
logic: >
  Alert when an organization owner is added, restored, or when ownership is granted
  outside an approved change window or without a matching change ticket.
required_fields:
  - actor
  - target_user
  - organization
  - action
  - timestamp
  - source_ip
  - user_agent
  - SSO/IdP context
false_positives:
  - Approved emergency ownership recovery
  - Planned administrative change
triage:
  - Validate change ticket and approver
  - Verify actor identity and MFA/SSO status
  - Review actor's recent GitHub activity
  - Check IdP logs for suspicious login or impossible travel
  - Confirm whether new owner changed settings, tokens, apps, runners, or rulesets
response:
  - Escalate to Incident Commander if unauthorized
  - Remove unauthorized owner
  - Revoke sessions and tokens for involved identities
  - Review organization settings and audit log for follow-on activity
owner: SOC / Security Engineering
review_cadence: Quarterly

推奨 detection catalog:

Detection ID	Detection	Severity	Primary Risk
GH-DET-001	Organization owner added or restored	Critical	Privilege escalation
GH-DET-002	SAML SSO, MFA, or enterprise identity setting weakened	Critical	Identity control bypass
GH-DET-003	Repository changed from private/internal to public	Critical	Source/data exposure
GH-DET-004	Ruleset or branch protection disabled, deleted, or bypass actor added	High/Critical	Source integrity compromise
GH-DET-005	Workflow file changed in critical repository	High	CI/CD compromise
GH-DET-006	New self-hosted runner or runner group policy changed	High	Runner compromise path
GH-DET-007	OAuth App or GitHub App approved with broad private repo access	High	Third-party data access
GH-DET-008	Classic PAT or broad fine-grained PAT approved	High	Token-based bypass
GH-DET-009	Secret scanning alert or push protection bypass	High	Credential exposure
GH-DET-010	Release, tag, package, or artifact modified unexpectedly	High	Supply-chain compromise
GH-DET-011	Large clone, unusual archive download, or mass repository access	Medium/High	Source-code exfiltration
GH-DET-012	GitHub Actions job uses unexpected privileged runner label	High	Runner trust-zone violation

Detection quality metrics:

Alert volume
True-positive rate
False-positive rate
Mean time to triage
Mean time to contain
Percentage of alerts with complete required fields
Percentage of critical repositories covered
Detection drift or broken parser count

20.3 Example SIEM Detection Logic

疑似ロジック:

IF github.event IN (
  "org.update_member",
  "org.add_member",
  "org.add_owner",
  "repo.visibility_change",
  "repo.transfer",
  "protected_branch.destroy",
  "ruleset.destroy",
  "oauth_application.create",
  "self_hosted_runner.create"
)
AND actor NOT IN approved_admins
THEN alert severity = high

Source exfiltration の場合:

IF actor clones OR downloads many private repositories
AND actor is unusual for that repository set
AND activity occurs outside normal geography or working pattern
THEN alert severity = high

Workflow tampering の場合:

IF file_path MATCHES ".github/workflows/**"
AND actor NOT IN platform_security_or_devsecops
THEN alert severity = high

20.4 Triage Steps

高リスク GitHub alerts では次を行います。

actor、account type、team、employment status を特定する。
変更が承認済みか確認する。
影響を受けた repositories をレビューする。
関連する workflow runs をレビューする。
token、OAuth、app activity を確認する。
recent authentication and SSO events を確認する。
secrets または releases へアクセスされたか確認する。
unauthorized の場合は containment する。
audit logs と timeline を保存する。
malicious または unexplained の場合は incident record を作成する。

21. Incident Response Playbooks for GitHub

21.1 Compromised User Account

即時対応:

user を organization から suspend または remove する。
利用可能な場合は active sessions を revoke する。
PATs と SSH keys を revoke する。
OAuth authorizations を revoke する。
recent repository access をレビューする。
pushes、PRs、workflow runs、releases、package activity をレビューする。
user がアクセスできた secrets を rotate する。
unauthorized code changes を revert する。
integrity が不確かな場合は artifacts を rebuild する。
root cause と detection improvement を完了する。

21.2 Leaked Secret

即時対応:

source system で secret を revoke する。
replacement credential を rotate する。
secret を含む repositories と branches を特定する。
secret が accessed または used されたかをレビューする。
active code から secret を削除する。
必要かつ運用上安全な場合にのみ history を clean する。
affected owners へ通知する。
secret type が検知されなかった場合は custom pattern を追加する。
なぜ push protection がブロックしなかったかをレビューする。

21.3 Malicious Workflow Execution

即時対応:

workflow が still running または recurring の場合は disable する。
active workflow runs を cancel する。
exposed tokens を revoke する。
workflow がアクセスできた secrets を rotate する。
runner logs と system state をレビューする。
self-hosted runners を rebuild する。
生成された artifacts と packages をレビューする。
downstream deployment impact を確認する。
root cause が修正されるまで Actions policy を制限する。
workflow policy checks を追加する。

21.4 Suspected Source Code Exfiltration

即時対応:

audit logs を保存する。
actor と accessed repositories を特定する。
clone/download scope を判断する。
compromised access を disable する。
使用された tokens と apps をレビューする。
regulated または sensitive data が関係する可能性がある場合は Legal/Privacy を関与させる。
embedded secrets があれば rotate する。
public exposure risks をレビューする。
executive summary を作成する。
access model と detection logic を更新する。

22. Backup, Recovery, and Business Continuity

GitHub の可用性と完全性は重要です。

最小統制:

critical repositories には repository backup strategy を維持する。
必要な場合は repository metadata を export する。
release artifacts または rebuild provenance を保存する。
実務上可能な場合、critical GitHub configuration を configuration as code として backup する。
deleted repository、compromised branch、lost admin access に対する recovery procedures を文書化する。
少なくとも年1回 recovery をテストする。

Backup scope:

Git repositories
Protected branch / ruleset configuration
CODEOWNERS
Workflow files
Release metadata
可能な場合は Package metadata
Repository settings inventory
Team and access inventory
Security alert exports

23. Secure Configuration as Code

GitHub セキュリティをクリック操作だけで管理してはいけません。

Terraform、GitHub APIs、または承認済み自動化を使い、次を管理します。

Repository creation
Team management
Repository access
Branch protection
Rulesets
Actions policy
Repository topics and metadata
Secret scanning enablement
Default settings
Webhooks

利点:

reviewable changes
audit trail
drift detection
repeatability
faster onboarding
easier rollback

最小標準:

GitHub administrative changes は、実務上可能な場合 Pull Request review を通す。
security-sensitive GitHub configuration changes には platform/security approval を必須にする。
drift reports は毎月レビューする。

23.1 Automation and Drift Detection

Configuration as code は、安全な設定を作成するだけでは不十分です。継続的に drift を検知する必要があります。

推奨 automation model:

Layer	Automation
Inventory	APIs で repository、team、owner、runner、app、token、ruleset、security feature state を取得する
Classification	data classification、production impact、owner、deployment authority の repository metadata を必須にする
Policy evaluation	current settings を control catalog と repository classification に照らして評価する
Remediation	non-compliant settings に対して tickets または pull requests を自動作成する
Enforcement	approved automation により organization rulesets、branch protections、Actions policies、repository defaults を適用する
Evidence	policy state、exceptions、remediation status の signed snapshots を保存する
Alerting	critical drift は backlog ticket だけでなく SIEM/SOC へ送る

低リスクで可逆的かつ承認済みでない限り、自動化に破壊的変更を黙って実行させてはいけません。users の削除、deploy workflows の無効化、broad access の revoke など高リスク変更には human approval gate を使います。

対応を促すべき drift の例:

enforced ruleset のない critical repository
Secret scanning disabled
Push protection disabled
Actions policy changed to allow all public actions
Self-hosted runner added to broad repository group
Repository admin added directly instead of through team
Public visibility enabled
Required security status check removed
Bypass actor added to production branch ruleset
Repository missing owner or classification metadata

24. Repository Onboarding Checklist

すべての新規 repository は、本番利用前にこのチェックリストを完了する必要があります。

# GitHub Repository Security Onboarding Checklist

Repository:
Owner:
Business service:
Data classification:
Production impact: Yes / No
Internet-facing: Yes / No

## Access
- [ ] Repository owner assigned
- [ ] Team-based access configured
- [ ] No unnecessary direct user grants
- [ ] Admin access minimized
- [ ] Outside collaborators approved and expiry set

## Protection
- [ ] Organization ruleset applies
- [ ] Default branch protected
- [ ] Pull requests required
- [ ] CODEOWNERS configured
- [ ] Signed commits required
- [ ] Required status checks configured
- [ ] Force pushes blocked
- [ ] Branch deletion blocked

## Security scanning
- [ ] Secret scanning enabled
- [ ] Push protection enabled
- [ ] Code scanning enabled
- [ ] Dependency scanning enabled
- [ ] Dependency review enabled
- [ ] IaC scanning enabled if applicable
- [ ] Container scanning enabled if applicable

## Actions
- [ ] GitHub Actions required for this repository
- [ ] Workflow permissions explicitly set
- [ ] Third-party actions pinned to SHA
- [ ] OIDC used instead of cloud static keys
- [ ] Environments configured for deployment
- [ ] Workflow changes require CODEOWNER review
- [ ] Self-hosted runner use approved if applicable

## Release
- [ ] Release owners defined
- [ ] Tag protection configured where applicable
- [ ] Artifact signing/provenance configured where applicable
- [ ] Package publishing restricted

## Monitoring
- [ ] Repository included in audit monitoring
- [ ] Security alerts routed to owner
- [ ] Incident contact defined

25. Quarterly GitHub Security Review

四半期ごとに実施します。

Identity and Access

organization owners をレビューする。
enterprise owners をレビューする。
repository admins をレビューする。
outside collaborators をレビューする。
dormant users をレビューする。
service accounts をレビューする。
direct repository grants をレビューする。
SSO と MFA enforcement を確認する。

Applications and Tokens

OAuth Apps をレビューする。
GitHub Apps をレビューする。
fine-grained PAT approvals をレビューする。
classic PAT usage をレビューする。
unused tokens を revoke する。
unused integrations を revoke する。

Repositories

public repositories をレビューする。
archived repositories をレビューする。
owner がいない repositories をレビューする。
recent activity がない repositories をレビューする。
rulesets がない repositories をレビューする。
security scanning がない repositories をレビューする。
private forks をレビューする。

CI/CD

privileged permissions を使う workflows をレビューする。
pull_request_target を使う workflows をレビューする。
unpinned actions を使う workflows をレビューする。
write tokens を持つ workflows をレビューする。
OIDC trust policies をレビューする。
deployment environment approvals をレビューする。
runner groups and labels をレビューする。

Alerts and Incidents

open secret scanning alerts をレビューする。
open code scanning alerts をレビューする。
Dependabot backlog をレビューする。
bypass events をレビューする。
security exceptions をレビューする。
GitHub incidents and lessons learned をレビューする。

26. Metrics for Leadership

統制カバレッジとリスク低減を示す指標を使います。

Metric	Target
MFA enforcement rate	100%
SSO enforcement coverage	org access で 100%
Repositories with active owner	100%
Critical repos with rulesets	100%
Critical repos requiring signed commits	100%
Critical repos with CODEOWNERS	100%
Repositories with secret scanning	supported の場合 100%
Repositories with push protection	supported の場合 100%
Active critical/high code scanning findings past SLA	0
Active leaked secret alerts past SLA	0
Classic PAT usage	0 または formally excepted
Unapproved OAuth Apps	0
Self-hosted runners without owner	0
Production deployments using long-lived cloud keys	0 または exception-approved
GitHub audit logs forwarded to SIEM	100%

一時点の数値だけでなく、傾向を報告します。

27. Exception Handling

一部の repositories がすぐにベースラインを満たせないことはあります。重要なのは、例外が可視化され、リスク承認され、期限付きであることです。

Exception request には次を含めます。

Control not met
Repository or organization scope
Business justification
Risk impact
Compensating controls
Owner
Expiry date
Remediation plan
Approval

ルール:

permanent exceptions は認めない。
Critical repositories には CISO または delegated security approval を必須にする。
expired exceptions は escalation する。
exceptions は毎月レビューする。

28. 30 / 60 / 90 日ハードニング計画

最初の30日: 最大リスクを止める

MFA を強制する。
SSO を強制する、または identity integration roadmap を確認する。
organization owners を削減する。
base permissions を no permission または read に設定する。
repository creation と visibility changes を制限する。
outside collaborator invitations を制限する。
OAuth App restrictions を有効化する。
classic PATs を制限する。
secret scanning と push protection を有効化する。
critical repositories に branch protection または rulesets を適用する。
Actions default token permissions を read-only に設定する。
critical repositories では unapproved Actions をブロックする。
self-hosted runners を inventory する。
audit logs を SIEM へ export する。

31〜60日: 統制を標準化する

organization rulesets を実装する。
protected branches で signed commits を必須にする。
critical repositories で CODEOWNERS を必須にする。
reusable workflows を標準化する。
third-party Actions を SHAs に pin する。
production deployments の cloud secrets を OIDC に置き換える。
self-hosted runner groups を segment する。
code scanning と dependency review を有効化する。
repository onboarding automation を構築する。
app and token inventory を構築する。
GitHub incident response playbooks を作成する。

61〜90日: 成熟化・自動化する

GitHub configuration を code として管理する。
drift detection を実装する。
high-risk GitHub events に対する SIEM detections を追加する。
critical builds に artifact attestations を実装する。
実務上可能な場合、deployment で provenance を強制する。
GitHub compromise tabletop を実施する。
supply chain attack simulation を実施する。
metrics を leadership とレビューする。
残存 exceptions を解消または正式承認する。

29. GitHub Enforcement Location Map

このセクションは、各推奨統制を GitHub のどこで強制するか、どの設定を変更するか、どの証跡を取得するかを管理者向けに示します。GitHub の製品ナビゲーションは時間とともに変わるため、ここに示すパスは運用ガイダンスとして扱い、展開前に自社の GitHub Enterprise または Organization UI で確認してください。

このセクションは appendix の control catalog と組み合わせて使います。

Control ID → GitHub location → Setting to configure → Evidence to capture

29.1 Enforcement Scope Reference

Scope	Typical GitHub Location	Used For
Enterprise	Enterprise account → Settings	enterprise identity、Actions policy、audit log streaming、enterprise-wide security and policy controls
Organization	Organization → Settings	SSO、MFA、base permissions、repository governance、Actions policy、OAuth/PAT policy、security defaults
Repository	Repository → Settings	branch protection、rulesets、Actions、environments、secrets、code security、Pages、webhooks
Security Overview / Security Configurations	Organization または enterprise security views	security feature coverage、secret scanning、code scanning、Dependabot、vulnerability management
API / Terraform / GitHub CLI	GitHub REST/GraphQL API、Terraform provider、`gh` CLI	evidence export、drift detection、policy-as-code、bulk remediation

運用ルール:

すべての統制は、enforcement が enterprise、organization、repository、workflow、cloud、process のどの layer で行われるかを明確にする必要があります。GitHub に native setting がない場合は、compensating automation、required evidence、manual review owner を文書化してください。

29.2 Control-by-Control Enforcement Instructions

Control ID	Where to Enforce in GitHub	What to Configure	Evidence to Capture
GH-GOV-01	単一の GitHub toggle はありません。security governance documentation で管理し、organization teams と repository metadata に ownership を反映します。	enterprise/org settings、repositories、Actions、secrets、apps、runners、security alerts、audit logs の accountable owners を定義します。`platform-admins`、`security-admins`、service owner teams などの GitHub teams を作成します。	RACI、owner register、GitHub team list、repository owner metadata、quarterly review ticket。
GH-ID-01	Enterprise または Organization → Settings → Authentication security / SAML single sign-on。Enterprise Managed Users の場合は Enterprise → Settings → Authentication and provisioning。	SAML SSO または Enterprise Managed Users を強制します。利用可能な場合は SCIM を設定します。IdP groups を GitHub teams へ map します。Organization access には SSO authorization を必須にします。	SSO enforcement screenshot/export、IdP group mapping、SCIM configuration、sample deprovisioning evidence。
GH-ID-02	Organization → Settings → Authentication security。Enterprise policies でも user security controls を強制できる場合があります。	すべての organization members に two-factor authentication を必須にします。対応している場合、outside collaborators と privileged users も同じ要件を満たすことを確認します。	MFA requirement screenshot/export、non-compliant users のリスト、removal/suspension evidence。
GH-ID-03	Organization → People → Owners。該当する場合は Enterprise → People / Administrators。	organization owners を最小化します。不要な owner access を削除します。named accounts のみを使います。routine administration は delegated teams または custom roles へ移します。	Owner list export、monthly review record、removal tickets、break-glass account record。
GH-ACCESS-01	Organization → Teams; Organization → People; Repository → Settings → Collaborators and teams。	repository access は teams 経由で付与します。例外承認がない限り direct user grants を削除します。利用可能な場合は IdP groups を GitHub teams に map します。	Team-to-repository access export、direct access report、exception register。
GH-ORG-01	Organization → Settings → Member privileges → Base permissions。	base permission を `No permission` に設定します。明示承認がある場合のみ `Read` を使います。広範な `Write` は使いません。	Organization settings screenshot/API export、base permission が `No permission` でない場合の exception approval。
GH-ORG-02	Organization → Settings → Member privileges and Repository defaults。	repository creation、deletion、transfer、visibility changes、outside collaborator invitations を制限します。repository creation は approved teams に限定します。public repositories には approval を必須にします。	Organization privilege settings export、repository creation permission list、visibility/deletion/transfer audit events。
GH-REPO-01	Repository → About/sidebar metadata、repository topics、custom inventory、または policy-as-code inventory。	business owner、technical owner、classification、production-impact flag、deployment authority flag、OIDC/cloud access flag、last review date を必須にします。GitHub はすべての metadata fields を native enforce できないため、repository onboarding automation と inventory checks で強制します。	Repository inventory export、onboarding checklist、metadata validation report、missing-owner report。
GH-REPO-02	Repository root → `CODEOWNERS`; Repository → Settings → Rules → Rulesets または Branches → Branch protection。	global ownership と `.github/workflows/`、`terraform/`、`k8s/`、`auth/`、release/package files などの sensitive paths に CODEOWNERS entries を追加します。rulesets または branch protection で CODEOWNERS review を必須にします。	CODEOWNERS file、code owner review を必須にする ruleset、blocked/approved PR のサンプル証跡。
GH-RULE-01	Organization → Settings → Rules → Rulesets、または Repository → Settings → Rules → Rulesets / Branches → Branch protection rules。	`main`、`master`、`release/`、`hotfix/`、`production` 向けの enforced rulesets を作成します。pull requests、approval count、CODEOWNERS review、required status checks、signed commits、conversation resolution、force pushes blocking、deletions blocking、bypass restriction を必須にします。	Ruleset export/API snapshot、enforcement mode、protected branch patterns、required checks list、bypass actor list。
GH-RULE-02	Organization または Repository → Settings → Rules → Rulesets → Bypass list。Branch protection を使う場合は branch protection bypass controls。	bypass actors はデフォルトで空にするか break-glass team に限定します。bypass use には approval、reason code、ticket reference、SOC alerting を必須にします。	Bypass actor export、break-glass approval record、bypass event の SIEM alert、post-event review ticket。
GH-ACT-01	Enterprise または Organization → Settings → Actions → General。Repository override: Repository → Settings → Actions → General。	不要なリポジトリでは Actions を無効化します。allowed Actions と reusable workflows を制限します。GitHub-authored Actions と approved third-party Actions のみ許可します。third-party Actions は workflow linting または policy-as-code で full-length commit SHA pinning を必須にします。	Actions policy export、allowed Actions list、SHA pinning を示す workflow scan、exception list。
GH-ACT-02	Organization → Settings → Actions → General → Workflow permissions。Repository override は Repository → Settings → Actions → General。workflow files は `.github/workflows/*.yml`。	default `GITHUB_TOKEN` permissions を read-only にします。“Allow GitHub Actions to create and approve pull requests” は無効化、または厳格に制御します。すべての workflow に明示的な `permissions:` を必須にします。	Organization/repository Actions settings、workflow lint results、explicit permissions を持つ sample workflow。
GH-ACT-03	GitHub 側: Repository → Settings → Environments と workflow `permissions: id-token: write`。Cloud 側: AWS IAM / Azure Federated Credentials / GCP Workload Identity Federation / Vault trust configuration。	static cloud keys を OIDC または承認済み短命クレデンシャルに置き換えます。可能な範囲で organization、repository、branch/tag/environment、workflow により trust を制限します。environment ごとに role を分けます。	Workflow file、GitHub environment configuration、cloud trust policy、role permissions、federated identity を示す deployment logs。
GH-RUN-01	Enterprise または Organization → Settings → Actions → Runners / Runner groups。repo-scoped runners は Repository → Settings → Actions → Runners。	trust zone ごとに runner groups を作成します。各 runner group を利用できる repositories を制限します。untrusted fork PRs を privileged self-hosted runners で実行させません。sensitive workloads では ephemeral runners を優先します。	Runner group policy export、repository allowlist、runner labels、network segmentation evidence、runner lifecycle logs。
GH-SEC-01	Organization security settings / Security configurations、または Repository → Settings → Code security and analysis / Security and analysis。	secret scanning、push protection、利用可能な validity checks、internal tokens 用 custom patterns を有効化します。対応している場合は security configurations を repositories に適用します。	Security configuration export、secret scanning status、push protection status、custom pattern list、alert routing evidence。
GH-PAT-01	Organization → Settings → Personal access tokens → Settings。Enterprise policies が適用できる場合もあります。	classic PAT access を制限またはブロックします。対応している場合は fine-grained PATs に approval を必須にします。maximum lifetime と least privilege を強制します。active tokens を定期レビューします。	PAT policy screenshot/export、approved token list、denied/non-compliant token events、exception register。
GH-APP-01	Organization → Settings → Third-party Access / OAuth application policy; Organization → Settings → GitHub Apps / Installed GitHub Apps; 該当する場合 Enterprise → Policies。	OAuth App access restrictions を有効化します。apps が organization resources へアクセスする前に approval を必須にします。GitHub Apps は selected repositories のみに、最小 permissions で install することを優先します。broad app scopes は四半期レビューします。	OAuth restriction setting、pending/approved app list、GitHub App installation permissions、vendor/security approval record。
GH-SCA-01	Repository → Security / Security and quality; Repository → Settings → Code security and analysis。利用可能な場合は Organization security configurations。Required checks は Rulesets/Branch protection で設定。	CodeQL/code scanning または approved SAST を有効化します。Dependabot alerts、dependency graph、Dependabot security updates、dependency review を有効化します。Critical と High repositories では merge 前に security checks を必須にします。	Code scanning configuration、Dependabot settings、PR required checks、vulnerability SLA report、false-positive/suppression record。
GH-SUPPLY-01	Repository → Settings → Actions、Environments、Packages、Releases、Tags、workflow files。利用可能な場合は tag/release branch protection 用 Rulesets。	protected release branches/tags、restricted release publishers、process が対応する場合の signed tags、artifact attestations/provenance、package publishing controls を必須にします。critical artifacts は deployment 前に provenance を検証します。	Release/tag protection evidence、workflow attestation output、package publisher list、deployment verification logs。
GH-MON-01	Enterprise → Settings → Audit log / Audit log streaming。Org-level review は Organization → Audit log。SIEM/log lake configuration は GitHub 外。	GitHub audit logs を SIEM/log lake へ stream または export します。enterprise audit log、organization audit log、利用可能な Git events、Actions、security alerts、app/token events、runner events、ruleset changes を含めます。	Audit log streaming configuration、SIEM ingestion dashboard、parser health、sample event、retention configuration。
GH-IR-01	GitHub Security、Audit log、Actions run logs、repository activity、Releases、Packages、Branches/Rulesets、IdP logs。Incident case system は GitHub 外。	GitHub incidents では、remediation により文脈が失われる前に raw audit logs、workflow logs、runner logs、release metadata、package metadata、commit/PR history、token/app activity、identity evidence を保存します。	Incident evidence package、immutable log export、chain-of-custody record、timeline、containment approvals、post-incident review。
GH-EXC-01	単一の native GitHub toggle はありません。exception register を維持し、承認済み exceptions を ruleset bypass lists、Actions allowlists、app approvals、token approvals、repository metadata に反映します。	risk rating、business justification、compensating controls、owner、expiry date、remediation plan を必須にします。expired exceptions に alert します。	Exception register、approval record、expiry tracking、compensating control evidence、monthly review。

29.3 GitHub UI Enforcement Notes by Domain

Identity and access

可能な限り GitHub で強制しますが、identity provider を source of truth として扱います。SSO、SCIM、team synchronization、Enterprise Managed Users は、enterprise または organization identity settings と corporate IdP で管理します。GitHub teams は、管理外の第二のアイデンティティシステムにならないよう、承認済み IdP groups を反映させるべきです。

実装チェックリスト:

SSO または Enterprise Managed Users を強制する。
MFA を必須にする。
IdP groups を GitHub teams へ map する。
People/Owners view から organization owners をレビューする。
repository collaborator settings から direct repository grants を削除する。
API または governance tooling で team and repository access を export する。

Organization governance

デフォルトのガードレールには organization settings を使います。これらは repository owner がリスクを作る前に危険な操作を防ぐ統制です。

実装チェックリスト:

base permissions を No permission にする。
repository creation を制限する。
利用可能な場合、repository deletion、transfer、visibility changes を制限する。
outside collaborator invitations を制限する。
public repositories には approval を必須にする。
governance setting changes の audit events を監視する。

Repository rules and change control

まず organization rulesets を使い、特殊ケースには repository rulesets または branch protection を使います。Organization rulesets は drift を減らし、各 repository が独自の security model を作ることを防ぎます。

実装チェックリスト:

production branch patterns 向けに rulesets を作成する。
PRs、approvals、CODEOWNERS review、required checks、signed commits、conversation resolution を必須にする。
force pushes と branch deletion をブロックする。
bypass actors を最小化する。
テスト後は rulesets を enforced mode にする。
audit 用に ruleset configuration を export する。

GitHub Actions and CI/CD

広範な制限には enterprise または organization Actions policy を使います。repository-specific controls には repository Actions settings と workflow linting を使います。OIDC enforcement には cloud IAM を使います。GitHub は identity token を発行しますが、それが何にアクセスできるかを決めるのは cloud provider だからです。

実装チェックリスト:

allowed Actions と reusable workflows を制限する。
default GITHUB_TOKEN を read-only に設定する。
明示的な workflow permissions: を必須にする。
third-party Actions には SHA pinning を必須にする。
.github/workflows/** を CODEOWNERS と rulesets で保護する。
production deployment approvals には GitHub Environments を使う。
static cloud keys ではなく、cloud-side trust restrictions を持つ OIDC を使う。

Security scanning

一貫した scanning defaults を適用するには、利用可能な場合 organization security configurations を使います。repository-specific enablement や検証には repository Code security settings を使います。

実装チェックリスト:

secret scanning を有効化する。
push protection を有効化する。
internal credentials 用 custom secret patterns を有効化する。
CodeQL/code scanning または approved SAST を有効化する。
Dependabot alerts と security updates を有効化する。
Critical と High repositories では rulesets または branch protection により security checks を必須にする。
alerts を security と repository owners へ route する。

Apps, tokens, and integrations

Programmatic access は中央で統制するべきです。OAuth Apps、GitHub Apps、fine-grained PATs、classic PATs は、通常の review と SSO-driven access を迂回する経路になり得ます。

実装チェックリスト:

OAuth App access restrictions を有効化する。
GitHub App installations と scopes をレビューする。
automation には OAuth Apps より GitHub Apps を優先する。
classic PATs を制限またはブロックする。
fine-grained PATs には approval、expiry、least privilege を必須にする。
app and token inventory を維持する。
broad app approval または token policy weakening に alert する。

Runners

Runner isolation は GitHub と infrastructure の両方で強制する必要があります。GitHub runner groups は repository eligibility を制御しますが、network segmentation、ephemeral lifecycle、egress control、host hardening は runner environment 側で強制する必要があります。

実装チェックリスト:

trust zone ごとに runner groups を作成する。
runner groups を approved repositories に制限する。
privileged runners へ誤って job が流れない distinct labels を使う。
sensitive workflows には ephemeral runners を使う。
privileged runners を untrusted fork PRs から遮断する。
runner OS、job、network telemetry を central logging へ転送する。

Audit logging and incident response

GitHub audit logging はインシデント前に設定しておく必要があります。audit log UI だけでは、retention と query capability が限られる場合があるため、成熟した調査には不十分です。

実装チェックリスト:

利用可能な場合、enterprise audit logs を SIEM へ stream する。
streaming が使えない場合は organization audit logs を export する。
利用可能な場合は source IP visibility を有効化する。
owner changes、SSO/MFA weakening、ruleset changes、runner changes、app approvals、token activity、workflow changes、public exposure に対する detections を構築する。
incidents 中は logs、workflow run data、runner evidence、release metadata、package metadata、identity evidence を保存する。

29.4 When GitHub Has No Native Enforcement Setting

このガイドの一部統制は、GitHub UI setting だけでは完全には強制できません。その場合、次の fallback model を使います。

Control Type	Enforcement Method
Ownership metadata	Repository onboarding workflow、required repository topics/properties、CMDB integration、または policy-as-code inventory
Repository classification	Intake questionnaire、repository inventory、security review、automated policy evaluation
Workflow SHA pinning	CI workflow linter、pre-merge check、policy-as-code scanner、required status check
Cloud OIDC scope	Cloud IAM trust policy、federated credential conditions、Vault role configuration
Artifact provenance verification	Deployment controller、Kubernetes admission policy、release pipeline gate、package registry control
Exception governance	GRC register、ticketing workflow、exception dashboard、monthly review
Incident evidence package	Incident case management system、immutable storage、SIEM export、chain-of-custody process
Drift remediation	GitHub API/Terraform/GraphQL inventory compared against the control catalog

non-native controls の最小文書化項目:

Control ID:
Native GitHub setting available: Yes / No
Compensating enforcement:
Owner:
Evidence:
Review cadence:
Exception expiry:

この区別は重要です。統制は、この標準に書かれているだけでは “implemented” とは言えません。強制設定、自動化、またはレビュー手順が存在し、証跡を生成して初めて実装済みと言えます。

30. Enterprise Control Catalog Appendix

この appendix は、policy-as-code、audit evidence、quarterly review の出発点として使います。

Control ID	Domain	Requirement	Minimum Evidence	Review Cadence
GH-GOV-01	Governance	GitHub には enterprise/org settings、repositories、Actions、secrets、apps、runners、alerts、audit logs の accountable owners が必要	RACI、owner list、operating model	Quarterly
GH-ID-01	Identity	organization access には SSO を強制する	SSO setting、IdP mapping	Quarterly
GH-ID-02	Identity	all members、owners、billing managers、outside collaborators、対応可能な automation accounts には MFA を必須にする	MFA compliance report	Monthly
GH-ID-03	Identity	Organization owners は最小化しレビューする	Owner list、review ticket	Monthly
GH-ACCESS-01	Access	repository access は承認済み例外を除き direct grants ではなく teams 経由で付与する	Team mapping、direct grant report	Quarterly
GH-ORG-01	Organization	base permission は承認がない限り `No permission` とする	Org settings export	Quarterly
GH-ORG-02	Organization	repository creation、deletion、transfer、visibility changes は制限する	Org settings export	Quarterly
GH-REPO-01	Repository	すべての repository に owner、classification、production-impact metadata を持たせる	Repository inventory	Quarterly
GH-REPO-02	Repository	Critical と High repositories では sensitive paths に CODEOWNERS を使う	CODEOWNERS file and ruleset evidence	Quarterly
GH-RULE-01	Rulesets	default、release、hotfix、production branches には PR review、status checks、CODEOWNERS review、force-push protection を必須にする	Ruleset/branch protection export	Quarterly
GH-RULE-02	Rulesets	bypass actors は最小化し、承認し、監視する	Bypass actor list and SIEM alert	Monthly
GH-ACT-01	Actions	third-party Actions は承認し、full-length commit SHA に pin する	Workflow scan results	Monthly
GH-ACT-02	Actions	`GITHUB_TOKEN` は read-only を default とし、workflows は explicit permissions を宣言する	Org Actions setting and workflow lint	Monthly
GH-ACT-03	Actions	production cloud access には OIDC または承認済み短命クレデンシャルを使う	Trust policy and workflow evidence	Quarterly
GH-RUN-01	Runners	self-hosted runners は trust zone ごとに分離し、untrusted code から隔離する	Runner group policy、network evidence	Monthly
GH-SEC-01	Secrets	利用可能な場合、secret scanning と push protection を有効化する	Security settings export	Monthly
GH-PAT-01	Tokens	Classic PATs は block または正式例外扱いにする	Token policy and exception records	Monthly
GH-APP-01	Apps	OAuth Apps と GitHub Apps には approval と inventory tracking を必須にする	App inventory and approvals	Quarterly
GH-SCA-01	Code security	active production repositories では SAST/SCA と required security checks を実行する	Scan configuration and PR checks	Quarterly
GH-SUPPLY-01	Supply chain	Critical artifacts には実務上可能な範囲で provenance または signing を必須にする	Attestation/signature evidence	Quarterly
GH-MON-01	Monitoring	GitHub audit logs は SIEM へ export するか、承認済みプロセスでレビューする	SIEM ingestion、export job、parser health	Monthly
GH-IR-01	Incident response	GitHub incidents では audit logs、workflow logs、release metadata、identity evidence を保存する	Incident evidence package	Per incident
GH-EXC-01	Exceptions	exceptions は risk-rated、time-bound、approved、reviewed であること	Exception register	Monthly

31. Final thoughts

ユーザーログインと branch protection だけを守っても、GitHub を守っているとは言えません。

強い GitHub セキュリティプログラムは、identity、teams、repository governance、code review、signed commits、Actions、runners、secrets、tokens、OAuth apps、supply chain provenance、audit logging、incident response、continuous review を含みます。

最も重要な設計原則は次です。

GitHub は開発者の注意力だけに依存してはいけません。セキュリティ上重要な振る舞いは、platform guardrails によって強制されるべきです。

開発者は速く進むべきです。ただし、予測可能なミスを防ぎ、高影響の悪用経路をブロックする仕組みの中で速く進むべきです。