はてなブックマーク

先日 tj-actions/changed-files などの人気の GitHub Actions のセキュリティインシデントがありました (CVE-2025-30066)。 自分は OSS の開発者として様々な OSS を公開しており、こういったセキュリティインシデントは他人事ではありません。 そこでこの 1 ヶ月弱セキュリティ周りを見直し、かなり改善することが出来ました。 本記事では GitHub のセキュリティを改善する方法について紹介します。 主なターゲットしては自分のような OSS の開発者ですが、 GitHub を使っている方全てに参考になる内容かなと思います。 皆さんが本記事を参考にセキュリティを改善し、セキュリティインシデントを未然に防ぐことが出来れば幸いです。 先日登壇した GitHub Actions 関連の資料 先日 2025-03-11 に GitHub Actio

先日起きた tj-actions や reviewdog のセキュリティインシデントのレポートを読みました。 その内容を個人的な検証結果や感想を挟みつつかいつまんで書きたいと思います。 詳細は原文を読んでください。 なお、侵害された repository 及び tag は全て修正され、盗まれた Personal Access Token (PAT) も revoke されているはずです。 攻撃の流れ tj-actions/changed-files が侵害されるまでに複数の PAT の流出及びリポジトリの侵害が連鎖的に起こっています。 つまり tj-actions/changed-files が直接的にいきなり侵害されたというより、複数のリポジトリをいわば踏み台のようにして侵害したという感じでしょうか。 攻撃者は PAT が盗まれたりした GitHub Account とは別に複数の Gi

GitHub Actions でセキュアにコードを修正するための OSS を作ったので紹介します。 本記事では概要を紹介します。 公式ドキュメントを結構しっかり書いたつもりなので詳細はそちらに譲ります。 実現すること 主に業務で扱うプライベートリポジトリでチームで開発することを想定しています。 Public リポジトリでは autofix.ci を推奨します。 GitHub Actions で Pull Request のコードをセキュアに修正する 例: コードのフォーマット、コードからドキュメントの自動生成 コードを修正する GitHub Actions に修正に使われる GitHub App の Private Key を渡さない コードの修正が可能な GitHub App の悪用を防ぐ GitHub Actions で完結し、サーバーの運用などを必要としない 専用の action を

tfmv は以下のことをするシンプルなツールです。 リソース名の変更 リソースの参照の変更 moved block の生成 なお、ここでいうリソースは Terraform の以下のものを指します: resource data source module Remote State を参照したりしない静的なツールで事前に terraform init を実行したりする必要もありません。 リソース名を書き換えるロジック リソース名を書き換える方法として現在 3 つサポートしています。 多くの場合は --replace (-r) で十分かと思いますが、より柔軟な修正をしたい場合は正規表現や Jsonnet が使えます。 固定文字列の置換 --replace (-r) '<置換前の文字列>/<置換後の文字列>' マッチする文字列が全部置換されます。 正規表現による置換 --regexp '<正規表現

lock 機構を実現するための GitHub Action を作ったので紹介します。 背景 lock 機構によって複数のプロセスが同時に実行されるのを防ぐことが出来ます。 例えば GitHub Flow で Pull Request (以下 PR) をマージしたらデプロイを実行する場合に、デプロイ直前に lock を取り完了後に unlock することで、デプロイ中に他の PR がマージされてデプロイが複数同時に実行されるようなことを防ぐことが出来ます。 また、 Terraform で State の分割作業を行う際に、作業前に lock を取り完了後に unlock することで作業中に terraform plan, apply が実行されるのを防ぐことが出来ます。 今回は GitHub Actions で簡単に lock 機構を実現するための Action を開発しました。 特徴 今回

昨日自分の OSS の issue や pull request (以下 PR) を 1 つの GitHub Project に自動で集約して管理するようにしたお話を紹介しました。 昨日導入したばかりですが、今のところかなり良い感じに機能しています。 これを個人の OSS 開発だけに閉じるのはもったいなく、業務でも活用できるはずだと思いました。 今回の記事はその続きで、個人の OSS ではなく業務における開発組織の issue や PR を自動で GitHub Project に追加するようにするお話を紹介します。 やることは前回の記事とほぼ同じですが、皆さんが業務で活用するのをイメージしやすいように具体例を交えながらお話したいと思います。 最初は前回の記事に追記しようかと思いましたが、せっかく追記しても前回の記事のタイトル的に OSS を開発していない人には読んでもらえない可能性がある気

2024-07-24 追記: 本記事の続きで、開発組織でのソフトウェア開発の Issue や PR を自動で適切な GitHub Project に割り当てていく方法についても書きました。 https://zenn.dev/shunsuke_suzuki/articles/manage-enterprise-issue-pr-by-project タイトルの通り、自分が管理する全 OSS の Issue や Pull Request (以下 PR) を 1 つの GitHub Project に集約した話を紹介します。 自分は様々な OSS をメンテしており、様々なリポジトリで作られる GitHub Issues や PR を日々ハンドリングする必要があります。 しかしこれだけリポジトリの数が増えると一つ一つリポジトリを巡回してハンドリングしていくのは困難です。 ユーザーによって issu

GitHub Actions の timeout-minutes に関する lint rule 及び一括で timeout-minutes を設定するツールを作ったので紹介します。 timeout-minutes とは timeout-minutes は GitHub Actions の job 及び step (workflow は対応していないはず) の設定項目の一つで、 job 及び step のタイムアウトです。 timeout-minutes で設定した時間以内に job 及び step が完了しない場合に強制的に終了し失敗扱いになります。 デフォルトは 360 分です。 ただし、 reusable workflow を使っている job は timeout-minutes をサポートしていません。 なぜ timeout-minutes を設定すべきなのか デフォルトの 6 時間

Octo STS は GitHub Access Token をよりセキュアに発行する Security Token Service です。 GitHub App と GitHub Action が公開されています。 CI などの自動化で用いる GitHub Access Token の管理を改善することが出来ます。 Octo STS はまだ非常に若いプロジェクトなため実用には時期尚早かもしれませんが、今後の発展が楽しみなプロジェクトです。 公式ドキュメントがまだ整備されておらず、日本語情報も皆無なため、この本を執筆しました。 この本では Octo STS とは何か、なぜ Octo STS が必要なのか、現状 Octo STS にどういった課題があるのか、どうやって使うのか、どのような仕組みで動いているのか、などについて紹介します。

先日 DeNA 主催の CI/CD Test Night #7 というイベントで登壇しました。 自分は普段あまり登壇とかはせずに主に OSS の開発やブログの執筆という形でアウトプットをすることが多いのですが、自分がメンテしている OSS などでいつもお世話になっている @ponkio_o さんからお声がけいただき、登壇することとなりました。 貴重な機会をいただきありがとうございました。 本記事では自分の発表について紹介したいと思います。 自分は主に CI/CD のセキュリティ的なプラクティスや関連するツールの紹介をしました。 一つのことを掘り下げるというより、色々なトピックについて話をしました。 自分の発表の多くは自分が過去に書いたブログ記事に基づいています。 ブログ記事ではより詳しく解説していたりするので、是非そちらも参照してください。 Pull Request の CI の結果を P

危険な Terraform Provider の実行を防いで Security を担保するためのコマンドラインツールを作ったので紹介します。 # Only google provider and azurerm provider are allowed $ cat .tfprovidercheck.yaml providers: - name: registry.terraform.io/hashicorp/google version: ">= 4.0.0" - name: registry.terraform.io/hashicorp/azurerm # tfprovidercheck fails because aws provider is disallowed $ terraform version -json | tfprovidercheck FATA[0000] tfpro

本記事では GitHub Actions で pull_request event の代わりに pull_request_target を用い、 workflow の改竄を防いでより安全に CI を実行する方法について紹介します。 まずは前置きとして背景や解決したいセキュリティ的な課題について説明した後、 pull_request_target を用いた安全な CI の実行について紹介します。 本記事では OSS 開発とは違い業務で private repository を用いて複数人で開発を行うことを前提にします。 長いので要約 GitHub Actions で Workflow の改竄を防ぎたい GitHub の branch protection rule や codeowner, OIDC だけでは不十分なケースもある pull_request event の代わりに pull_r

aqua という CLI Version Manager の参考書です。 初心者の方は勿論、既に aqua を使っている人にも参考になる内容です。 aqua を人に勧めたり社内に導入・布教する際にも是非お使いください。

GitHub Actions の action と reusable workflow の version を commit hash で固定する CLI ツールの紹介です。 $ git diff diff --git a/.github/workflows/test.yaml b/.github/workflows/test.yaml index 84bd67a..5d92e44 100644 --- a/.github/workflows/test.yaml +++ b/.github/workflows/test.yaml @@ -113,17 +113,17 @@ jobs: needs: path-filter permissions: {} steps: - - uses: actions/checkout@83b7061638ee4956cf7545a6f7efe594e5a

tfaction という、 GitHub Actions で Terraform Workflow を構築するための Action を開発しています。 今回 tfaction が Terraform の Drift Detection をサポートしたので紹介します。 詳細に関しては公式ドキュメントを参照してください。 Drift Detection とは ここでいう Drift とは、 IaC においてコードによるインフラの定義と実際のインフラの状態が乖離していることを指し、 Drift Detection とはその Drift を検出することを指しています。 Terraform に限らず、 IaC において Drift Detection は重要なトピックです。 Drift が常態化しているとコードの信頼性がなくなります。 なにか変更を加える際にその変更と関係な差分が検出され、その変更が

本記事は Renovate の Pull Request を安全に自動マージするためのガイドです。 以下のドキュメントが元になっています。 この記事は一度書いたら後はメンテしませんが元のドキュメントはメンテしていくので、元のドキュメントも参照してください。 Renovate の導入は非常に簡単ですが、単に GitHub App をインストールしただけではその真価は発揮されません。 この記事では安全かつ自動で Renovate の Pull Request をマージし dependencies を常に最新に保つためのテクニックを紹介します。 この記事では CI に GitHub Actions を使うことを前提とします。また、 Renovate とは直接関係ない内容も含みます。 1. 概要 ある dependency を update する場合、その update に関連した test が

GitHub Actions の Workflow や Workflow 用のスクリプトの変更を防いでセキュリティを改善するための OSS を開発しているので紹介します。 背景 GitHub Actions は非常に便利ですが、 Workflow を書き換えて任意のコマンドを実行できるという、セキュリティ的なリスクがあります。 例えば GitHub Actions で Terraform を実行して AWS や GCP の IaC を実現している場合、 Workflow を書き換えて terraform destroy を実行して インフラを破壊するといったことが考えられます。 GitHub App が使われている場合、 Workflow を書き換えて GitHub App で悪意のある Pull Request を approve したり、はたまた GitHub App で Pull R

tfaction という、 GitHub Actions で良い感じの Terraform Workflow を構築するための Action を開発しています。 今回は tfaction の導入ガイドのようなものを書こうかと思います。 AWS Account が必要です。 執筆時点で tfaction の最新バージョンは v0.4.5 です。 2022-02-07 追記 Getting Started を作成しました。 README に従っていけば tfaction の workflow を動かして terraform を実行するのを体験できると思います。 IAM OpenID Connect provider の作成 IAM OpenID Connect provider を作成します。 data "tls_certificate" "github" { url = "https://t

tfaction という、 GitHub Actions で良い感じの Terraform Workflow を構築するための Action を開発しているので紹介します。 まだ開発中という感じで未成熟(個人の AWS, GCP アカウントを使って検証しているくらい)ですが、既にそれなりに動くはずです。 tfaction とは GitHub Actions で良い感じの Terraform Workflow を構築するための Action です。 単一の Action ではなく、複数の Action で構成されています。 ここで言う Terraform Workflow とは、 terraform plan や apply を実行する一連の流れのことを指しています。 この Workflow に求める要件は組織・チームによっても異なるでしょう。 そもそも apply の自動実行は危険だから手

e.g. github-comment で Envoy Proxy の設定の validation に失敗したら通知 github-comment というツールを使って GitHub の Pull Request (以下 PR) にコメントをして CI の結果を分かりやすくする方法について紹介します。 執筆時点で最新バージョンは v4.1.0 です。 github-comment とは github-comment は GitHub の commit, issue, PR にコメントをしたり、コメントを非表示にする CLI ツールです。 YAML の設定ファイルにコメントのテンプレートなどを記述し、それを元にコメントします。 シェルスクリプトとコメントのテンプレートを分離できるので、メンテナンス性が高いです。 3 つのサブコマンドがあります。 post: コメントをする exec: 指定し

Terraform の CI/CD を改善する tfcmt というツールを紹介します。 ちなみに HashiTalks JP 2021 でも紹介しています。 執筆時点で最新バージョンは以下のとおりです。 tfcmt: v3.0.0 github-comment: v4.0.1 tfnotify: v0.7.0 tfcmt は terraform plan, apply の結果を GitHub の Pull Request (以下 PR) にコメントとして通知する CLI ツールです。 態々 CI のログを見にいかなくても PR のページで結果を確認でき、 なおかつ素のログに比べて非常に分かりやすいのが特徴です。 tfnotify の Fork ですが、互換性はありません。 自分にとって不要な機能(主に GitHub 以外への通知)を削る代わりに、様々な改善を入れています。 GitHub 以

2022-10-07 追記 aqua v1.15.0 からは aqua g の -s option でバージョンを選択できるようになりました。 CLI ツールを YAML でバージョン管理できるツール aqua を開発しています。 aqua で CLI ツールを YAML でバージョン管理 も参照してください。 似たようなユースケースで使われる有名なツールとして asdf があります。 そこで、 aqua と asdf の違いについて書きたいと思います。 ちなみに aqua と asdf のバージョンは以下のとおりです。 asdf: v0.9.0 aqua: v0.8.2 aqua-registry: v0.11.0 ただし、自分は asdf にはあまり詳しくありません。 最近 aqua と比較するためにちょっと触っているくらいです。 また、自分は aqua の開発者であるため、どうしても

CLI ツールを YAML でバージョン管理できるツール aqua を開発しています。 先日(2021-11-27)、公式サイトを公開しました。 詳細は公式サイトをご参照ください。 この記事にコマンドやその実行結果、設定ファイルのサンプルなどを書いてもメンテが難しいため、 ここでは時間が経っても変わりにくい内容を書こうかと思います。 この記事の執筆時点で最新バージョンは v0.8.0 (Standard Registry は v0.10.13) です。 aqua は CLI ツールをインストールする CLI ツールです。 Go で書かれたシングルバイナリなので、簡単にインストールできます。 CLI ツールのインストールでいうと、 Homebrew などでインストールすることが多いかと思いますが、 aqua はインストールする CLI とそのバージョンを YAML で宣言的に定義するのが特徴