2026年5月5日に作成された Microsoft developer platform 関連の更新「Bump the external-dependencies group across 1 directory with 2 updates」は、アプリ本体やBusiness CentralのAPI仕様を変えるものではありません。結論から言うと、Microsoft/AL-GoリポジトリのGitHub Actionsワークフローで使われている外部依存関係を2件パッチ更新する変更です。対象は step-security/harden-runner と github/codeql-action で、CI/CDの実行環境保護とSARIFアップロード、CodeQL連携まわりを確認すべき更新です。(GitHub)
AL-Go for GitHubは、Business Central ALプロジェクト向けにCI/CD、テスト、デプロイなどのDevOpsプロセスを自動化するテンプレートとActionsのセットです。Microsoft Learnでも、AL-Goの最新ドキュメントはリポジトリ側で管理・更新されると案内されています。そのため、AL-Goを利用しているチームは「単なるDependabot PR」と見なすのではなく、自社リポジトリのワークフロー設定に同じ依存関係がないかを確認する価値があります。(Microsoft Learn)
Microsoft developer platformの更新内容：何が変わったのか
今回の更新は、/.github/workflows 配下にあるGitHub Actionsワークフローの uses: 参照を更新するものです。PRはDependabotによって2026年5月5日に作成され、2026年5月6日に main ブランチへマージされています。変更対象は1ディレクトリですが、実際には複数のワークフローファイル内で同じAction参照が更新されています。(GitHub)
| 更新対象 | 変更前 | 変更後 | 実務上の意味 |
|---|---|---|---|
step-security/harden-runner | v2.19.0 | v2.19.1 | GitHub Actionsランナーの監視・制御に関わるActionのパッチ更新 |
github/codeql-action/upload-sarif | v4.35.2 | v4.35.3 | SARIFアップロードとCodeQL関連処理のパッチ更新 |
| 対象ディレクトリ | /.github/workflows | 同左 | アプリコードではなくCI/CDワークフロー側の変更 |
| 更新種別 | SemVer patch | SemVer patch | 大きな仕様変更ではないが、セキュリティ・解析系のため動作確認は必要 |
特に注目すべき点は、ActionがタグだけではなくフルレングスのコミットSHAで固定されていることです。GitHubは、Actionを不変に近い形で使う方法としてフルレングスのコミットSHAへの固定を推奨しています。今回のPRも、バージョンコメントを併記しながらSHAを差し替える形になっており、サプライチェーンリスクを抑えつつ更新を追従する運用に近い形です。(GitHub Docs)
対応が必要な人と優先度
今回のMicrosoft developer platform更新で、すべての開発者がすぐにコードを変更する必要はありません。影響を受けるのは、主にAL-GoやGitHub Actionsのワークフロー管理に関わる人です。
| 対象者 | 対応優先度 | 確認すべきこと |
|---|---|---|
| AL-Goをフォーク、または自社テンプレート化しているチーム | 高 | .github/workflows 内のAction参照が古いSHAのまま残っていないか |
| Business Central向けにAL-Goテンプレートを使っている開発チーム | 中 | AL-Goシステムファイル更新後にCI、デプロイ、テストが通るか |
| GitHub Actionsのセキュリティ管理者 | 高 | harden-runner の監視対象ランナー、ubuntu-slim の利用有無 |
| CodeQL、SARIF、Scorecard分析を運用しているチーム | 中〜高 | upload-sarif 更新後にCode scanningへ結果が反映されるか |
| AL-Goを使っていない一般開発者 | 低 | 同じActionを自社ワークフローで使っている場合のみ確認 |
判断基準はシンプルです。step-security/harden-runner または github/codeql-action/upload-sarif を自社の .github/workflows で使っているなら確認対象です。使っていない場合、このPR自体による直接的な移行作業は基本的にありません。
step-security/harden-runner v2.19.1で確認すべき変更点
step-security/harden-runner は、GitHub Actionsの実行中にランナーの挙動を監視し、ネットワーク通信などの制御・可視化に使われるActionです。今回の v2.19.1 では、ubuntu-slim ランナーを早期に検出し、従来のように後続処理で chown: invalid user: 'undefined' のような失敗を起こすのではなく、情報ログを出して正常に終了する修正が入っています。(GitHub)
ただし、ここで誤解してはいけないのは、ubuntu-slim でもHarden-Runnerによる監視が可能になったわけではない点です。リリースノートでは、ubuntu-slim 上のジョブはHarden-Runnerで監視されないと明記されています。理由は、Harden-Runnerが必要とする低レベルのカーネル機能に、ubuntu-slim の実行環境が対応していないためです。(GitHub)
GitHub Docsでも、ubuntu-slim はコンテナ内で動作する単一CPUランナーであり、非特権モードのため、ファイルシステムのマウント、Docker-in-Docker、低レベルのカーネル機能など、昇格権限を必要とする操作はサポートされないと説明されています。つまり、セキュリティ監視を必須にしているワークフローでは、ubuntu-slim を安易に選ばない判断が必要です。(GitHub Docs)
harden-runner更新後の判断基準
| 状況 | 推奨対応 |
|---|---|
runs-on: ubuntu-latest や標準Ubuntu VMを使っている | 通常のCI実行ログを確認し、Harden Runnerステップが期待通り動作するか見る |
runs-on: ubuntu-slim を使っている | エラーが消えても「監視されている」と判断しない。監視必須ならランナーを変更する |
| セキュリティポリシーで全ジョブ監視が必須 | ubuntu-slim を許可しない運用ルールを検討する |
過去に chown: invalid user: 'undefined' が出ていた | v2.19.1で解消する可能性があるため、該当ワークフローを再実行して確認する |
github/codeql-action/upload-sarif v4.35.3で確認すべき変更点
github/codeql-action/upload-sarif は、SARIF形式の解析結果をGitHubのCode scanningへアップロードするためのActionです。今回の v4.35.3 では、古いCodeQLバージョンへの非推奨警告、プライベートレジストリ設定の改善、接続テスト方式の変更、診断ファイルが上書きされる不具合の修正、デフォルトCodeQL bundleの更新などが含まれています。(GitHub)
実務で特に見ておきたいのは、古いCodeQLバージョンを固定している環境です。リリースノートでは、CodeQL 2.19.3 以前の利用者に対する非推奨警告が追加され、これらのバージョンは今後のCodeQL Actionのマイナーリリースでサポートされなくなる予定と説明されています。GitHub Enterprise Serverや社内CIでCodeQL CLIのバージョンを明示的に固定している場合は、ワークフローだけでなくCLIやbundleの固定設定も確認してください。(GitHub)
また、CloudsmithやGCP OIDCを使ったプライベートレジストリ設定が受け入れられるようになった点、プライベートレジストリへの接続確認で HEAD ではなく GET を使うようになった点も、企業環境では重要です。社内プロキシ、NuGetフィード、プライベートパッケージ管理を使っている場合、これまで接続確認だけで失敗していたケースが改善する可能性があります。(GitHub)
SARIFアップロードで確認すべき設定
SARIFアップロードの失敗は、Actionのバージョンだけが原因とは限りません。GitHub Docsの例では、SARIFアップロードのワークフローに security-events: write が必要で、プライベートリポジトリでは actions: read と contents: read も示されています。更新後にCode scanningへ結果が出ない場合は、まず権限設定とGitHub Code Securityの有効化状態を確認してください。(GitHub Docs)
permissions:
security-events: write
actions: read
contents: read次のような症状があれば、upload-sarif のログを詳しく確認します。
| 症状 | 主な確認ポイント |
|---|---|
| SARIFアップロードが失敗する | permissions、GitHub Code Securityの有効化、SARIFファイルのパス |
| Code scanningに結果が表示されない | sarif_file の指定、category の重複、解析対象コミット |
| プライベートレジストリ連携で失敗する | OIDC設定、レジストリのエンドポイント、NuGet service index |
| 複数SARIFをアップロードして結果が上書きされる | category または runAutomationDetails.id の一意性 |
影響範囲：アプリコードではなくCI/CDとセキュリティ運用が中心
今回の変更は、Business CentralのALコード、アプリケーションロジック、公開APIを直接変えるものではありません。PRの差分は .github/workflows 配下のAction参照更新に集中しています。したがって、アプリの機能テストよりも、CI、E2E、PowerShell関連ワークフロー、Scorecard分析、SARIFアップロードの確認が重要です。(GitHub)
特に、次のワークフローを持つリポジトリでは確認を優先してください。
| ワークフローの種類 | 確認すべき理由 |
|---|---|
| CIワークフロー | harden-runner の起動・終了ログに変化が出る可能性がある |
| Deployワークフロー | デプロイ時に外部通信やシークレットを扱うため、ランナー保護の確認が重要 |
| E2Eワークフロー | 複数ジョブで同じActionを使う場合、1か所だけ更新漏れが起きやすい |
| PowerShell解析ワークフロー | SARIFアップロードが失敗するとCode scanningの可視化に影響する |
| Scorecard分析ワークフロー | サプライチェーンリスクの検知結果がCode scanningへ出るか確認が必要 |
移行・設定確認の手順
まず自社リポジトリで同じActionを使っているか確認する
最初にやるべきことは、.github/workflows 内の利用状況確認です。AL-Go本体のPRがマージされていても、自社リポジトリのワークフローがすぐに更新されるとは限りません。手元またはCI管理用ブランチで次のように検索します。
grep -R "step-security/harden-runner\|github/codeql-action/upload-sarif" .github/workflows検索結果に古いSHAや古いバージョンコメントが出た場合は、該当ワークフローを更新候補にします。GitHub Actionsの依存関係はDependency graphでも把握でき、ワークフロー内の uses: 参照、バージョン、SHAが依存関係として認識されます。(GitHub Docs)
SHA固定を維持したまま更新する
更新時にやってはいけないのは、確認を簡単にするために次のようなタグ指定へ戻すことです。
uses: step-security/[email protected]タグ指定は便利ですが、GitHubのセキュリティベストプラクティスでは、フルレングスのコミットSHA固定がより安全な選択肢とされています。今回のPRのように、SHAで固定し、同じ行に # v2.19.1 のようなコメントを残すと、可読性とサプライチェーン対策を両立しやすくなります。(GitHub Docs)
uses: step-security/harden-runner@a5ad31d6a139d249332a2605b85202e8c0b78450 # v2.19.1ubuntu-slimを使っていないか確認する
harden-runner の更新で最も見落としやすいのは、ubuntu-slim ではエラーが出なくなっても監視はされない点です。次のようにランナー指定を検索します。
grep -R "runs-on:.*ubuntu-slim" .github/workflows該当するジョブがあり、そのジョブでHarden-Runnerによる監視を期待している場合は、ubuntu-latest、明示的なUbuntu VM、larger runner、または適切に管理されたself-hosted runnerへの変更を検討します。軽量なIssue処理や短時間の自動化なら ubuntu-slim は選択肢になりますが、セキュリティ監視が必須のCI/CDには向きません。(GitHub Docs)
CodeQLとSARIFの結果を実行後に確認する
github/codeql-action/upload-sarif を更新した後は、ワークフローが成功したかだけでなく、Code scanningに結果が反映されているかを確認します。SARIFアップロードでは、ファイルパス、カテゴリ、権限、Code Securityの有効化状態が原因で失敗することがあります。(GitHub Docs)
確認の流れは次の通りです。
| 手順 | 確認内容 |
|---|---|
| ワークフローを手動またはPRで実行 | Upload SARIF ステップが成功しているか |
| ログを確認 | results.sarif のパスが正しいか、アップロードエラーがないか |
| GitHubのSecurityタブを確認 | Code scanning alertsに新しい結果が表示されるか |
| 複数解析がある場合 | category が重複していないか |
| 古いCodeQLを固定している場合 | CodeQL 2.19.3 以前を使っていないか |
Dependabot運用で再発を防ぐ
今回のPRはDependabotによるグループ更新です。Dependabotは、通常は依存関係ごとにPull Requestを作りますが、groups を使うと複数の依存関係更新を少ないPull Requestにまとめられます。GitHub Actions向けのDependabot設定では、directory: "/" を指定すると /.github/workflows などが検索対象になります。(GitHub Docs)
自社リポジトリでも同様の運用をしたい場合は、既存の .github/dependabot.yml と重複しないようにしたうえで、次のような設定を検討できます。
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
groups:
external-dependencies:
patterns:
- "step-security/harden-runner"
- "github/codeql-action"
update-types:
- "patch"
- "minor"この設定は一例です。セキュリティ関連Actionはパッチ更新だけ自動グループ化し、メジャー更新は個別レビューにするなど、組織の変更管理ルールに合わせて調整してください。重要なのは、Dependabot PRを「自動で出す」だけで終わらせず、ワークフロー実行、差分確認、依存関係レビューまで運用に含めることです。
よくある失敗と回避策
エラーが消えたのでHarden-Runnerが監視していると判断する
ubuntu-slim では、v2.19.1によりHarden-Runnerがきれいに終了する可能性があります。しかし、それは監視が成功したという意味ではありません。セキュリティ監視が必要なジョブでは、ランナー種別そのものを見直す必要があります。(GitHub)
パッチ更新だからテストせずにマージする
今回の更新はSemVer上はパッチですが、対象はCI/CDのセキュリティと解析結果アップロードに関わるActionです。アプリのビルドが通るだけでは不十分で、Harden Runnerログ、SARIFアップロード、Code scanning反映まで確認するべきです。
SHA固定をタグ指定に戻してしまう
タグ指定は見やすい一方で、タグが移動された場合に意図しないコードを実行するリスクがあります。フルレングスSHA固定とバージョンコメントの併記を維持すると、セキュリティとメンテナンス性のバランスを取りやすくなります。(GitHub Docs)
SARIFアップロード失敗をAction更新だけの問題と考える
upload-sarif の失敗は、権限不足、GitHub Code Securityの未有効化、SARIFファイルパスの誤り、カテゴリ重複などでも起きます。Actionを戻す前に、permissions とSecurityタブの設定を確認してください。(GitHub Docs)
今回の更新で取るべき次の行動
今回のMicrosoft developer platform更新は、AL-Goを使う開発者にとって「アプリの移行」ではなく「GitHub Actionsワークフローの健全性確認」です。まず .github/workflows を検索し、step-security/harden-runner と github/codeql-action/upload-sarif の利用有無を確認してください。次に、SHA固定を維持したまま更新し、ubuntu-slim の利用有無、Harden Runnerのログ、SARIFアップロード結果、Code scanningへの反映を確認します。
特にセキュリティ監視やCode scanningを開発プロセスの品質ゲートにしているチームでは、今回の変更を「Dependabotの自動更新」で終わらせず、CI/CD設定の棚卸しとして扱うのが安全です。AL-Goの更新を取り込む前に、ステージング用ブランチでワークフローを実行し、問題がないことを確認してから本番ブランチへ反映しましょう。
コメント