#Security #Continuous Integration GitHub Actions における権限昇格を引き起こす 3 パターンと対策を解説した Flatt Security ブログ記事（2026 後編） 権限昇格の 3 パターン 過剰なデフォルト権限: permissions 未宣言の workflow は広い権限を継承し、workflow_dispatch API 経由で悪意ある workflow の実行が可能 キャッシュポイズニング: 10 GB 上限を悪用して正規キャッシュを退避。デフォルトブランチのキャッシュが全ブランチから読めることを利用し、issue トリガー（低権限）から release workflow（高権限）へ汚染が跨ぐ secrets: inherit: 再利用可能 workflow に全 secrets を暗黙で渡す設定。侵害された 1 workflow が上流全 secrets に波及 対策 workflow root に permissions: {} を宣言し、job 単位で必要な権限のみ付与 classic PAT 廃止 → fine-grained PAT 移行、Organization base permissions を Read に制限 release 系 workflow でキャッシュ無効化、secrets: inherit を明示的 secret 渡しに変更 GitHub App private key はクラウド KMS（例: Azure Key Vault）で管理し secrets ストアには置かない https://blog.flatt.tech/entry/2026-github-actions-security-part2

#Security #Continuous Integration GitHub Actionsワークフローの静的解析を行うSASTツール。サプライチェーン攻撃や認証情報窃取につながる workflow 設定の不備を検出する Rust製。.github/workflows/ 配下の YAML を解析し、命名された audit ID 単位で検出 / ignore を行える 主な audit カテゴリ: dangerous-triggers template-injection unpinned-uses excessive-permissions overprovisioned-secrets https://zizmor.sh/ https://github.com/zizmorcore/zizmor

#Security #Continuous Integration GitHub Actions で OIDC や Trusted Publishing を導入しても runner 上の認証情報漏洩リスクは構造的に残る、という限界を解説した Flatt Security ブログ記事（Part 3） 漏洩経路: Runner.Worker プロセスのメモリダンプで GITHUB_TOKEN や環境変数の secrets・OIDC 派生クレデンシャルを取得可能（GitHub-hosted runner は sudo がパスワードなしで実行可能） 軽減策: クラウド側でクレーム完全一致検証・数値 ID 優先・インラインセッションポリシーで権限を多層絞り込み；認証 step と任意コード実行 job を分離 残る攻撃面: サプライチェーン攻撃で依存が汚染された場合、認証 job のコンテキスト内で悪意コードが動く（IaC ワークフローは job 分離自体が困難） 検知と対応: 一時クレデンシャル（有効期間 ~1.5h）の悪用を前提に CloudTrail・Cloud Audit Logs・GuardDuty 等で検知体制を整備 https://blog.flatt.tech/entry/2026-github-actions-security-part3 Blog

#Security #Continuous Integration Cilium を題材に CI/CD 依存の固定・審査戦略を解説した CNCF ブログ記事（全3回の第2回） GitHub Actions の SHA pin: タグではなく 40 字コミット SHA で参照し、tag 書き換えによるサプライチェーン攻撃を防ぐ Renovate 自動更新: pinGitHubActionDigests preset で SHA を自動管理、minimumReleaseAge 5 日クールダウンで公開直後の悪意バージョンを回避 Go ベンダリング: vendor/ をリポジトリに commit し CI で go.mod/go.sum を検証、proxy 改ざんをレビュー可視に actionlint で pin 漏れ・runner image タグ未固定を検出 CODEOWNERS で vendor/ 変更者を限定し依存変更の承認ゲートを構築 https://www.cncf.io/blog/2026/06/12/securing-ci-cd-for-an-open-source-project-locking-down-dependencies/

#Continuous Integration GitHub Actions の workflow 内で、PR / push で変更されたファイルの一覧を出力する community action tj-actions/changed-files。後続 step は出力を参照し、変更パスに応じて処理を分岐できる https://github.com/tj-actions/changed-files

#Programming #Continuous Integration GitHub公式のコード品質機能。Code scanning を拡張し、Pull Request 上でコード品質の問題を検出して修正提案までを提供する。 2025 年に public preview として公開。GitHub Team / Enterprise Cloud の組織リポジトリのみ対応（Enterprise Server 非対応）で、別途 Copilot / Code Security ライセンスは不要 ルールベース解析（CodeQL エンジン）と AI 解析の 2 系統で、保守性・信頼性・パフォーマンス・複雑度・重複/デッドコード・テストカバレッジなどを検出する 指摘は PR 上にインライン表示され、GitHub Copilotによるワンクリック autofix と reliability/maintainability スコアを提示する スキャンはGitHub Actions上で実行され、Actions minutes を消費する 適応度関数のコード品質カテゴリに該当する https://docs.github.com/en/code-security/concepts/about-code-quality

#Continuous Integration Terraform GitHub provider の resource で、GitHub リポジトリ内の単一ファイルの内容を宣言管理する（repository / file（パス）/ content / branch を指定し commit として反映）。 .github/workflows/*.yml を対象にすれば GitHub Actions のワークフローを配布でき、for_each で複数リポジトリへ撒ける コピーして終わりではなく宣言内容へ収束し続ける点が要: 配布先での手動編集も drift として plan で検出され apply で是正される https://registry.terraform.io/providers/integrations/github/latest/docs/resources/repository_file

#Continuous Integration 指定した status check（CI チェック）の成功を PR マージの条件にする GitHub の ruleset ルール（正式名 "Require status checks to pass before merging"）。repository / organization どちらのレベルでも設定できる。 status check は GitHub Actions のジョブ・外部 CI（Commit Status API）・GitHub App から付与され、base 追従を必須化する up-to-date オプションを持つ https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets

#Security #Cloud Native #Continuous Integration GitHub Actions / GitLab CI/CD のジョブをeBPFでカーネルレベルに監視し、実行時のサプライチェーン攻撃を検出するオープンソースのランタイムセキュリティセンサー（"Think EDR, but for CI/CD Pipelines"） CI/CD が握る認証情報・署名鍵・トークンを狙う攻撃に対し、汚染された依存がジョブ内で「何を実行したか」のランタイム可視性と事後調査の手段を与える 検出の仕組み: プロセス系譜分析 - 例として npm install から派生したプロセスによる認証情報アクセス シグナル相関 - 例として 1 ジョブ内での複数カテゴリの認証情報アクセス 構成要素: Sensor - eBPF ベースのランタイムモニタ Action - GitHub Actions 統合。run ごとにレポートと build attestation を生成 Manager - ログを S3 / GCS / Pub/Sub 等のクラウドシンクへルーティング（データはユーザー管理下） 2026 年時点で pre-release・活発に開発中 https://github.com/cicd-sensor/cicd-sensor

#Continuous Integration GitHub の organization / enterprise レベル専用の ruleset ルールで、指定した GitHub Actions ワークフローの成功を PR マージの条件にする（正式名 "Require workflows to pass before merging"、旧 Required workflows）。各リポジトリにファイルを追加せず適用でき、GitHub Enterprise Cloud 等の GitHub Enterprise プランが必要。 repo 単位でチェック成功を必須化する別ルール require status checks とは別物 https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets

#Continuous Integration Renovate を GitHub Actions 上でセルフホストする公式 Action renovatebot/github-action。ホスト型 Mend Renovate App を使わず、自前リポジトリの workflow から依存更新 PR を回す前提のセットアップ 設定 workflow の on.schedule（cron）で定期実行する（例: 0/15 * * * *） 設定ファイルは configurationFile で指定（JS / JSON）。RENOVATE_ 接頭辞の環境変数はそのままコンテナへ渡る renovate-version で実行する Renovate（Docker イメージ）のバージョンを固定できる https://github.com/renovatebot/github-action

#Security #Continuous Integration GitHub Actions の action / reusable workflow の参照を full-length commit SHA に pin する CLI（@suzuki-shunsuke 製）。タグは可変で改ざんの余地があり、SHA 固定だけが不変なリリース参照になる、というサプライチェーン攻撃対策。 pinact run で参照を SHA に pin（# v3.5.1 のバージョンコメント付き）。--update で更新、整合の検証にも対応 --no-api で API なしの構文チェック、--min-age でリリース直後の参照を弾く https://github.com/suzuki-shunsuke/pinact

#Continuous Integration リポジトリ設定を policy-as-code で組織横断に宣言・適用する GitHub App（Probot ベース）。admin リポジトリに設定を集中管理し、各 repo の実設定を GitHub API 経由で宣言状態へ収束させる、repo 設定版の Infrastructure as Code。Platform Engineering の guardrails 実装の一つ 設定は admin repo の 3 階層（.github/settings.yml=org / suborgs/*.yml / repos/*.yml）で各 repo にマージ適用、優先度は repo > suborg > org full sync（CRON）で drift を検出・修正、PR では nop モードで dry-run 差分を提示 管理対象は GitHub API で扱う設定のみ（branch protection / labels / collaborators / teams / topics / custom properties / environments / rulesets 等）。ファイル内容は扱えず .github/workflows/*.yml の配布はできない（GitHub Actions の強制は ruleset / require workflows 経由） Organization 専用で個人アカウントでは動かない https://github.com/github/safe-settings

#Continuous Integration GitHub Actions の workflow 内で GitHub App のインストールアクセストークンを発行する公式 Action actions/create-github-app-token。App の ID と private key を渡すと、対象を絞ったトークンを払い出す 特徴 発行されるインストールトークンは 1 時間で失効する短命トークン。post step で自動 revoke され、明示しない限り他 job へは渡らない owner / repositories でアクセス先リポジトリを限定し、権限を細かく絞れる デフォルトの GITHUB_TOKEN（権限が制限的で後続 CI をトリガできない）や PAT の代替として使い、GitHub App の bot 名義で commit / comment できる https://github.com/actions/create-github-app-token

#Continuous Integration GitHub Actions が各 workflow run の開始時に自動発行する組み込みトークン。secrets.GITHUB_TOKEN または github.token で参照でき、その run 内で GitHub API / Git 認証に使う 実体は github-actions[bot] という GitHub App のインストールアクセストークンで、job が終わると失効する短命トークン（最長 24 時間） 特徴 権限は workflow の permissions キーで制御し、最小権限の付与が推奨される 権限のスコープは workflow が置かれたリポジトリに限定される GITHUB_TOKEN で起こしたイベントは新たな workflow run をトリガしない（再帰実行の防止）。このため bot 起点で後続 CI を回すには GitHub App トークンや PAT が必要になる https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication

GitHubの planning & tracking ツール。Issue と Pull Request を集約し、カスタムフィールド付きの table / board / roadmap として可視化する user / organization レベルで管理され、item にメタデータ（date・single select・iteration 等、最大50フィールド）を付与できる table（表）/ board（かんばん）/ roadmap（タイムライン）の3レイアウトを切り替えられる built-in workflows で item の追加・変更時にフィールドを自動設定でき、GraphQL API や GitHub Actions でさらに細かく自動化できる https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects

#Security changed-files action (≤ v45.0.7) が侵害されたサプライチェーン攻撃の脆弱性。全タグが malicious commit に retroactively 付け替えられ、汚染された action が GitHub Actions runner の secrets を workflow ログへ dump した (embedded malicious code)。 CWE-506 (Embedded Malicious Code) CVSS 3.1: 8.6 HIGH (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) 影響: tj-actions/changed-files ≤ v45.0.7、v46 で解消 https://www.cve.org/CVERecord?id=CVE-2025-30066 https://nvd.nist.gov/vuln/detail/CVE-2025-30066

#Data Engineering AtlasをベースとしてマイグレーションDockerイメージを、GitHub Actionsでビルド＆パブリッシュ、Kubernetes Job上のArgo CDでのマイグレーションリリースまでを自動化する記事 https://tech-blog.rakus.co.jp/entry/20250526/dbmigration

#Security GitHub Actionsの人気 action changed-files が侵害されたサプライチェーン攻撃事例 CVE-2025-30066 発覚: 2025-03-14 09:00 PT (16:00 UTC)、StepSecurity が Harden-Runner の挙動監視で検知 侵害手法: @tj-actions-bot の PAT が奪取（取得経路は不明） リポジトリ外で作成した malicious commit (0e58ed86...) に全タグを retroactively 付け替え（tag 移動による action 汚染の典型） ペイロード: Python script が /proc/[pid]/mem 経由で GitHub Actions runner プロセスのメモリから secrets を dump、log に double base64 で出力 影響: 23,000+ リポジトリ。compromise 窓は約 37 時間 (2025-03-14 16:00 UTC 〜 2025-03-15 22:00 UTC)。public repo の log は誰でも読めるため secrets 漏洩 復旧: 2025-03-15 22:00 UTC に GitHub がリポジトリを復旧、その後 v46.0.1 リリース 対処: step-security/changed-files@v45 等への切替、または SHA pin 化、漏洩可能性ある secrets を rotate https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised ブログ

Claude CodeをGitHubリポジトリ上で呼び出すのを容易にするGitHub Actions GitHub Issue、PR上で @claude メンションを用いて起動が可能になる https://github.com/anthropics/claude-code-action