Microsoft developer platform documentation update: Bump the actions group across 1 directory with 3 updatesで最初に押さえるべき点は、アプリケーション本体の仕様変更ではなく、Microsoftのbpf_performanceリポジトリにあるGitHub Actionsワークフローの依存関係更新だということです。対象はstep-security/harden-runner、actions/upload-artifact、github/codeql-actionの3つで、CI/CD、セキュリティ監査、成果物アップロード、CodeQL解析に影響します。(GitHub)
対応の結論はシンプルです。GitHub Actionsを運用している担当者は、DependabotのPRをそのままマージする前に、すべてのワークフロー実行結果、Artifactの保存結果、CodeQLの警告、Harden Runnerのログを確認してください。特に2026年5月5日時点で確認するなら、このPRが指している更新先が各Actionの最新リリースと一致しているかも見直すべきです。(GitHub)
今回の更新は何が変わるのか
今回のPull Request #246は、Dependabotが作成した「actions」グループの一括更新です。PR本文では、ルートディレクトリ配下のGitHub Actions依存関係として、3つのActionが更新対象になっています。step-security/harden-runnerは2.16.0から2.17.0、actions/upload-artifactは7.0.0から7.0.1、github/codeql-actionは4.34.0から4.35.1へ更新されます。(GitHub)
変更ファイルは.github/workflows配下の7つです。具体的にはBuild.yml、CICD.yml、Test.yml、UploadPerfResults.yml、codeql-analysis.yml、dependency-review.yml、scorecards.ymlが対象で、差分は全体で14行追加・14行削除です。つまり、ソースコードのロジック変更ではなく、CI/CDで使うActionの参照先SHAを差し替える更新です。(GitHub)
| 更新対象 | 変更内容 | 影響しやすい領域 | まず確認すること |
|---|---|---|---|
step-security/harden-runner | 2.16.0 → 2.17.0 | ランナーの実行時監視、egress監査、セキュリティポリシー | egress-policy: auditのログ、許可すべき通信先、Policy Store利用有無 |
actions/upload-artifact | 7.0.0 → 7.0.1 | ビルド成果物、テスト結果、SARIFファイルのアップロード | Artifact名、保存パス、空ファイルになっていないか、後続ジョブで取得できるか |
github/codeql-action | 4.34.0 → 4.35.1 | CodeQL解析、Code scanning、セキュリティアラート | Gitバージョン、CodeQLの警告、解析時間、アラート件数の変化 |
対応すべき人と影響範囲
この更新で最も対応が必要なのは、Microsoft developer platform関連のリポジトリでGitHub Actionsを管理している開発者、DevOps担当者、セキュリティ担当者です。PRはワークフロー定義の更新なので、アプリの利用者や通常の機能開発だけを担当する開発者には直接の仕様変更はありません。
ただし、CIが失敗するとリリースやPull Requestのマージが止まります。特に以下のようなチームは、影響範囲を広めに見ておく必要があります。
- GitHub Actionsの必須チェックをBranch protectionやRulesetsで有効にしている
- CodeQLやDependency Reviewの結果をマージ条件にしている
- ビルド成果物やテスト結果をArtifactとして後続ジョブで利用している
- Harden Runnerでワークフローの外向き通信を監査している
- self-hosted runnerや古いGit環境を使っている
GitHubのDependency Reviewは、Pull Request内の依存関係変更を確認し、既知の脆弱性を含む依存関係が追加された場合にエラーを出せます。必須チェックにしている場合、依存関係レビューの失敗はマージ停止につながるため、今回のようなDependabot更新でも軽視しないほうが安全です。(GitHub Docs)
step-security/harden-runner更新で確認すべきこと
step-security/harden-runnerのv2.17.0では、Policy Store Supportが追加されています。リリースノートによると、use-policy-storeとapi-key入力を使ってStepSecurity Policy Storeからセキュリティポリシーを取得でき、ポリシーはworkflow、repo、org、clusterレベルで定義できます。より細かい単位のポリシーが優先され、ポリシーが見つからない場合はaudit modeになると説明されています。(GitHub)
今回の差分では、既存ワークフロー内のegress-policy: auditが維持されています。つまり、直ちにブロックモードへ移行する更新ではありません。ただし、Harden RunnerはCI/CDの通信可視化やサプライチェーン対策に関わるため、マージ前にログを確認し、意図しない外向き通信が増えていないかを見ておくべきです。
確認の観点は次の通りです。
| 確認項目 | 見るべき内容 | 問題がある場合の対応 |
|---|---|---|
| egressログ | ビルド中の外向き通信先が想定範囲か | 不明なドメインやIPを調査し、必要なら許可リストや依存関係を見直す |
| audit mode | 監査のみで実行されているか | ブロック運用へ移行する前に、誤検知を洗い出す |
| Policy Store | use-policy-storeを使う予定があるか | 既存のpolicy入力や権限設計と重複しないよう段階導入する |
| runner種別 | GitHub-hostedかself-hostedか | self-hostedの場合はネットワーク、権限、監視対象を事前確認する |
2026年5月5日時点で見ると、Harden Runnerのリリースページにはv2.19.1も公開されています。PR #246はv2.17.0への更新なので、マージ前にDependabot PRをrebaseまたはrecreateして、より新しい更新を取り込むべきか判断する余地があります。(GitHub)
actions/upload-artifact更新で確認すべきこと
actions/upload-artifactは、ビルド成果物、テスト結果、プロファイル結果、SARIFファイルなどをGitHub Actions上に保存するためのActionです。今回の更新は7.0.0から7.0.1へのパッチ更新で、リリースノートではREADMEのdirect upload関連更新、v7向けサンプル更新、typespec/ts-http-runtime 0.3.5関連の変更が挙げられています。(GitHub)
今回のPRでは、Build.yml、Test.yml、scorecards.ymlなどでactions/upload-artifactの参照SHAが更新されています。Test.ymlではCSV結果やcommit_sha.txt、プロファイル関連ファイルがArtifactとしてアップロードされ、scorecards.ymlではresults.sarifがアップロード対象になっています。(GitHub)
実務では、Actionの更新そのものよりも「アップロードされた成果物を後続工程が正しく使えるか」が重要です。たとえば、テスト結果CSVを別ジョブで集計している、SARIFをCode scanningへ渡している、リリース前にビルドArtifactを人が確認している、といった運用では、アップロードが成功していてもファイル名や中身が期待通りか確認する必要があります。
マージ前に確認すべきポイントは次の3つです。
- Artifact一覧に期待した名前が表示されるか
- アップロード対象パスが空になっていないか
- 後続ジョブや手動ダウンロードで同じ形式のファイルを取得できるか
v7系ではdirect uploadなどの仕様にも触れられていますが、今回の差分だけを見る限り、archive: falseのような新しい入力を追加する変更ではありません。既存のpath、name、retention-daysの挙動が変わっていないかを中心に確認するとよいでしょう。(GitHub)
github/codeql-action更新で確認すべきこと
github/codeql-actionは、CodeQL解析やSARIFアップロードに関わる重要なActionです。今回のPRでは、codeql-analysis.ymlのinitとanalyze、scorecards.ymlのupload-sarifで参照SHAが更新されています。PR本文では4.34.0から4.35.1への更新とされています。(GitHub)
v4.35.1のリリースノートでは、improved incremental analysisに必要なGitバージョンの記載誤りが修正され、正しくは2.36.0であると説明されています。v4.35.0では、既定のCodeQL bundleが2.25.1へ更新されています。(GitHub)
GitHub-hosted runnerを使っている場合は大きな問題になりにくい一方、self-hosted runnerで古いGitを使っている環境では、CodeQL解析の警告や失敗が出る可能性があります。特にサブモジュールを含むリポジトリ、プライベートレジストリ連携、独自のCodeQL設定を持つ環境では、ログを流し読みせず、警告行を確認してください。
また、今回の差分には見落としやすい点があります。codeql-analysis.ymlやscorecards.ymlでは参照SHAがc10b806...へ更新されている一方、行末コメントに# v3.29.5のような古いバージョン表記が残っている箇所があります。依存関係としてはPR本文の4.35.1が更新対象ですが、レビュー担当者が誤解しやすいため、可能であればコメントも実際の参照先に合わせて修正しておくと安全です。(GitHub)
2026年5月5日時点の確認では、CodeQL Actionのリリースページにv4.35.3が公開されています。PR #246はv4.35.1を指しているため、CIが通っても「最新まで上げるか」「このPRでは最小限の更新に留めるか」をチームで判断してください。(GitHub)
SHA固定は良いが、レビューを省略してよいわけではない
今回の差分では、Actionを@v4のようなタグではなく、長いコミットSHAで参照しています。これはサプライチェーン対策として望ましい運用です。GitHub Docsでも、ActionをフルレングスのコミットSHAに固定することが、現時点でActionをimmutable releaseとして使う唯一の方法だと説明されています。(GitHub Docs)
ただし、SHA固定には「安全だから何も見なくてよい」という意味はありません。むしろ、固定したSHAが本当に期待するActionのリポジトリ由来か、リリースノートと一致するか、古いコメントやドキュメント表記が残っていないかを確認する必要があります。
確認用のコマンド例は次の通りです。
grep -R "harden-runner\|upload-artifact\|codeql-action" .github/workflowsこの結果を見て、uses:の参照先、行末コメント、同じActionの複数箇所更新漏れを確認します。大規模なリポジトリでは、Dependabotのグループ更新によって複数ワークフローが同時に変わるため、1ファイルだけ見て判断しないことが重要です。
マージ前の実務チェックリスト
この更新はDependabotによる依存関係更新ですが、CI/CD基盤に触れるため、通常のライブラリアップデートより慎重に扱うべきです。以下の順番で確認すると、失敗原因を切り分けやすくなります。
| 手順 | 確認内容 | 合格ライン |
| -: | —————————- | ————————- |
| 1 | PR差分で変更されたActionとSHAを確認する | 3つのActionだけが意図通り更新されている |
| 2 | 7つの対象ワークフローをすべて実行する | 必須チェックがすべて成功している |
| 3 | Harden Runnerのログを確認する | 監査ログに不審な通信や新しい失敗がない |
| 4 | Artifactをダウンロードして確認する | ファイル名、拡張子、中身、保存期間が従来通り |
| 5 | CodeQLのログとCode scanning結果を見る | 新しい重大警告や解析失敗がない |
| 6 | Dependency Reviewを確認する | 既知の脆弱性やライセンス違反でブロックされていない |
| 7 | コメントとドキュメント表記を整える | SHAとバージョン説明が矛盾していない |
特にBranch protectionでCodeQL、Dependency Review、CI/CDを必須チェックにしている場合、ひとつのチェック失敗がマージ停止につながります。依存関係更新PRだからといって、自動マージだけに任せず、失敗時にどのActionが原因か分かる状態にしておきましょう。
そのままマージしてよいケース、見送るべきケース
| 判断 | 状況 | 推奨対応 |
|---|---|---|
| そのままマージしやすい | 全ワークフローが成功し、ArtifactとCodeQL結果に差分がない | 通常レビュー後にマージ |
| rebaseまたは再作成を検討 | PR作成後に対象Actionの新しいリリースが出ている | Dependabot PRを最新化してから再テスト |
| 一時保留 | CodeQL、Artifact、Harden Runnerのいずれかで新しい失敗がある | 失敗したAction単位で切り分け |
| 修正してからマージ | 行末コメントや内部ドキュメントのバージョン表記が古い | コメントを実際のSHA・バージョンに合わせる |
| 見送り | self-hosted runnerのGitや権限要件を満たせない | runner更新や設定変更を先に実施 |
今回のような「actions group」の更新は、複数のActionをまとめて更新できる一方で、失敗した場合に原因が分かりにくくなります。CIが赤くなったときは、harden-runner、upload-artifact、codeql-actionを個別に戻して再実行し、どの更新で変化が出たかを切り分けると早く解決できます。
自社リポジトリで同様の更新に備えるポイント
Microsoft developer platform関連のリポジトリに限らず、GitHub Actionsを使う開発組織では、今回の更新から次の運用を見直す価値があります。
まず、Actionの参照はできるだけフルコミットSHAで固定します。次に、行末コメントやREADMEにバージョンを書く場合は、Dependabot更新時に一緒に更新される運用にします。最後に、Dependabotのグループ更新を有効にしている場合でも、セキュリティ系ActionとArtifact系Actionはレビュー観点を分けるべきです。
たとえば、upload-artifactの更新では「成果物が保存できたか」が中心ですが、codeql-actionでは「解析結果が変わっていないか」、harden-runnerでは「通信監査やポリシーが意図通りか」が中心になります。同じDependabot PRに含まれていても、確認すべきログは異なります。
次に取るべき行動
この更新を確認する担当者は、まず.github/workflows配下で3つのActionの参照箇所を検索し、PR #246の差分と一致しているか確認してください。そのうえで、Build、Test、CodeQL、Dependency Review、Scorecards、Artifactアップロードを含むワークフローを一通り実行します。
CIがすべて成功しても、CodeQLの警告、Harden Runnerの監査ログ、Artifactの中身までは確認しておくべきです。2026年5月5日時点では、PRが指すバージョンより新しいHarden RunnerやCodeQL Actionのリリースも確認できるため、急いでマージするより、最新化の要否を判断してから取り込むほうが安全です。(GitHub)
今回の更新は小さな差分に見えますが、CI/CDの信頼性とサプライチェーンセキュリティに関わる変更です。マージ前に「ワークフローが通るか」だけでなく、「何が監査され、何が保存され、どの解析結果が変わったか」まで確認しておくことで、後続の開発やリリース作業を安定させられます。
コメント