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

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

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

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

目的はシンプルです。

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

このガイドの使い方

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

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

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

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 機能を有効化するか、承認済みのサードパーティ統制を使うか、補完統制付きの期限付き例外を文書化してください。

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

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

それでは不十分です。

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

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

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

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

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

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

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

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

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

最小統制カタログ形式

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

次の形式を使います。

スターター統制:

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

推奨する認証方式:

1. Passkeys / hardware security keys
2. TOTP authenticator apps
3. 補助的な選択肢として 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 を使う

推奨ロールモデル:

「 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

推奨デフォルト:

6. Repository Security Baseline

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

6.1 Repository Classification

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

6.1.1 Repository Classification Decision Criteria

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

次の基準を使います。

判断ルール:

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

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

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 について、次を保持します。

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:

組織で使わない 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 の統制は、現実的な悪用パスと結び付けるべきです。

最小設計原則:

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-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 を分離します。

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 を使います。

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

11.2 Replace Static Secrets with Federation

優先順位:

1. OIDC federation
2. Vault や cloud secret manager などの secret broker with short-lived credentials
3. Environment-scoped GitHub secrets
4. Repository-scoped GitHub secrets
5. selected repositories に制限された Organization secrets
6. 長命 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

自動化の優先順位:

1. minimal permissions の GitHub App
2. OIDC federation
3. expiry 付き fine-grained PAT
4. Classic PAT は例外のみ

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

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

12.4 PAT Containment Procedure

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

1. token を直ちに revoke する。
2. token owner を特定する。
3. token がアクセス可能だった scopes と repositories を特定する。
4. token activity の audit logs をレビューする。
5. repository clone、push、release、workflow、package、secret access events を確認する。
6. token がアクセスできた downstream secrets を rotate する。
7. release integrity が不確かな場合は artifacts を rebuild する。
8. incident ticket を作成する。
9. 再発防止の detection または prevention rule を追加する。
10. 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 を維持します。

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 の例:

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 を監視します。

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 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 では次を行います。

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

21. Incident Response Playbooks for GitHub

21.1 Compromised User Account

即時対応:

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

21.2 Leaked Secret

即時対応:

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

21.3 Malicious Workflow Execution

即時対応:

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

21.4 Suspected Source Code Exfiltration

即時対応:

1. audit logs を保存する。
2. actor と accessed repositories を特定する。
3. clone/download scope を判断する。
4. compromised access を disable する。
5. 使用された tokens と apps をレビューする。
6. regulated または sensitive data が関係する可能性がある場合は Legal/Privacy を関与させる。
7. embedded secrets があれば rotate する。
8. public exposure risks をレビューする。
9. executive summary を作成する。
10. 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:

低リスクで可逆的かつ承認済みでない限り、自動化に破壊的変更を黙って実行させてはいけません。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

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

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

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

運用ルール:

すべての統制は、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

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 を使います。

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 の出発点として使います。

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 によって強制されるべきです。

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