GitHub を使う上で知っておくと嬉しいかも Tips
127 Views
August 12, 26
スライド概要
2026年エンジニア新人研修の資料です。
サイボウズ株式会社の主に開発本部の資料を公開するアカウントです。
関連スライド
各ページのテキスト
GitHub 知っておくと便利かも Tips 2026 セキュリティ向上 Tips 特集号 開運研修 2026 社外公開版 2026.05.08 社内公開 2026.07.21 更新 サイボウズ株式会社 開発本部 開発支援副本部 技術支援部 生産性向上副部 平木場 風太
自己紹介: 平木場 風太（ひらこば ふうた） 社内でのニックネームは「きばちゃん」 所属 開発本部 開発支援副本部 技術支援部 生産性向上副部 生産性向上副部 エンジニア兼マネージャー（副部長） 2020 年 4 月に新卒入社、生産性向上チーム配属 2024 年 10 月から生産性向上副部の副部長 出身: 鹿児島、宮崎 好きな 技術, サービス: CI/CD、GitHub、AWS 時代: 14~20世紀ヨーロッパ、幕末〜昭和日本 音楽: B’z, YUI, Mr.Children ゲーム: パラドゲー（EU5, Vic3, CK3） 仕事のアイコン SNS のアイコン GitHub: @korosuke613 Twitter: @shitimi_613 https://korosuke613.dev GitHub 知っておくと便利かも Tips 2026 2
はじめに 平木場が 6 年間業務をしてきた中で知ってきた GitHub に関する知っておくと嬉しいかもしれない Tips を紹介 本資料は 2026 年 4 月時点の情報に基づいている コンセプト 誰に：GitHub を使ったことがあるけど組織の中ではまだ使ったことがない人 なんと言ってほしいか：こんな使い方・機能・設定があったんだ！有効活用していきたいねぇ おねがい 今回紹介する Tips が全てのチーム・ケースにおいて常に有効に活用できるとは限らない チームの開発にマッチするかどうか、チームの開発方針に反しない範囲で適切に活用すること 他メンバーに影響を与える行動をする際は、先にチーム内での合意形成を行うこと。とりあえず周りの先輩社員に相談してみると良 い 何か間違ってる情報があれば教えてください GitHub 知っておくと便利かも Tips 2026 3
【2026.07 追加】この資料について 本資料は 2026-05-08 に社内発表した講義の資料（情報は 2026 年 4 月時点）を、2026-07-21 に更新したもの GitHub の進化は速い。この2ヶ月のアップデートで本スライドの前提が変わったケースも存在する。最新情報は GitHub Changelog や公式ドキュメントを確認してほしい 収録後の特に重要なアップデートを次のスライドで簡単に紹介する GitHub 知っておくと便利かも Tips 2026 4
【2026.07 追加】社内公開後の重要アップデート (1/2) 社内公開（2026-05-08）後の GitHub のアップデートから、本講義の主題（セキュリティ対策）に関わる重要なものを紹介 する。まずは Actions まわり。 github-actions[bot] が作った PR でもワークフローを実行可能に（2026-06-11） 従来、 GITHUB_TOKEN で作成した PR は再帰防止のため pull_request トリガーのワークフローが実行されず、CI 未検証のま まマージされうる課題があった。write 権限者の approval で実行される方式に fork PR の安全な checkout がデフォルトに（2026-06-18） actions/checkout v7 が pull_request_target での fork コードの危険な取得を既定で拒否（pwn request 対策）。全サポー トバージョンにもバックポート済み ワークフローを実行できる actor / イベントを制限可能に（2026-06-18、Public Preview） Actions の新しい Policies で、実行者（ユーザー・ロール・GitHub Apps 等）と起動イベントを許可リスト制御。renovate など の bot が作る PR ではワークフローを自動実行させない、といったサプライチェーン攻撃への守りに使える untrusted トリガーの Actions キャッシュが read-only に（2026-06-26） pull_request_target 等で起動したワークフローには読み取り専用キャッシュのみ発行し、キャッシュポイズニングを防止 GitHub 知っておくと便利かも Tips 2026 5
- https://github.blog/changelog/2026-06-11-bot-created-pull-requests-can-run-workflows-if-approved/
- https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout
- https://github.blog/changelog/2026-06-18-control-who-and-what-triggers-github-actions-workflows/
- https://github.blog/changelog/2026-06-26-read-only-actions-cache-for-untrusted-triggers
【2026.07 追加】社内公開後の重要アップデート (2/2) 続いて、サプライチェーン対策とその他のアップデート。 npm のサプライチェーン対策が本格化（2026-05〜07） 公開前承認を要する staged publishing が GA、npm v12 でライフサイクルスクリプト無効化等が既定に、2FA バイパストークン は段階的廃止へ CodeQL がプロンプトインジェクションを検出（2026-07-10） 信頼できない入力が AI モデルのシステムプロンプトへ流入する箇所を検出。AI 組み込みアプリという新しい攻撃面に対応 Dependabot の version update に 3 日間の cooldown（2026-07-14） 新バージョン公開直後の侵害・欠陥バージョンの自動流入を防ぐ猶予期間（security update は即時のまま） GitHub 知っておくと便利かも Tips 2026 6
- https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation
- https://github.blog/changelog/2026-07-10-codeql-2-26-0-adds-kotlin-2-4-0-support-and-ai-prompt-injection-detection
- https://github.blog/changelog/2026-07-14-dependabot-version-updates-introduce-default-package-cooldown
2025 年版との主な変更点 講義を分割: 「Git/GitHub Tips」→「Git Tips」と「GitHub Tips」の 2 講義に 本講義は GitHub Tips です。Git Tips は別講義をご覧ください 今年の主題はセキュリティ: 「セキュリティリスク」と「セキュリティ対策」を中心に据えた構成に その他細かい効率化などは「Tips集」として後半にまとめ GitHub 知っておくと便利かも Tips 2026 7
目次 1 1. GitHub のおさらい 1. 🎓 GitHub とは（ざっくり） 2. 🎓 GitHub の機能群（ざっくり） 3. 🎓 GitHub のサービス一覧 4. 🎓 GitHub の種類 5. 🎓 アカウントの種類とチーム 6. 🎓 可視性 (visibility) 7. 🎓 GitHub Advanced Security (GHAS) 2. GitHubを取り巻くセキュリティリスク 1. 🎓 GitHub 利用の拡大 2. 🎓 どんな攻撃があるのか 3. 📈 激化する GitHub 利用者への攻撃 4. 🚨 攻撃を許すと何が起こるか？ 3. GitHub 利用のセキュリティを強化する 1. 🎓 GitHub を安全・安心に使っていくため には？ 2. 🎓 事前知識: 最小権限の原則 3. 🎓 事前知識: 多層防御 4. 🎓 事前知識: 予防 / 検知 / 対応
目次 2 4. GitHub 利用セキュリティ強化 - 🛡️ 予防 5. 🛡️ 成果物の出所を証明する（Artifact 1. 🛡️ メンバーに必要以上の権限を与えない attestations） 2. 🛡️ GITHUB_TOKEN の権限を正しく把握・制御す 6. GitHub 利用セキュリティ強化 - 🛡️ 予防 る 1. 🛡️ fork からの PR でシークレットが漏洩するのを 3. 🛡️ 用途に応じた認証方法を選ぶ 防ぐ 4. 🛡️ 任意のファイルを関係者のみがマージできるよ 2. 🛡️ ワークフローへのスクリプトインジェクション うにする 5. GitHub 利用セキュリティ強化 🛡️ 予防 1. 🛡️ 改ざん対策 2. 🛡️ 依存 Action のタグ書き換えを防ぐ 3. 🛡️ 大事なブランチの改ざんを防ぐ 4. 🛡️ 成果物（タグ・リリース）の改ざんを防ぐ を防ぐ 3. 🛡️ シークレットを含みうるファイルのプッシュを 防止する 4. 🛡️ API キーをプッシュ前にブロックする 5. 🛡️ Actions のシークレットへのアクセスを絞る 6. 🛡️ Actions で他サービスへの認証に長命クレデン シャルを使わない
目次 3 7. GitHub 利用セキュリティ強化 - 🛡️ 予防 4. 🔍 組織全体のセキュリティ状況を俯瞰する 1. 🛡️ 脆弱性のある依存関係の追加を防ぐ 9. GitHub 利用セキュリティ強化 - 🚨 対応 8. GitHub 利用セキュリティ強化 - 🔍 検知 1. 🚨 サプライチェーン侵害発覚時に影響範囲 1. 🔍 依存ライブラリの脆弱性を検知する を特定する 2. 🔍 コード内のセキュリティ脆弱性を早期に 2. 🚨 侵害の痕跡を audit log で調査する 発見する 3. 🚨 インシデント発生時に認証情報を一括無 3. 🔍 コミット済みのシークレットを検知する 効化する
目次 4 10. Tips集 1. 💡 Actions のコストを安く抑えたい 2. 💡 組織の Actions 利用状況を把握したい 3. 💡 マージ済みの不要ブランチを片付けたい 4. 💡 外部タスク管理の番号を自動リンク化し 7. 💡 CLI や CI から GitHub を素早く操作した い 8. 💡 Markdown で注意書きを視覚的に目立た せたい 9. 💡 リポジトリが増えすぎて分類・管理が大 たい 変 5. 💡 複数人で作業したコミットの貢献者を明 10. 💡 GitHub の調子が怪しい！ 示したい 11. おわりに 6. 💡 GitHub 上のコードを不変な URL で共有 したい
GitHub のおさらい
🎓 GitHub とは（ざっくり） 曰く、Build and ship software on a single, collaborative platform 噛み砕いて言うと、ソフトウェア開発とリリース までを、複数人で一緒に進められるオールインワ ンなプラットフォーム 元々 Git 関係の機能しかなかったが、だんだん CI/CD やアーティファクトリポジトリ、リモート 開発環境などの機能が追加され、ソフトウェア開 発・運用における開発部分を GitHub 上で完結で きるようになってきた https://github.com より GitHub 知っておくと便利かも Tips 2026 13
🎓 GitHub の機能群（ざっくり） 📝 Issues ⚙ Actions 🗣 Discussions ✨ Releases 📊 Projects 📦 Packages e od lo R y C 📜 te Ops ra pe O Te s ⚙ Actions r ito on t M ld ⚙ Actions ⚙ Actions Pages ep D n Dev i Bu 📱 Mobile ◼ CLI 🖥 Desktop 📠 API Copilot Copilot a Pl 🌏 Web GitHub Interface 💻 Codespaces ea se 🙏 Pull requests el 🌴 Git server Sec 🤖 Dependabot Copilot 🆘 Code scanning 🔑 Secret scanning GitHub 知っておくと便利かも Tips 2026 14
🎓 GitHub のサービス一覧 たくさんある。ざっくり Git サーバー: リモートリポジトリとしての機能を提供 Issue: リポジトリに関連する問題や機能要望を管理 Pull Request: GitHub上でのコードレビューとマージを管理 Discussions: コミュニティQAやアイデアの共有を促進 Projects: Issue、タスクをプロジェクト的に管理 Wiki: ドキュメントなどを共有するための機能 Pages: 静的ウェブサイトホスティング GitHub Mobile: モバイル向けの GitHub Actions: CI/CD Releases: ソフトウェアのリリースを管理 Packages: さまざまな種類のパッケージを管理 Dependabot: 依存関係の自動更新、脆弱性アラートなど Code Scanning: コードの脆弱性スキャン Secret Scanning: 平文のクレデンシャルを検知 Codespaces: クラウド上の開発環境を提供 Copilot: AI を使った開発支援機能の総称 Models: LLM を手軽に評価できる機能 CLI: コマンドラインから GitHub を操作するためのツール GitHub 知っておくと便利かも Tips 2026 15
🎓 GitHub の種類 クラウド版（github.com） Free（個人向け無料） Pro（個人向け有料） Team（組織向け有料） Enterprise（大規模組織向け有料） GitHub Enterprise Cloud を略して俗に GHEC と呼ばれていたりする オンプレ版（任意ドメインのものは大体オンプレ版） オンプレ版は自社サーバーでの運用が可能 GitHub Enterprise Server を略して GHES と呼ばれていたりする GitHub Enterprise Cloud with data residency（*.ghe.com） データの所在を特定のリージョンに限定できる＆ガバナンスを強化したクラウド版。2025 年末より日本リージョンも追加 github.com ともその他の ghe.com テナントとも隔離された専用環境が提供される 言うなれば「クラウド版 GitHub Enterprise Server」 GitHub 知っておくと便利かも Tips 2026 16
🎓 アカウントの種類とチーム User[1] 個人を表すアカウント Repository を所有、管理できる Organization 組織を表すアカウント Repository、Team を所有、管理できる Team Organization 所属 User を束ねるグループ 効率の良いレビュワーや権限の指定を実現する Enterprise 複数の Organization を束ねる組織を表すアカウント Organization を所有、管理できる 1. Enterprise Managed Users という Enterprise 専用 User も存在するが割愛 ↩︎ Te a m 0..* 所有する 1 Organization 所属する 1..* 0..* 0..* 所属する 所属する 0..1 Enterprise 1 1..* 0..* User 1 所有する 所有する 0..* 0..* Repository クラス図で表すとこんな感じだと思う GitHub 知っておくと便利かも Tips 2026 17
🎓 可視性 (visibility) GitHubのリポジトリには3つの可視性がある。 Public 全世界に公開。誰でもアクセス可能 OSS くらいでしか使わない Private 権限のあるユーザーのみアクセス可能 他 Org メンバーにも公開できないようなリポジトリの場合に使う[1] Internal 権限のあるユーザー、および、同一 enterprise のユーザーはアクセス可能 特段理由がなければ Internal を選ぶのが無難だと考える 1. ている。もし特定チームのみに限定したい場合、 Organization の base permission はデフォルトで Read となっている。例えば、org A に private repo B を作った場合、org A のメンバーは全員その private repo B にアクセス可能となっ base permission を にして、アクセスさせたいチームにだけ Read 以上の権限を付与するなどの工夫が必要（organization admin は常にアクセス可能） ↩︎ No permission GitHub 知っておくと便利かも Tips 2026 18
🎓 GitHub Advanced Security (GHAS) GitHub にはセキュリティを高める機能が存在する。これらのうち有料ライセンスが必要な機能は、 public repo では無料、 [1] private repo では有料という形式になっている 。 有料ライセンスには GitHub Secret Protection と GitHub Code Security があり、まとめて GitHub Advanced Security (GHAS) と総称される。 ライセンス 価格 追加ライセンス不要 無料 GitHub Secret Protection $19/月・アクティブコミッター GitHub Code Security $30/月・アクティブコミッター 1. 最新情報は https://github.com/security/plans を参照 ↩︎ 主な機能 Dependabot alerts / security updates / version updates、 Dependency graph、GitHub Advisory Database Secret scanning、Push protection、 Copilot secret scanning、Custom patterns Code scanning、Copilot Autofix、Dependency review、 Custom auto-triage rules for Dependabot GitHub 知っておくと便利かも Tips 2026 19
GitHubを取り巻くセキュリティリスク
🎓 GitHub 利用の拡大 GitHub はもはやリポジトリ管理の枠を超え、開発プロセスのあらゆる段階をカバーするプラットフォームになっている。 あ なたの組織は GitHub にどれくらい依存しているだろうか？ 例えば、 コードは GitHub で管理し CI/CD を GitHub Actions で回し 成果物を GitHub Packages で配布する さらに 下流のリポジトリがその Packages の成果物に依存し Actions でビルドした成果物を本番環境にデプロイしている というふうに、GitHub を軸にした開発フローが構築されているケースももはや珍しくないだろう。 GitHub への依存が増えると、そのぶん攻撃者に狙われる面も広がる。 では実際、どんな入り口から、どんな攻撃が仕掛けら れているのだろうか？ GitHub 知っておくと便利かも Tips 2026 21
🎓 どんな攻撃があるのか 今後の説明のためにどういう攻撃があるのか分類してみます。 攻撃には「🚪 入口」と「⚔️ 行為」の 2 面があり、行為が次 の入り口を生む連鎖を起こす。 🚪 入口 (被害を与えるための下準備) 👥 権限の乗っ取り メンテナ乗っ取り / PAT 窃取 / 可視性変更・リポジトリ削除 📦 危険な依存 悪意のある依存 / 脆弱性のある依存 / タイポスクワッティング ⚔️ 行為 (実際に被害を与える) 🎭 コード・成果物の改ざん 悪意のある変更 / ビルドシステム侵害 / タグ書換 🔓 認証情報の流出 リポジトリへの誤コミット / PAT 窃取 / CI 環境変数流出 行為は次の入口を生み、連鎖する 🎭 改ざんされたパッケージ → 下流ビルドの 📦 危険な依存の入口に 🔓 流出した認証情報 → 他リポへの 👥 権限の乗っ取りの入口に 例: tj-actions 2025 = 👥 権限の乗っ取り (tj-actions-bot PAT) → 🎭 タグ書換 → 🔓 利用側 23,000 リポの secrets 流出 → (その secrets が次の 👥 乗っ取りの入口に) GitHub 知っておくと便利かも Tips 2026 22
📈 激化する GitHub 利用者への攻撃 サプライチェーン攻撃は月16件以上のペースで発生し、巧妙化・大規模化が止まらない[1]。 年 事例 2021 2024 2025 2025 2026 Codecov Bash Uploader[2] xz Utils[3] reviewdog + tj-actions/changedfiles[4] Shai-Hulud npm ワーム[5] Trivy Action + setup-trivy[6] 手口と連鎖 🎭 → 🔓 Docker から漏れた GCS キーで Uploader 改ざん、GitHub Actions 含む CI の env var が 2 ヶ月流出、23,000 顧客 に影響 👥 → 🎭 2 年かけて GitHub 上で信頼構築しコミット権獲得、OpenSSH RCE バックドア注入（CVSS 10.0） 👥 → 🎭 → 🔓 Actions 2 段連鎖侵害、全タグ書換で 23,000+ リポから secrets 流出 🎭 → 👥 preinstall が GitHub workflow を自動生成、25,000+ 悪意リポが自己増殖 👥 → 🎭 → 🔓 GHA トークン窃取でタグ書換、セキュリティツール本体が標的に GitHub Actions のタグ書換が定番手口に（tj-actions 2025 → Trivy 2026） 定番パターン: 👥 権限の乗っ取り → 🎭 改ざん -> 🔓 secrets 流出 -> 👥 さらなる権限乗っ取り -> … のループ 最初の入口は多様: 依存関係起因 / 管理者の不手際による secret 流出 / 信頼関係を作った後の裏切り / etc… 1. 2024-10〜2025-05 の月平均。Sonatype 2024 State of the Software Supply Chain Report および後継調査より ↩︎ 2. Codecov 公式発表 ↩︎ 3. NVD: CVE-2024-3094 (xz Utils) ↩︎ 4. CISA: Supply Chain Compromise of Third-Party tj-actions/changed-files (CVE-2025-30066) ↩︎ 5. Unit 42 (Palo Alto Networks) 調査 ↩︎ 6. Aqua Security 公式発表 ↩︎ GitHub 知っておくと便利かも Tips 2026 23
- https://www.sonatype.com/state-of-the-software-supply-chain
- https://about.codecov.io/security-update/
- https://nvd.nist.gov/vuln/detail/CVE-2024-3094
- https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-github-action-cve-2025-30066
- https://unit42.paloaltonetworks.com/npm-supply-chain-attack/
- https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/
🚨 攻撃を許すと何が起こるか？ 被害は自分の環境・自分の責任として返ってくる。 CI の秘密が根こそぎ抜かれる: AWS キー・DB 認証・API トークンなどを全件ローテーション クラウド破産: 盗まれたキーで仮想通貨マイニング、気づいたら数百万円の請求 自分が公開したものが、下流を感染させる: 下流（社内の別組織や顧客）を巻き込み、多大なる被害を与える 本番環境へ悪意あるコードがデプロイされる: 顧客データ漏洩、サービス停止 組織・製品の信頼が揺らぐ: セキュリティが疎かな組織は信用できないと判断され、顧客離れにつながる ひとたび侵害が起きれば、技術の問題に留まらず、事業継続性まで揺らぐ。 だからこそ、次章で予防 / 検知 / 対応の 3 段で対策を見ていく。 GitHub 知っておくと便利かも Tips 2026 24
GitHub 利用のセキュリティを強化する
🎓 GitHub を安全・安心に使っていくためには？ ソフトウェアエンジニアリングにおける一般的なセキュリティの考え方を重視することに加え、GitHub ならではのセキュリ ティ機能や仕様・プラクティスを理解し、適切に活用していくことで、セキュリティリスクを減らしつつ GitHub を活用して いくことができる。 本章では特に GitHub ならではのセキュリティ機能やプラクティス を紹介していく 基本的には GitHub の正規の機能を紹介し、原則として 3rd パーティ製のツールや一般的なセキュリティ知識や考え方は取り扱わない ただし、本章を通底する 最小権限の原則 と 多層防御、そして本章の構成軸となる 予防 / 検知 / 対応 の 3 つだけは事前知識と して押さえておきたい。 GitHub 知っておくと便利かも Tips 2026 26
🎓 事前知識: 最小権限の原則 必要な操作に必要な範囲だけの権限を与える。 トークンが漏洩すると、攻撃者はそのトークンの権限の範囲であなたになりすませる PAT (Classic) のスコープが repo なら → すべてのプライベートリポジトリが読み書き可能に Fine-grained PAT で対象リポジトリ1つ・ contents: read のみなら → 被害はそのリポジトリの読み取りだけ 権限を絞ることで、漏洩時の影響範囲を小さくできる。有効期限を短くすることで、悪用可能な時間を短くできる。 この原則は認証方法の選択だけでなく、 GITHUB_TOKEN の permissions 設定、ロール付与、Rulesets など、本章の全 Tip に通じる考え方。 GitHub 知っておくと便利かも Tips 2026 27
🎓 事前知識: 多層防御 単一のセキュリティ対策に頼らず、複数の対策を重ねて守る設計思想。 どんなに優れた対策でも 100% は防げない前提で設計する 同じ脅威に対して、異なる角度・段階で複数の対策を持つ 「社内だから安全」「信頼できる人しかいない」は技術的な防御にならない 例: 配布元の凍結（Immutable Releases） + 受信側の検証（Artifact attestations） の組み合わせで、配布と受信の両面 から改ざんを防ぐ（後の Tip で登場） GitHub 知っておくと便利かも Tips 2026 28
🎓 事前知識: 予防 / 検知 / 対応 攻撃をめぐる時間軸を 予防（前）/ 検知（中）/ 対応（後） の 3 段に分けて、それぞれに対策を持つ考え方。 🛡️ 予防 (Prevent) 攻撃が成立する前に塞ぐ 権限を絞る 危険な操作をブロック 信頼できる依存だけ通す 🔍 検知 (Detect) すり抜けたら → 起きた異常を早く見つける 既知の脆弱性のスキャン 漏れたシークレットの発見 怪しいコードパターン抽出 🚨 対応 (Respond) 検知したら → 起きた後の被害を最小化 影響範囲の特定 認証情報の即時無効化 監査ログでの追跡 攻撃の前 / 中 / 後で対策を分ける考え方は、NIST Cybersecurity Framework[1] の Protect / Detect / Respond にも対応する業界標 準的な分類 1. NIST Cybersecurity Framework。CSF 2.0 では Govern / Identify / Protect / Detect / Respond / Recover の 6 機能で構成され、本章はそのうち中核 3 つ（Protect / Detect / Respond）に対応する範囲を扱う ↩︎ GitHub 知っておくと便利かも Tips 2026 29
GitHub 利用セキュリティ強化 - 🛡️予防 （最小権限）
🛡️ メンバーに必要以上の権限を与えない GitHub 上でできる権限をまとめたロール（役割）が定義されている。ロールは User や Team に対して付与できる Repository roles [1] Read : リポジトリを読む人向け Triage : Issue や PR の優先順位やカテゴリ分けを決める人向け Write : リポジトリのコードを変更する人向け Maintain : リポジトリのメンテナ向け（ Write と Admin の中間） Admin : リポジトリの管理者向け Organization roles [2] All-repository * : Repository roles を全てのリポジトリに対して適用するロール Apps manager : Organization 上の GitHub Apps に関する管理を行う人向け CI/CD Admin : Organization 上の GitHub Actions に関する管理やメトリクスの取得を行う人向け Security Manager : Organization やリポジトリに対するセキュリティ機能のレビュー、管理を行う人向け 1. 詳しくは https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-user-access-to-your-organizations-repositories/managing-repositoryroles/repository-roles-for-an-organization ↩︎ 2. 詳しくは https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization ↩︎ GitHub 知っておくと便利かも Tips 2026 31
- https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization
- https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization
ロールをカスタムする Roles を付与することで、特定の役割の人に必要な権限のみを付与できるが、定義済みのロールだと権限が大きすぎることがある。そ ういう時は Custom roles という機能を使えば任意の権限を付与したロールが作れる 例 シナリオ：GitHub Actions のジョブ・ワークフローの無駄を見つけ改善案を提案する仕事をすることになった A さん。Actions に は利用状況をダッシュボード的に確認する機能があるが、リポジトリ横断で確認するには Organization Owner であるかもしくは CI/CD Admin ロールが必要。でも Owner の持つ権限も CI/CD Admin ロールの持つ権限も強すぎて懸念が多い… 解決例：A さんをメンバーに招待した上で GitHub Actions の Usage metrics、Performance metrics の閲覧権限（ View organization Actions usage metrics ）を持つカスタムロールを作成し、A さんに付与する GitHub 知っておくと便利かも Tips 2026 32
🛡️ GITHUB_TOKEN の権限を正しく把握・制御する GitHub Actions のワークフロー実行時に自動で発行される短命トークン ジョブの終了とともに失効するため、漏洩リスクが最も低い 権限（何ができるか）: permissions: ブロックの指定による。未指定の場合は enterprise / org / repo の設定からデフォルト権限 が適用される（ read-only / write-all を選択可能）[1] 範囲（どこに対してか）: 実行中のリポジトリのみ。別リポジトリへのアクセスは不可 comment: permissions: pull-requests: write steps: - name: Example step using GITHUB_TOKEN env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | gh pr comment 123 --body "This is a comment from GITHUB_TOKEN" 1. め、手元の 2023-02-02 以降に作成された Organization では新規リポジトリのデフォルトが になっている。古い Organization は Org の設定を必ず確認すること。参照: Updating the default GitHub_TOKEN permissions to read-only ↩︎ read-only write-all のまま放置されている可能性があるた GitHub 知っておくと便利かも Tips 2026 33
GITHUB_TOKEN - permissions で権限設定 に付与する権限は permissions: ブロックでスコープごとに read / write / 指定なし（ none ）を設定する 指定していないスコープの権限は none になる デフォルト権限（ write-all / read-only ）も消える permissions: を指定しない場合のデフォルト権限は write-all （全て読み書き可能）になっている write-all : 全てのスコープ（例外あり）が write で付与される。非常に強い権限を持ってしまう read-only : contents 、 packages のみが read で付与される。限定的な権限であり安全性が高い enterprise / org / repo の設定からデフォルト権限を read-only に変更可能 セキュリティの観点から read-only を強く推奨 ワークフローとジョブ両方で permissions: が指定された場合、ジョブの permissions: が優先される（マージではなく、上書 きされる） GITHUB_TOKEN GitHub 知っておくと便利かも Tips 2026 34
GITHUB_TOKEN permission actions artifact-metadata attestations checks contents deployments discussions id-token issues models packages pages pull-requests security-events statuses - permissions 一覧（抜粋） 説明 ワークフローの管理（実行のキャンセル、ログの取得等） Artifact メタデータストレージの操作 Artifact attestations の生成 チェックランの作成・更新 リポジトリの内容（コード、コミット、リリース）の読み書き デプロイメントの作成・管理 Discussions の読み書き OIDC トークンの取得（ write のみ） Issue やコメントの読み書き GitHub Models による AI 推論の実行（ read のみ） GitHub Packages の読み取り・公開 GitHub Pages のビルドリクエスト PR やコメント、ラベルの読み書き Code scanning アラートの読み書き コミットステータスの読み書き GitHub 知っておくと便利かも Tips 2026 35
GITHUB_TOKEN - 実際に付与されている権限の確認方法 ジョブ実行時のログで確認できる（ Set up job ステップ） GitHub 知っておくと便利かも Tips 2026 36
GITHUB_TOKEN - Q1: どのような権限が付与される？ デフォルト権限: read-only ワークフロー、ジョブ共に permissions: 未指定 正解は… GitHub 知っておくと便利かも Tips 2026 37
GITHUB_TOKEN - Q1: どのような権限が付与される？ デフォルト権限: read-only ワークフロー、ジョブ共に permissions: 未指定 正解は… Contents, Metadata, Packages が read になる Issues や Pull Requests などの他の権限は none になるため、リポジトリ のコードを変更したり、認証が必要な Issue や PR の読み取りなどはできない ▼ GITHUB_TOKEN Permissions Contents: read Metadata: read Packages: read GitHub 知っておくと便利かも Tips 2026 38
GITHUB_TOKEN - Q2: どのような権限が付与される？ デフォルト権限: read-only ワークフローで permissions: contents: write 、 issues: read 、 pull-requests: write を指定、ジョブでは permissions: 未指定 正解は… GitHub 知っておくと便利かも Tips 2026 39
GITHUB_TOKEN - Q2: どのような権限が付与される？ デフォルト権限: read-only ワークフローで permissions: contents: write 、 issues: read 、 pull-requests: write を指定、ジョブでは permissions: 未指定 正解は… 与えた権限 + Metadata が付与される read-only * permissions: 未指定で付与されていた Packages: read は Packages: none となり、特に権限が与えられてない状態になる ▼ GITHUB_TOKEN Permissions Contents: write Issues: read Metadata: read PullRequests: write GitHub 知っておくと便利かも Tips 2026 40
GITHUB_TOKEN - Q3: どのような権限が付与される？ デフォルト権限: write-all ワークフローで permissions: に contents: read を指定、ジョブでは permissions: に pull-requests: write を指 定 正解は… GitHub 知っておくと便利かも Tips 2026 41
GITHUB_TOKEN - Q3: どのような権限が付与される？ デフォルト権限: write-all ワークフローで permissions: に contents: read を指定、ジョブでは permissions: に pull-requests: write を指 定 正解は… ジョブで指定した pull-requests: write のみが付与される ジョブの permissions: はワークフローの permissions: を上書きす るため、ワークフローで指定した contents: read は無視される ジョブが優先されること、ワークフローの permissions: とマージはさ れないことに注意 ▼ GITHUB_TOKEN Permissions Metadata: read PullRequests: write GitHub 知っておくと便利かも Tips 2026 42
GITHUB_TOKEN - Q4: どのような権限が付与される？ デフォルト権限: write-all ワークフロー、ジョブ共に permissions: 未指定 正解は… GitHub 知っておくと便利かも Tips 2026 43
GITHUB_TOKEN - Q4: どのような権限が付与される？ デフォルト権限: write-all ワークフロー、ジョブ共に permissions: 未指定 正解は… 全ての権限が write になる！！！ 何かあったら危ない！！！ ▼ GITHUB_TOKEN Permissions Actions: write ArtifactMetadata: write Attestations: write Checks: write Contents: write Deployments: write Discussions: write Issues: write Metadata: read Models: read Packages: write Pages: write PullRequests: write RepositoryProjects: write SecurityEvents: write Statuses: write GitHub 知っておくと便利かも Tips 2026 44
GITHUB_TOKEN - Q5: どのような権限が付与される？ デフォルト権限: write-all ワークフロー、ジョブ共に permissions: {} を指定 正解は… GitHub 知っておくと便利かも Tips 2026 45
GITHUB_TOKEN - Q5: どのような権限が付与される？ デフォルト権限: write-all ワークフロー、ジョブ共に permissions: {} を指定 正解は… Metadata のみが read になる 他の全ての権限は none になるため、リポジトリのコードを変更したり、認 証が必要な Issue や PR の読み取りなどはできない 極めて安全な状態（もちろんできることは限られる） デフォルト権限が write-all であっても、ワークフローで permissions: {} を指定すれば、全ての権限を none にできて安全性が 増す ▼ GITHUB_TOKEN Permissions Metadata: read GitHub 知っておくと便利かも Tips 2026 46
GITHUB_TOKEN - 覚えていってほしいこと とにかくジョブに permissions を設定する癖をつける。 の権限は、「 permissions: （ジョブ） > permissions: （ワークフロー） > デフォルト権限」の順で決まる permissions: の指定が一番最小権限の原則を実現できる。可能な限り permissions: を指定する enterprise、org、repo の設定でデフォルト権限を read-only にすることができる。セキュリティの観点から read-only への 設定変更を強く推奨 一番まずいのはデフォルト権限が write-all の状態で、ワークフローやジョブで permissions: を指定せずに放置すること。何 かあったときの影響が大きすぎる とりあえず自分の管理下にあるワークフローの GITHUB_TOKEN の権限を確認してみよう。ジョブ実行ログの Set up job ステッ プで確認できる GITHUB_TOKEN GitHub 知っておくと便利かも Tips 2026 47
🛡️ 用途に応じた認証方法を選ぶ GitHub API やリポジトリへのアクセスには複数の認証方法がある。用途に応じて適切な方法を選ぶことが重要。 : Actions 内で自動発行される短命トークン。実行中のリポジトリのみ対象 GitHub App: Org/リポジトリにインストール。Bot として動作し、人の退職・異動に影響されない PAT (Fine-grained): リポジトリ単位・権限単位で細かく設定可能 PAT (Classic): スコープ単位の粗い権限。一部古いツールで必要だが、可能な限り Fine-grained への移行推奨 デプロイキー: リポジトリ単位の SSH キー。Git プロトコル操作のみ可能（今回は説明を割愛） OAuth App: ユーザーの代わりに API を呼ぶ仕組み。現在は GitHub App でほとんど代替可能（今回は説明を割愛） GITHUB_TOKEN GitHub 知っておくと便利かも Tips 2026 48
Personal Access Token (PAT) ユーザー個人に紐づくトークン。2種類ある。ローカルマシンでの API 操作、ghcr.io のイメージ操作[1]など Fine-grained PAT（推奨） 権限: 権限単位で細かく設定可能（ contents: read 等） 範囲: リポジトリ単位で指定可能 有効期限は最大1年（組織のポリシーで最大無期限に変更可能） 組織の設定で承認制にできる（デフォルトは承認なしで作成可能） Classic PAT 権限: repo , admin:org 等の粗いスコープ単位 範囲: リポジトリ単位で絞れず、 repo スコープだけでもユーザーがアクセスできる全リポジトリが対象[2] 可能な限り Fine-grained へ移行したほうが良い 1. の認証周りはとても複雑なので、各々壁に当たったら調べてみてください 2026年1月時点でも GitHub App のインストレーショントークンは GHCR へのアクセスに使えないため、GHCR にアクセスする必要がある場合は PAT を使う必要がある。GitHub Packages ↩︎ 2. SSO が有効な Organization の場合、トークン作成後に から SSO 認可のステップが必要 ↩︎ Configure SSO GitHub 知っておくと便利かも Tips 2026 49
GitHub App PAT との最大の違いは「短命なトークンを払い出せる」こと。「人ではなく組織に紐づく」こと。 API 実行のためのトークンが短命: Installation Token は 1 時間で失効。漏洩しても影響時間が限定される（Fine-grained PAT は最大 1 年） 必要なリポジトリだけにトークンを絞れる: リクエストごとに対象リポジトリを動的に指定できる。最小権限の原則に沿いやすい (PAT は発行時に固定) Org / Enterprise が公式に把握できる: 管理画面でどの App がどこにインストールされているかを一覧できる。個人作成の PAT のよ うに「誰が何を持っているか分からない」状態にならない 退職・異動の影響を受けない: App は Org / Enterprise が所有。作成者が抜けてもトークンは生き続ける[1] API レートリミットが App 専用で分離される: Bot ワークロードがユーザーの 5,000 req/h を圧迫しない 2つの方式: Installation Token 方式（Bot として動かす一般的な方法）と Device Flow 方式（ローカル環境で採用しやすい方法）があ る GITHUB_TOKEN では実現できない複数リポジトリ操作や Actions 外から API を叩く場面で、PAT よりも先に検討すべき選 択肢。 1. GitHub App はユーザーに紐づけての作成もできますが、インストール先を全世界か作成ユーザーかしか選べないため、組織で使うことはないでしょう。 ↩︎ GitHub 知っておくと便利かも Tips 2026 50
GitHub App の仕組み（Installation Token 方式） GitHub App を Bot として使う典型的な方法 = Installation Token 方式。2 段階の認証で API を呼ぶ。 利用側 GitHub API ために使う ① App ID + 秘密鍵で JWT 生成 (最大10分有効) ② で を要求 JWT Installation Token POST /app/installations/:id/access_tokens 時間有効) ③ Installation Token で API 操作 Installation Token (1 利用側 JWT: App 所有者であることを証明する短命の自 己署名トークン。Installation Token を要求する Installation Token: 特定の Installation（インス トール先 Org / リポジトリ）の操作を行うための トークン。API 操作はこれで行う 秘密鍵の扱いに注意: 秘密鍵さえあれば誰でも Installation Token を発行できる。Actions secrets / Environment secrets / シークレットマ ネージャ等で厳重に保管する GitHub API GitHub 知っておくと便利かも Tips 2026 51
GitHub App 利用例（Installation Token 方式） Actions 上では actions/create-github-app-token で簡単にトークンを取得できる。 steps: - uses: actions/create-github-app-token@1b10c78c7865c340bc4f6099eb2f838309f1e8c3 # v3.1.1 id: app-token with: app-id: ${{ vars.APP_ID }} private-key: ${{ secrets.APP_PRIVATE_KEY }} repositories: my-org/other-repo # - name: Issue env: GH_TOKEN: ${{ steps.app-token.outputs.token }} run: | gh issue comment 42 -R my-org/other-repo --body "Automated comment" 別リポジトリの にコメント オプション。指定しないとインストールされている全リポジトリが対象 今回は Actions secrets に秘密鍵を置いている例となっているが、さらにアクセス可能なユーザーを減らすために Environment secrets に置くことを推奨[1] ※ 1. 合わせることでワークフローを編集できるユーザーを絞れる Actions secrets はリポジトリの Write 権限以上あれば誰でもワークフローを編集することでシークレットを取得できてしまうが、Environment secrets は Environment と Rulesets を組み ↩︎ GitHub 知っておくと便利かも Tips 2026 52
GitHub App の仕組み（Device Flow 方式） GitHub App を ユーザーの代理として使う方法 = Device Flow 方式。秘密鍵不要、ブラウザ認可ベース。 ユーザー (ブラウザ) 利用側 ① GitHub API を要求 device_code POST /login/device/code MJHT ） User Access Token: App がユーザーの代理とし て API を叩くためのトークン。API 操作はこれで device_code, user_code, verification_uri ② device_code / user_code: device_code は App 側が保持する識別子、user_code はユーザー がブラウザに入力する短い文字列（例: WDJB- と を表示 user_code verification_uri ③ ブラウザで App を認可 (user_code を入力) ④ device_code でトークン取得 POST /login/oauth/access_token 時間有効) ⑤ User Access Token で API 操作 行う ローカル認証に最適: 秘密鍵を配らず、ブラウザ認 可だけで使える。対話必須なので主用途はローカ ル CLI 認証 User Access Token (8 利用側 ユーザー) ブラウザ ( GitHub API GitHub 知っておくと便利かも Tips 2026 53
GitHub App 利用例（Device Flow 方式）
curl
で GitHub の Device Flow API を叩いて User Access Token を取得し、 gh CLI で利用する例[1]。
を要求
の
が必要
# 1. device_code
(App
Client ID
)
$ curl -X POST https://github.com/login/device/code \
-d "client_id=$CLIENT_ID" -H "Accept: application/json"
# → { "device_code": "...", "user_code": "WDJB-MJHT", "verification_uri": "https://github.com/login/device", ... }
ブラウザで verification_uri を開き、user_code を入力 → App を認可
# 3. User Access Token を取得
# 2.
$ curl -X POST https://github.com/login/oauth/access_token \
-d "client_id=$CLIENT_ID" -d "device_code=$DEVICE_CODE" \
-d "grant_type=urn:ietf:params:oauth:grant-type:device_code" \
-d "repository_id=$REPO_ID" \
-H "Accept: application/json"
# → { "access_token": "ghu_...", "expires_in": 28800 }
# repository_id
(
REPO_ID
は任意 指定でアクセス対象を単一リポに絞れる。
は `gh api repos/{owner}/{repo} --jq .id` で取得)
# 4. 取得したトークンで API 操作（実際にやるときはコマンド置換`$()`などを使って環境変数に渡そう）
$ export GH_TOKEN=ghu_xxxxxxxxxxxxxxxxxxx
$ gh issue comment 42 -R my-org/other-repo --body "ローカルから自動コメント"
1. 事前に GitHub App の設定画面で「Device Flow」を有効化しておく必要がある ↩︎
GitHub 知っておくと便利かも Tips 2026 54
GitHub App の 2 方式比較 観点 Installation Token 方式 Device Flow 方式 秘密鍵の配布 有効期限 動作主体 対話性 権限スコープ 主な用途 必要（手元に置く） 1時間 Bot として動く 不要（自動化向き） 不要 8時間 ユーザー（App が代理で動く） 必要（ブラウザ認可） App + Installation + ユーザーが許可した範囲 ローカル CLI 認証、チームで共有する開発フロー App + Installation の全権限 CI/CD (Actions)、個人ローカル自動化、Bot 検証 Installation Token 方式: 秘密鍵管理ができる前提で、自動化の標準。Actions ではこれ Device Flow 方式: 秘密鍵を配布したくない場面の選択肢。ローカル CLI 認証で本領を発揮 GitHub 知っておくと便利かも Tips 2026 55
認証方法 - クレデンシャル比較（ざっくり） 観点 GITHUB_TOKEN GitHub App PAT (Fine-grained) PAT (Classic) 権限粒度 有効期限 発行者 細かい ジョブ終了まで Actions ジョブ実行 細かい 短命トークンは1時間 細かい 最大1年（設定変更で無期限可能） 粗い 最大無期限 漏洩時の影響範囲 実行中の repo のみ インストール先の enterprise、org、repo 指定リポジトリ 複数リポジトリ操作 ✗ ✓ ✓ 全てのリポジトリ 利用用途 単一リポジトリに閉じた API 操作 複数リポジトリや org に関する API 操作 ローカルマシンでの API 操作 enterprise / org user user user がアクセスできる ✓ ローカルマシンでの API 操作、 または ghcr.io に関する操作 GitHub 知っておくと便利かも Tips 2026 56
認証方法 - おすすめ優先度 以下の優先度で認証方法を選択する。上ほど低リスクだと思う。 1. GITHUB_TOKEN ↓ Actions 上じゃない or GITHUB_TOKEN では実現できない（別リポジトリへのアクセスなど[1]） 2. GitHub App ↓ GitHub App では実現できない、実現が困難、一時的に API 操作したいなど 3. PAT (Fine-grained) ↓ Fine-grained PAT では実現できない（Packages / ghcr.io へのアクセス[1:1]や Enterprise Billing API など） 4. PAT (Classic) 1. Packages はやや特殊: レジストリ認証に使えるのは Classic PAT か、GitHub Actions 内の （同一リポジトリの package。package 側の設定で同一 org の他リポジトリの Actions に許可を出すことも可能）のみ。GitHub App / Fine-grained PAT はどのレジストリも未対応 ↩︎ ↩︎ GITHUB_TOKEN GitHub 知っておくと便利かも Tips 2026 57
🛡️ 任意のファイルを関係者のみがマージできるようにする 大規模リポジトリの場合、さまざまな関係者が Write 権限を持っていることがある（フロントエンドエンジニア、バックエンドエンジ ニア、インフラエンジニア、デザイナーなど） 全員が全ファイルをマージできる状態だと、アカウントが乗っ取られた場合や誤って操作してしまった場合の影響範囲が大きい 特定のファイルやディレクトリは特定のチームしかマージできないようにすることで、万が一のときの影響範囲を限定できる GitHub では適切なファイルを適切な user / team がマージできるように設定することが可能。 CODEOWNERS で「このファイルはこの人/チームが見てね」という所有者を定義する Branch rulesets の Required reviewer rule で「このパスの変更にはこのチームの承認が必須」というルールを設定する GitHub 知っておくと便利かも Tips 2026 58
CODEOWNERS CODEOWNERS ( .github/CODEOWNERS ) リポジトリ内のコードに対するオーナーを定義するファイル プルリクエストが作成された際に定義に応じたレビュワーが自動でアサインされる レビュワーとしての設定は可能だが、そのままだと承認されなくてもマージ可能。マージに承認を必要としたいのであれば後述の Branch rulesets と組み合わせる Require review from Code Owners の有効化 .github/CODEOWNERS の例（※登場する固有名詞、設定内容は全て架空のものです） どのパターンにもマッチしない場合は @cybozu/product-owners チームをレビュワーにアサインする # * @cybozu/product-owners # コンポーネントごとにそれぞれのチームをレビュワーにアサインする /frontend/ @cybozu/frontend-team /backend/ @cybozu/backend-team # CODEOWNERS の変更は社長をレビュワーにアサインする /.github/CODEOWNERS @cybozu-ceo GitHub 知っておくと便利かも Tips 2026 59
Required reviewer rule（Branch rulesets） Branch rulesets（後述）にある「Required reviewer rule」を使うと、特定パスのマージに特定チームの承認を必須化できる org / enterprise 側の設定により、全リポジトリに横串で強制可能 指定できるのはチームのみ（個人ユーザー不可。個人指名をしたい場合は CODEOWNERS を使う） 設定イメージ → @cybozu/security の承認 1 件必須 /infra/** → @cybozu/sre の承認 1 件必須 .github/workflows/** GitHub 知っておくと便利かも Tips 2026 60
CODEOWNERS と Required reviewer rule の使い分け 観点 CODEOWNERS Required reviewer rule（branch rulesets） 定義場所 指定できる主体 スコープ 自動アサインのみ レビュワーの確認手段 リポジトリ内ファイル 個人 + チーム 設定リポジトリ内のみ repo / org / enterprise ruleset ✓ リポジトリ内のファイルを開く チームのみ 設定リポジトリ、または org / enterprise 内の複数リポジトリ ✗（承認必須） <repo>/rules で確認（read 権限で可） org / enterprise で横串に強制したいポリシー → Rulesets Required reviewer rule 個人オーナーを指名したい / コード内に所有を明示したい / 承認必須にせずレビュー依頼だけ自動で飛ばしたい → CODEOWNERS 併用も可能なので用途に合わせよう GitHub 知っておくと便利かも Tips 2026 61
GitHub 利用セキュリティ強化 🛡️予防 （改ざん対策）
🛡️ 改ざん対策 改ざんはサプライチェーンの複数箇所で起きうる行為。さまざまな改ざん対策があり、対象が違えば対策も違う。 次について 順に見ていく。 依存 Action のタグ書き換えを防ぐ 大事なブランチの改ざんを防ぐ 成果物（タグ・公開済みリリース）の改ざんを防ぐ 成果物が改ざんされていないことを証明する GitHub 知っておくと便利かも Tips 2026 63
🛡️ 依存 Action のタグ書き換えを防ぐ のように、Git タグでカスタムアクションを指定できるが、タグは原則として上書き可能。もしも 依存しているアクションに悪意のあるコミットが入り、タグが書き換えられた場合に侵害の被害に遭う タグの代わりにコミット SHA を指定することで、依存に悪意のある変更が入ってもその影響を受けない uses: actions/checkout@v4 タグは上書きされる可能性がある # NG: - uses: actions/checkout@v4 コミット は不変 # OK: SHA - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 GitHub 知っておくと便利かも Tips 2026 64
🛡️ 大事なブランチの改ざんを防ぐ 大事なブランチを改ざんしづらくすることで、悪意あるコードを含んだデプロイの可能性を減らせる 該当リポジトリに依存している他のプロジェクトやサービスへの影響も防げる Branch rulesets: ブランチに対して保護ルールを設定する機能 直接 push の禁止、レビュー必須化、署名コミット要求、CI パス必須化、etc… ローカル側ではなくリモート側（github.com）での保護機構であるため、強固な保護が可能 GitHub 知っておくと便利かも Tips 2026 65
Branch rulesets ブランチに対する操作を制限するための設定 「branch protection rules」から進化した機能 設定項目 Enforcement status: Active, Evaluate, Disabled から選択。Active にするとルールに従い操作が制限される。Evaluate にする と操作に対する評価は行われる（ログに記録される）が、操作は制限されないため、ルールのテストに使える Bypass list: ルールを無視できるロールやチーム、App、ユーザーを指定できる Targets: ルールを適用するブランチやタグをパターンで指定（default branch の指定も可能） Rules・Restrictions: 適用するルールを指定 GitHub 知っておくと便利かも Tips 2026 66
Branch rulesets のルール一覧 Restrict creations: ブランチの作成を拒否 Restrict updates: ブランチの更新を拒否 Restrict deletions: ブランチの削除を拒否 Require linear history: merge コミットを禁止。プルリクエストを取り入れる際は squash と rebase のみ許可 Require merge queue: マージ時はマージキュー機能の利用を強制[1] Require deployments to succeed: environments において deployments の成功を強制 Require signed commits: 署名付きコミットを強制 Require a pull request before merging: 全てのコミットをプルリクエスト経由で行うことを強制 Require status checks to pass: ステータスチェック(Actions のジョブなど)の成功を強制 Block force pushes: force push を禁止 Require code scanning results: code scanning によるアラートが指定したレベル未満であることを強制 Restrict commit metadata: コミットのメールアドレスやメッセージのパターンを指定してコミットを制限 Restrict branch names: パターンにマッチする（しない）ブランチ名を強制 1. 設定が非常に複雑だが使いこなすと強力。個人リポジトリでは使えないので試しづらいのが難点。ぜひ探究してほしい ↩︎ GitHub 知っておくと便利かも Tips 2026 67
よくある Branch rulesets 例 ブランチ、コミットが消失しないようにする Rules Restrict deletions Block force pushes 特定の CI ジョブの通過を必須にする Rules Require a pull request before merging Require status checks to pass Do not require status checks on creation Status checks that are required [1] : GitHub Actions: npm test （Actions のジョブ等を指定） 1. デフォルトブランチが対象なら問題ないが、合流ブランチなどの短命なブランチに対して適用する場合は設定しないとブランチ作成 (push) ができないため、これを有効にしている ↩︎ GitHub 知っておくと便利かも Tips 2026 68
よくある Branch rulesets 例
conventional commit、および、マージ時のコミットメッセージのみを強制する
Targets: All branches
Restrictions
Restrict commit metadata
Commit message
, Must match a given regex pattern ,
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w
])+([\s\S]*)|^Merge pull request.*
CODEOWNERS に関することや、レビュワーの必須化などについては後述します。
GitHub 知っておくと便利かも Tips 2026 69
🛡️ 成果物（タグ・リリース）の改ざんを防ぐ 公開した「タグ」「リリースアセット」を後から書き換えられないようにする手段は 2 つある。守る対象が違うので、必要に 応じて併用する。 Admin 迂回耐性 機能 守る対象 主な制限 Tag Rulesets Immutable Releases Git タグ (ref) のみ Release 全体（タグ＋アセット＋ attestation） 削除・上書き禁止、命名パターン強制、 Admin は Bypass list に入れる / Rulesets 自体を編集・無効化できるため迂回可能 署名コミット強制 アセット改ざん不可、自動 attestation Bypass list の概念がなく、Admin でも publish 済み immutable リリースは変更不可 付与 （機能を無効化しても既存リリースの凍結は維持） 使い分け リリースを伴わないタグを守りたい / パターン指定したい → Tag Rulesets リリースアセット（バイナリ等）も守りたい / Admin 権限侵害にも備えたい → Immutable Releases 配布物のあるリポジトリでは 両者を併用 するのが安全（衝突しない） 両者は「配布チャネル側を凍結する」予防策。後の Artifact attestations（受信側で出所と完全性を検証する予防策）と組み合わせると、配布と受信の 両面から改ざんを防ぐ多層防御になる。 GitHub 知っておくと便利かも Tips 2026 70
Tag rulesets タグに対する操作を制限するための設定 Branch rulesets と同様の仕組みで、Enforcement status、Bypass list、Targets、Rules、Restrictions を設定可能 Rules・Restrictions はブランチ向けと共通のものもあるが、タグ向けに特化したルールもある GitHub 知っておくと便利かも Tips 2026 71
Tag rulesets のルール一覧 Restrict creations: タグの作成を拒否 Restrict updates: タグの更新を拒否 Restrict deletions: タグの削除を拒否 Require linear history: merge コミットを禁止。プルリクエストを取り入れる際は squash と rebase のみ許可 Require deployments to succeed: environments において deployments の成功を強制 Require signed commits: 署名付きコミットを強制 Require status checks to pass: ステータスチェック(Actions のジョブなど)の成功を強制 Block force pushes: force push を禁止 Restrict commit metadata: コミットのメールアドレスやメッセージのパターンを指定してコミットを制限 Restrict tag names: パターンにマッチする（しない）タグ名を強制 GitHub 知っておくと便利かも Tips 2026 72
よくある Tag rulesets 例 タグの上書き、削除を禁止 Rules Restrict deletions Restrict updates Block force pushes タグ名に semantic versioning を強制 Targets: All tags Restrictions Restrict tag names Tag name , Must match a given regex pattern , ^v(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:- ((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+ ([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ GitHub 知っておくと便利かも Tips 2026 73
Immutable Releases デフォルトでは、リリースのアセット・対象タグは差し替え可能であり、攻撃者が後からバイナリを置き換えるリスクがある Immutable Releases: 公開済みリリースのアセットとタグを書き換え・削除不可に固定する機能 対象 リリースアセット: 公開後の追加・削除・置換が不可 リリースに紐づくタグ: 対象タグの更新・別タグへの付け替えが不可 永続性: 一度 immutable として publish したリリースは、後から Immutable Releases を無効化しても immutable 状態が維持され る（リリース単位で属性が固定される） 例え Admin 権限を奪取されても改ざん不可能 Org / Enterprise 単位で強制可能 attestasion が自動付与される（後述） 全プラン無料 GitHub 知っておくと便利かも Tips 2026 74
🛡️ 成果物の出所を証明する（Artifact attestations）
あらゆる策を講じた上でそれでも成果物が差し替えられてしまった場合でも、利用者側で「出所（どこでどう作られたか）」を検証でき
れば改ざんされた成果物の利用を未然に防げる
Artifact attestations: ビルド成果物に暗号的な来歴（provenance）を添付する仕組み。Sigstore ベース
ビルド時に actions/attest-build-provenance で attestation を生成、GitHub に登録される
利用者は gh attestation verify で検証。「どのリポジトリの・どのワークフローが・どのコミットから」ビルドしたかが分かる
Public リポジトリは Sigstore Rekor（透明性ログ） にも記録され、第三者監査が可能
生成は GitHub Actions 専用。他の CI/CD サービスでは生成できない（検証は CI 非依存）
コンテナイメージを
に
した上で
を生成
#
ghcr
publish
attestation
- uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0
with:
subject-name: ghcr.io/${{ github.repository }}
subject-digest: ${{ steps.image-publish.outputs.digest }}
利用者側での検証
#
$ gh attestation verify oci://ghcr.io/<ORG>/<IMAGE>:v1 --repo <ORG>/<REPO>
GitHub 知っておくと便利かも Tips 2026 75
GitHub 利用セキュリティ強化 - 🛡️予防 （認証情報漏洩）
🛡️ fork からの PR でシークレットが漏洩するのを防ぐ Actions において、 on.pull_request_target は base ブランチの権限（write + secrets アクセス）で実行される[1] fork からの PR で head のコードを checkout して実行すると、攻撃者のコードが secrets 付きで動く 原則: pull_request_target は使わない。ことがおすすめ 過去の重大インシデントの多くがこのイベントを起点に発生しており、安全に使いこなすための対策を真面目に考えないといけない fork の PR に対する通常の CI（Lint・テスト等）は pull_request で十分。fork のコードは secrets なしで実行されるため、 攻撃者がシークレットに触れない どうしても使いたい場合は、fork のコードを絶対に checkout しないことだけは厳守する 【2026.07 追記】2026-06-18 の actions/checkout の更新で、 pull_request_target 等で起動したワークフローによる fork PR コードの checkout はデフォルトで拒否されるようになった（v7 および全サポートバージョンへ backport 済み）。誤って踏みにくくなったが、opt-in で無効化も できるため「fork のコードを checkout しない」原則は引き続き重要 1. と、 2025-12-08 以前は、 はワークフロー定義とチェックアウトを base ブランチから取得していた。そのため base ブランチに古い脆弱なワークフローが残っている PR のたびにそれが動いてしまう問題があった。2025-12-08 の GitHub セキュリティ強化で、ワークフロー定義とチェックアウトは常にデフォルトブランチから取得されるように変更され pull_request_target た。ただしこの変更は前述の危険性を根本的に解消するものではなく、依然として pull_request_target の利用自体を避けるべき ↩︎ GitHub 知っておくと便利かも Tips 2026 77
Q: private / internal リポジトリなら fork は無いのでは？ private リポジトリでも fork は可能 Org 設定の Member privileges → 「Allow forking of private repositories」が有効なら fork できる Enterprise ポリシーで Org 横断的に許可されている場合もある internal リポジトリは Enterprise 内の全メンバーが fork 可能 Enterprise 内の誰でも読める＝誰でも fork できる fork 先は private リポジトリになる fork の可否は Org / Enterprise 設定に依存するため、ワークフロー側では fork がある前提で防御するのが安全 GitHub 知っておくと便利かも Tips 2026 78
Q: 社内関係者しかアクセスできないから大丈夫では？ アカウント侵害: フィッシングやクレデンシャル漏洩で社内メンバーのアカウントが乗っ取られれば、攻撃者は「社内関係者」として行 動できる tj-actions 事件も、信頼されたメンテナのアカウント侵害が発端 内部不正: 全メンバーが善意とは限らない。退職予定者・不満を持つメンバーのリスク blast radius（爆発半径）の大きさ: internal リポジトリは Enterprise 全メンバーに見える＝攻撃面が広い 「信頼できる人しかいない」は運用の前提であって、技術的な防御にはならない。多層防御で仕組みとして守る GitHub 知っておくと便利かも Tips 2026 79
🛡️ ワークフローへのスクリプトインジェクションを防ぐ
ブロックで ${{ github.event.* }} を直接展開するとコマンドインジェクションが成立する
攻撃者は PR タイトルやコメント本文にシェルコマンドを仕込める
run:
タイトルにシェルコマンドを仕込まれる
# NG: PR
- run: echo "PR: ${{ github.event.pull_request.title }}"
環境変数を経由すればシェル展開されない
# OK:
- env:
PR_TITLE: ${{ github.event.pull_request.title }}
run: echo "PR: $PR_TITLE"
危険な入力元: github.event.issue.title , github.event.issue.body , github.event.pull_request.title ,
github.event.pull_request.body , github.event.comment.body , github.event.review.body など
対策: ユーザー由来の値は必ず環境変数経由で渡す
GitHub 知っておくと便利かも Tips 2026 80
🛡️ シークレットを含みうるファイルのプッシュを防止する や秘密鍵（ .pem ）、 .terraform/ 配下のステートファイルなど、シークレット・機微情報を含みうるファイルは普段か ら .gitignore で除外している しかし .gitignore はあくまで「ローカルで無視する」ための仕組み。書き忘れや git add --force で強引にコミットされた ら防げない Push Ruleset はリモート側（GitHub）でファイルパス・拡張子・サイズ・パス長をパターン指定して push 自体を拒否する水際対策 ブランチ Ruleset / タグ Ruleset と並ぶ第3の Ruleset タイプ .envrc Secret scanning の Push protection がファイルの中身にあるシークレット値（API キー・トークン文字列など）を止めるのに対し、Push Ruleset は ファイルそのもの（パス・拡張子・サイズ）を止める。用途が異なり、両者は補完関係 GitHub 知っておくと便利かも Tips 2026 81
Push rulesets git push を制限するための設定 Branch ruleset、Tag ruleset と同様の仕組みで、Enforcement status、Bypass list、Rules を設定可能 ルール一覧 Restrict file paths: 特定のファイルパスのファイルのプッシュを禁止 Restrict file path length: 特定のファイルパスの長さ超えたファイルのプッシュを禁止 Restrict file extensions: 特定のファイル拡張子のファイルのプッシュを禁止 Restrict file size: 特定のファイルサイズを超えたファイルのプッシュを禁止 GitHub 知っておくと便利かも Tips 2026 82
よくある Push rulesets ルール例 大きなファイルのプッシュを禁止 Rules Restrict file size Maximum file size , 10MB シークレットを含みうるファイルのプッシュを禁止[1] Rules Restrict file paths */.terraform/** .terraform/** Restrict file extensions .envrc 1. ッシュを防げる に書いておけばいい話ではあるが、 ↩︎ .gitignore .gitignore に書き忘れた場合や git add --force で無理やりコミットしてしまった場合であってもプッシュ保護を設定しておけばプ GitHub 知っておくと便利かも Tips 2026 83
🛡️ API キーをプッシュ前にブロックする Push protection: git push の時点でシークレットを検出 し、プッシュ自体を拒否する水際対策機能 既にコミット済みのシークレットの扱いは検知の章の「コミット 済みのシークレットを検知する」を参照（Secret scanning が 担当） Public リポジトリでは無料・デフォルト有効。Private リポジトリでは GitHub Secret Protection ライセンスが必要 https://github.blog/jp/2023-05-16-push-protection-is-generallyavailable-and-free-for-all-public-repositories/より GitHub 知っておくと便利かも Tips 2026 84
🛡️ Actions のシークレットへのアクセスを絞る Actions secrets はどのブランチ上の Action からでも使えることから、write 権限を持つユーザーは誰でもシークレットを取得でき てしまう Environments という機能を使うと、特定のブランチ・タグ上で実行されるワークフローからのみシークレットにアクセスできるよう 制限できる Required reviewers: 指定したユーザー、チームの承認がないとジョブが開始できない Wait timer: デプロイ前に一定時間待機。誤承認の取り消しが可能 Deployment branches and tags: Environment を使える ref を main や v* タグなどに絞る Environment secrets / variables: 許可された ref から起動した job だけがアクセスできるシークレット・変数 on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest environment: production # この Environment のシークレットとルールが適用される # production Environment に紐づいたシークレット env: TOKEN: ${{ secrets.PRODUCTION_TOKEN }} steps: - run: ./deploy.sh GitHub 知っておくと便利かも Tips 2026 85
main ブランチでのみ利用可能なシークレットを設定する例 Environment: production Deployment branches and tags Selected branches and tags Environment secrets Branch ruleset (Target: main ) : main のみ追加 実際に利用するシークレットをここに追加 ブランチは必ず @sre チームメンバの 1 人以上の承認 を得た PR 経由でしか更新できないようにする Rule 内容 main Require a pull request before merging: Enabled Require review from specific teams: Reviewer: @sre Approvals: 1 File patterns: * GitHub 知っておくと便利かも Tips 2026 86
🛡️ Actions で他サービスへの認証に長命クレデンシャルを使わない Actions は OIDC の ID プロバイダー (IdP) として振る舞うことができる。発行された短命の ID トークンをクラウドプロバイダ側で検 証し、ジョブ実行時に短命なクレデンシャルを動的に取得できる (AWS、Google Cloud、Azure などが対応) 長命のクレデンシャルを Secrets に保管する必要がなくなるため、長期保管に伴う漏洩リスクを排除できる (短命トークン自体の盗取 リスクはゼロではない点に注意) 原理や設定方法はドキュメントなどを読んでください[1] jobs: deploy: runs-on: ubuntu-latest permissions: id-token: write # OIDC contents: read トークンを発行するための権限 steps: - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2 with: role-to-assume: arn:aws:iam::123456789012:role/s3-read-only-by-github-actions aws-region: ap-northeast-1 - run: aws s3 ls 1. https://docs.github.com/en/actions/concepts/security/openid-connect ↩︎ GitHub 知っておくと便利かも Tips 2026 87
GitHub 利用セキュリティ強化 - 🛡️予防 （その他）
🛡️ 脆弱性のある依存関係の追加を防ぐ Dependency Review Action（ actions/dependency-review-action ）は GitHub 公式の Action PR で追加・変更される依存を GitHub Advisory Database と照合し、脆弱性があればチェックを失敗させる Dependabot が「入った後に検知」なら、Dependency Review は「入る前にブロック」 で脆弱な依存の追加をブロック # PR - uses: actions/dependency-review-action@2031cfc080254a8a887f58cffee85186f0e49e48 # v4.9.0 with: fail-on-severity: moderate 対応エコシステム: npm, pnpm, Yarn, Go, Cargo, Maven, pip, Poetry, NuGet, RubyGems, GitHub Actions etc. Public リポジトリは無料。Private リポジトリでは GitHub Code Security ライセンスが必要 GitHub 知っておくと便利かも Tips 2026 89
🛡️ リポジトリの可視性変更や削除の誤操作を防ぐ Repository policies: Organization の Policies > Repository から、リポジトリに対する操作を Organization 全体で一律に制限できる リポジトリの可視性変更、作成、削除、移転、命名を制限可能 個人の注意力に頼らず、仕組みで誤操作を防ぐ Rulesets がブランチ・タグ単位の保護なのに対し、Repository policies はリポジトリそのものに対する操作を制御する GitHub 知っておくと便利かも Tips 2026 90
Repository policies の設定 Policy Name: ポリシーに名前を付けて管理 Enforcement status: Active / Inactive を切り替え。Active にするとポリシーに従い操作が制限される Allow list: ポリシーの制限を免除するロール、チーム、App、ユーザーを指定できる Target repositories: ポリシーを適用するリポジトリの範囲を指定（全リポジトリ or パターンで絞り込み） Policies: 適用するポリシー（制限項目）を選択 GitHub 知っておくと便利かも Tips 2026 91
Repository policies のポリシー項目 Restrict visibility: 作成するリポジトリの可視性、および可視性の変更を制限。許可する可視性（Public / Internal / Private）を個別 に指定できる Restrict creations: リポジトリの作成を Allow list のユーザーのみに制限 Restrict deletions: リポジトリの削除を Allow list のユーザーのみに制限 Restrict transfers: リポジトリの Organization 外への transfer を Allow list のユーザーのみに制限 Restrict names: リポジトリ名を特定のパターンに制限。命名規則の強制に使える GitHub 知っておくと便利かも Tips 2026 92
GitHub 利用セキュリティ強化 - 🔍検知
🔍 依存ライブラリの脆弱性を検知する Dependabot alerts: 依存関係に含まれる既知の脆弱性を GitHub Advisory Database と照合して自動検知。Security タ ブと PR 上にアラート表示 Dependabot security updates: アラートを受けて脆弱性を修 正する PR を自動生成。検知から対応の初動まで一気通貫 対応エコシステム: npm / pip / Maven / Gradle / Go / Composer / Swift / Docker / GitHub Actions など多くのエコ システムをカバー 全てのケースに対応しているわけではないので過信しないこ と リポジトリ設定で有効にしておく必要がある https://docs.github.com/en/code-security/tutorials/secure-yourdependencies/dependabot-quickstart-guide より Dependabot alerts / security updates は全プラン無料（Private リポ ジトリでも利用可能） GitHub 知っておくと便利かも Tips 2026 94
🔍 コード内のセキュリティ脆弱性を早期に発見する Code scanning: コードを静的解析して脆弱性パターンを自動 検出する仕組み。検出結果は Security タブと PR 上にアラート として表示される CodeQL（GitHub 公式の解析エンジン）が基本。SQL イン ジェクション、XSS、パストラバーサル等の脆弱性パターン を検出 サードパーティ SAST ツール（Snyk Code, Semgrep 等） の結果も SARIF 形式で取り込み可能 Copilot Autofix: CodeQL やサードパーティ SARIF のアラート に対して、Copilot が修正コードと解説を自動生成。PR 上でそ のまま適用できる https://docs.github.com/en/code-security/concepts/codescanning/about-code-scanning-alerts より Public リポジトリでは Code scanning・Copilot Autofix ともに無料。 Private リポジトリでは GitHub Code Security ライセンスが必要 GitHub 知っておくと便利かも Tips 2026 95
🔍 コミット済みのシークレットを検知する Secret scanning: リポジトリ内のコミット履歴を継続的にスキャンし、既にコミットされたシークレットを検出・アラートする 予防の層の Push protection をすり抜けたり、過去にコミットされたシークレットを拾うのが役割 発見後はシークレットをローテーションするなり、場合によってはヒストリーを捨てて過去のコミットから完全に消すなりの対応が必 要 Public リポジトリでは無料・デフォルト有効。Private リポジトリでは GitHub Secret Protection ライセンスが必要 GitHub 知っておくと便利かも Tips 2026 96
🔍 組織全体のセキュリティ状況を俯瞰する Security overview: Organization レベルでセキュリティの状 況を一覧できるダッシュボード Dependabot alerts、Code scanning alerts、Secret scanning alerts の横断的な可視化 リスクの高いリポジトリの特定に有用 未対応のアラートが多いリポジトリを素早く発見 組織全体のセキュリティ対応状況を把握 Custom properties（後述）でリポジトリの重要度や優先度を 定義しておくと、より効果的に活用できる 契約している GitHub Code Security / Secret Protection の範囲によっ て、見える情報が変わる https://github.blog/changelog/2024-05-23-code-security-andsecret-scanning-insights-for-your-enterprise-public-beta より GitHub 知っておくと便利かも Tips 2026 97
GitHub 利用セキュリティ強化 - 🚨対応
🚨 サプライチェーン侵害発覚時に影響範囲を特定する 汚染バージョンが公開された時、どのリポジトリ・どの経路で影響が及ぶかの棚卸しが初動の鍵 Dependency graph : ロックファイル等を自動解析し、依存関係グラフを作る機能。さらにそれを SBOM（Software Bill of Materials、依存関係の台帳）で出力可能 全ての依存に対応しているわけではないので、実際に出力してみるなどどこまで対応されてるかを確認しておくことが重要 Private / Internal リポジトリでは Organization 設定または個別リポで明示的な有効化が必要 対応エコシステム例（何にどこまで対応しているかはドキュメント[1]で要確認） カテゴリ npm 系 Java 系 Go 系 Actions 対象ファイル 推移依存 / package-lock.json / pnpm-lock.yaml / yarn.lock pom.xml （Maven） / build.gradle （Gradle） ✓ Maven ✓ / Gradle ✗ 公式 doc では推移的依存に未対応だが、検証したところ indirect の依存も載った[2] ✗ package.json go.mod .github/workflows/*.yml の uses: 1. https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/dependency-graph-supported-package-ecosystems ↩︎ 2. ドキュメント上は未対応となっているため自分で確認してほしい ↩︎ GitHub 知っておくと便利かも Tips 2026 99
例: SBOM ファイル（SPDX 2.3 JSON）
{
"sbom": {
"spdxVersion": "SPDX-2.3",
"name": "com.github.korosuke613/homepage-2nd",
"packages": [
{
"name": "@storybook/addon-a11y",
"versionInfo": "9.1.20",
"licenseConcluded": "MIT",
"externalRefs": [
{ "referenceType": "purl", "referenceLocator": "pkg:npm/%40storybook/[email protected]" },
...
]
}
],
"relationships": [
{ "spdxElementId": "SPDXRef-npm-storybook-addon-a11y-9.1.20-...",
"relatedSpdxElement": "SPDXRef-npm-axe-core-4.10.3-...",
"relationshipType": "DEPENDS_ON"
},
...
]
}
}
: 依存一覧（名前・バージョン・ライセンス・purl など）
relationships[] : DEPENDS_ON で親子関係 → 依存グラフを復元可能
packages[]
GitHub 知っておくと便利かも Tips 2026 100
例: SBOM でリポジトリが影響を受けるかどうか確認する
単一リポジトリ
export OWNER="korosuke613" REPO="homepage-2nd" PATTERN="korosuke613/dangerous-action"
gh api "/repos/$OWNER/$REPO/dependency-graph/sbom" > "${REPO}.sbom.json"
jq -r '.sbom.packages[] | select(.name | test(env.PATTERN)) | "\(.name) \(.versionInfo // "")"' "${REPO}.sbom.json"
実行結果
#
korosuke613/dangerous-action 4b73464bb391d4059bd26b0524d20df3927bd417
オーナー配下の全リポジトリ
export OWNER="korosuke613" PATTERN="korosuke613/dangerous-action"
mkdir -p "sbom-$OWNER"
gh repo list "$OWNER" --limit 1000 --source --no-archived \
--json nameWithOwner -q '.[].nameWithOwner' \
| while read -r repo; do
gh api "/repos/$repo/dependency-graph/sbom" > "sbom-$OWNER/${repo#*/}.json"
done
for f in "sbom-$OWNER"/*.json; do
echo -e "repo:\t$OWNER/$(basename "$f" .json)"
jq -r '.sbom.packages[] | select(.name | test(env.PATTERN)) | "\t\(.name) \(.versionInfo // "")"' "$f"
done
実行結果
#
repo: korosuke613/homepage-2nd
korosuke613/dangerous-action 4b73464bb391d4059bd26b0524d20df3927bd417
repo: korosuke613/zenn-metadata-updater
korosuke613/dangerous-action v1.2.3
GitHub 知っておくと便利かも Tips 2026 101
🚨 侵害の痕跡を audit log で調査する Organization / Enterprise ではメンバー・権限・設定などの操作ログが記録されており、侵害の初動で「誰が・いつ・何をしたか」を 辿る起点になる 閲覧: Organization Settings → Logs → Audit log （Git 操作は Git events タブ） REST API からも取得可能: GET /orgs/{org}/audit-log Audit log streaming で AWS S3 や Datadog に転送できる（GitHub 内には 180 日ほどしか保存されない） ⚠ 記録「されない」もの コードや差分の中身: commit の内容・レビュー本文・Issue や PR のコメント本文は audit log に乗らない（Git 履歴や API で別途 確認） Actions のステップ実行ログ: Actions の実行ログ上から確認できるが、audit log には記録されない Git の Read 操作（ clone / fetch / pull ）: Git events が有効な Enterprise プランのみ記録、しかも retention はさら に短い Organization の Audit log 参照は全プラン可能。Audit log streaming と Git events の常時記録は Enterprise プラン（EMU 含む）のみ GitHub 知っておくと便利かも Tips 2026 102
🚨 インシデント発生時に認証情報を一括無効化する Enterprise 設定の Danger zone から、配下の全 Org・リポジトリに関連する認証情報を一括で無効化できる 2つのアクション: アクション 効果 前提条件 Revoke SSO authorizations Delete keys and tokens 全 Org の SSO 認可を取り消し トークン・SSH キーを完全削除 SAML SSO or EMU EMU のみ 対象: ユーザー SSH キー、OAuth App トークン、GitHub App ユーザートークン、PAT（classic / fine-grained） 対象外: Installation tokens、deploy keys、GitHub Actions tokens（ GITHUB_TOKEN ） 例えば、どんなシークレットが漏洩したかわからないが漏洩したのは間違いない、といった状況で役に立つ[1]。 1. そのレベルのやばい状況だと、enterprise や org 全体の設定で GitHub Actions を一律無効化することもやった方が良さそう ↩︎ GitHub 知っておくと便利かも Tips 2026 103
Tips集
💡 Actions のコストを安く抑えたい arm64 ランナーの採用: arm64 の vCPU を持ち、x64 ランナーより単価が安い arm64 でも動作可能なジョブにおすすめ ubuntu-slim ランナーの採用: コンテナベースの 1 vCPU 軽量ランナー（x86）で、標準ランナーより単価が安い 起動が速く、自動化・短時間ジョブ向けに標準ランナーより低コスト ジョブ実行時間に 15 分の上限あり（ timeout-minutes で延長不可）。超えるとジョブは失敗する Issue 操作・通知・軽い lint 等、15 分以内に終わる、かつ、コンテナ特有の制限がないジョブにおすすめ ランナー ubuntu-latest （ ubuntu-24.04 ） ubuntu-24.04-arm ubuntu-slim arch x64 arm64 x64 vCPU 2 2 1 1. Private リポジトリの分単位課金（2026 年 4 月時点）。Public リポジトリは無料枠内なら $0 ↩︎ RAM 8 GB 8 GB 5 GB ストレージ 単価[1] 備考 14 GB 14 GB 14 GB $0.006/min $0.005/min $0.002/min 15 分上限 GitHub 知っておくと便利かも Tips 2026 105
💡 組織の Actions 利用状況を把握したい Actions usage metrics: Organization の Actions 利用量・コ ストを把握できるダッシュボード Actions performance metrics: ワークフローの実行時間・キ ュー待ち時間・失敗率の推移を分析できるダッシュボード コスト最適化やボトルネック特定の意思決定に活用できる Actions usage metrics Actions performance metrics GitHub 知っておくと便利かも Tips 2026 106
💡 マージ済みの不要ブランチを片付けたい Automatically delete head branches プルリクエストをマージした後に、マージ元のブランチを自動的に削除する機能 大規模なリポジトリになるとマージ済みで不要になったブランチであふれかえりがちなので設定しておくと便利 マージ後に CI でブランチを再利用して何かやる場合には困るかもしれないので注意 不要なブランチが残らなくて便利 GitHub 知っておくと便利かも Tips 2026 107
💡 外部タスク管理の番号を自動リンク化したい Autolink references リポジトリ内の Issue や PR、コミットメッセージに含まれる特定の文字列を自動的にリンクにする機能。 kintone や Linear、Jira などでタスク管理している場合に便利。 こんな感じでマッチする文字列がリンクになる 数字> に https://example.com/tickets/TASK-<数字> のリンクを貼る設定 TASK-< GitHub 知っておくと便利かも Tips 2026 108
💡 複数人で作業したコミットの貢献者を明示したい Co-authored-by 複数人で作業したコミットであることを示すための機能 コミットメッセージに Co-authored-by: <名前> <<メアド>> を追加する 誰の貢献であるか、誰の責任でコミットされたかをはっきりさせられる。モブプログラミング時に有用 ただし、これを毎回設定することの面倒くささの方が勝る… コミットメッセージ # feat: most fantastic feature Co-authored-by: Seisan Shain kun <[email protected]> GitHub のユーザと紐づいた形で表示される GitHub 知っておくと便利かも Tips 2026 109
💡 GitHub 上のコードを不変な URL で共有したい GitHub 上のコードを共有する際、気をつけないとブランチに依存し た URL になってしまう 例: https://github.com/korosuke613/homepage2nd/blob/main/src/components/MyIcon/index.tsx#L101-L105 この URL は main ブランチの /src/components/MyIcon/index.tsx の 101 行目から 105 行目を指している main ブランチが更新されると、101 行目から 105 行目のコード が変わってしまう こうならないようにコードを URL で共有する際はパーマリンク化し て共有する A さん「隠しコマンド一覧を共有します」 ↓ main ブランチが更新された！ ↓ B さん「本当にこれ隠しコマンド一覧？？？」 GitHub 知っておくと便利かも Tips 2026 110
パーマリンクで不変なコードを共有する GitHub では簡単にパーマリンク化できる ショートカットキー y [1] アドレスバーの ref 部分がコミットハッシュになる 3点リーダー（ ••• ）をクリックして Copy permalink をクリック パーマリンクとしてクリップボードにコピーされる 先ほどの例だと https://github.com/korosuke613/homepage- 2nd/blob/299bb6174a38c85d4b2deebd5f96c3427fce2b17/src/components/MyIcon/index.tsx#L101-L105 が得られる コミットが残る限り共有されるコードの内容は不変となる 注意点：共有される側はコミットハッシュを含む URL が最新のコミットとは限らないことを理解しておく必要がある[2] 1. 平木場はもはや キーを押すのが癖になっている ↩︎ 2. すぐに気づくとは思う ↩︎ y GitHub 知っておくと便利かも Tips 2026 111
💡 CLI や CI から GitHub を素早く操作したい GitHub 公式ツールの GitHub CLI（ gh コマンド）を使えば CLI 環境や Actions[1]上から簡単に GitHub を操作できる コマンド例 : OAuth app 経由で GitHub にログイン gh pr view --web : 現在のブランチから PR を特定してブラウザでオープン gh api : GitHub API を直接実行するためのコマンド API の検証や GitHub CLI ではできないことを自動化する際に使う 例: gh api /rate_limit : 現在の認証情報における各種 API の rate limit を取得 各種 API はドキュメントをチェック REST API: https://docs.github.com/en/rest GraphQL API: https://docs.github.com/en/graphql gh auth login 1. GITHUB_TOKEN を渡すだけで（スコープの範囲内の API が）実行できて楽 ↩︎ GitHub 知っておくと便利かも Tips 2026 112
💡 Markdown で注意書きを視覚的に目立たせたい GitHub の Markdown で使えるアラート構文で、注意書きや補足情報を視覚 的に目立たせられる Issue、PR、Discussion、README など GitHub 上の Markdown で利用可 能 Markdown の仕様には存在しない。GitHub Flavored Markdown 独自の機能 > [!NOTE] > 補足情報です。 > [!TIP] > 便利なヒントです。 > [!IMPORTANT] > 重要な情報です。 > [!WARNING] > この操作は取り消せません。 > [!CAUTION] > この操作を行うと、データが完全に削除されます。 GitHub 知っておくと便利かも Tips 2026 113
💡 リポジトリが増えすぎて分類・管理が大変 org レベルでリポジトリに設定する任意のプロパティを定義できる（Custom properties）[1] 例: product: true 、 team: backend 、 compliance-level: high キーは org 側で定義し、値はリポジトリごとに指定する形 例えば、Rulesets のターゲットとしてプロパティでの絞り込みが可能 例: compliance-level: high のリポジトリにだけ厳格なブランチ保護 ルールを適用 他にもプロパティで絞り込める場所が増えてきている リポジトリの分類を簡単にし、必要なリポジトリだけに特定のルールや設定を 適用したり、何か問題が起きた時の対応優先度の判断をしたりと、運用の効率 化に役立つ 1. enterprise レベルでも org や repository に対して設定可能なプロパティを定義できるが、今回は割愛 ↩︎ GitHub 知っておくと便利かも Tips 2026 114
💡 GitHub の調子が怪しい！ 「Actions が急に動かない」「Push が通らない」「PR の表示が崩れている」-> 自分の設定ミスか GitHub 側 の障害かを最初に切り分けると早い www.githubstatus.com で各サービスの状況と進行中 のインシデントが確認できる 通知の購読も可能: RSS / Atom、メール、SMS、 Slack / Teams 等の Webhook なんか怪しいと思ったらとりあえず確認しよう www.githubstatus.com のスクリーンショット GitHub 知っておくと便利かも Tips 2026 115
おわりに
まずはドキュメントを探そう よくわからない GitHub の機能を見つけたらドキュメントを確認しよう。 GitHub 公式ドキュメント: https://docs.github.com 検索バーから Copilot くんへの質問もできるよ 最近のドキュメントの変更が知りたい時は https://github.com/github/docs のコミット履歴を見よう GitHub Changelog: https://github.blog/changelog/ GitHub の新機能・変更がタイムリーに投稿される。RSS フィードもあり GitHub Blog: https://github.blog/ 新機能の詳細な解説記事やベストプラクティスが掲載される GitHub を使って生産性の高い開発ライフを！ GitHub 知っておくと便利かも Tips 2026 117