Microsoft Security DevOps GitHub actionを使うと、GitHub ActionsのCI内でコード、IaC、コンテナーなどの静的分析を実行し、その結果をMicrosoft Defender for CloudのDevOps Securityに集約できます。結論から言うと、2026年5月29日前後の公式更新で管理者が最初に見るべきポイントは、GitHubリポジトリの接続状態、Workflow権限、id-token: write、スキャン対象、SARIFアップロードの扱いです。新しいツールを入れるだけではなく、「検出結果を誰が、どこで、どう直すか」まで運用に落とし込むことが重要です。
Microsoft Security DevOpsは、開発ライフサイクルに静的分析ツールを組み込むためのコマンドラインアプリケーションで、Bandit、BinSkim、Checkov、ESLint、Template Analyzer、Terrascan、TrivyなどをGitHub Actionsから実行できます。Microsoft Learnでは、GitHubリポジトリをDefender for Cloudに接続したうえで、ワークフロー権限をRead and Writeにし、Defender for Cloudとのフェデレーション用にid-token: writeを設定することが前提条件として示されています。(Microsoft Learn)
Microsoft Defenderのセキュリティ更新で押さえるべきポイント
今回の「Configure the Microsoft Security DevOps GitHub action」は、Microsoft Defender for CloudのDevOps SecurityをGitHub Actionsに組み込むための設定手順です。公式の原稿メタデータではms.date: 05/28/2026に更新され、GitHub上の履歴でも2026年5月28日の複数コミットが確認できます。日本時間やローカライズ反映のタイミングを含め、2026年5月29日前後に確認すべき公式更新として扱うのが実務上は自然です。(GitHub)
| 観点 | 変更・確認ポイント | 管理者・開発者への影響 |
|---|---|---|
| ドキュメントの鮮度 | 2026年5月末時点の手順として更新 | 古いワークフローを使っているリポジトリは、現行サンプルとの差分確認が必要 |
| 権限設定 | contents: read、id-token: write、actions: read、必要に応じてsecurity-events: writeを明示 | 権限不足だとDefender for Cloud連携やGitHub Securityタブへの反映でつまずきやすい |
| スキャン結果の確認先 | Defender for Cloud > DevOps Securityで確認 | 開発者のCIログだけでなく、セキュリティ管理者もAzure側で横断的に確認できる |
| GitHub Advanced Security連携 | GitHub Securityタブに結果を出す場合はSARIFアップロードとGHAS要件を確認 | GHASがない環境で「Securityタブに出ない」と誤解しやすい |
| スキャン対象の絞り込み | categories、languages、toolsで調整可能 | モノレポや大規模リポジトリでは実行時間とノイズを抑えられる |
重要なのは、今回の更新履歴から「既存ワークフローを直ちに破壊する変更」が読み取れるわけではない点です。実務上の焦点は、古い設定のまま動かしているGitHub Actionsが、現在のDefender for Cloud連携要件を満たしているかを点検することです。
Microsoft Security DevOps GitHub actionでできること
Microsoft Security DevOps GitHub actionは、GitHub Actions上でMicrosoft Security DevOps CLIを実行し、セキュリティ分析ツールのインストール、ポリシー取得、ツール実行、SARIF形式への結果正規化などを行います。GitHub Marketplace側の説明でも、SARIFへの正規化やビルドブレークなどが機能として説明されています。(GitHub)
主なスキャン領域は次のとおりです。
| 分析対象 | 主なツール例 | 使いどころ |
|---|---|---|
| Pythonコード | Bandit | Pythonアプリの危険な実装やセキュリティ上の問題を早期検出 |
| バイナリ | BinSkim | Windows/ELFバイナリの安全性確認 |
| IaC | Checkov、Template Analyzer、Terrascan | Terraform、Bicep、ARM、Kubernetes YAMLなどの設定ミス検出 |
| JavaScript | ESLint | JavaScriptコードの品質・セキュリティ観点のチェック |
| コンテナー・IaC | Trivy | コンテナーイメージやIaCの脆弱性・設定不備チェック |
| マルウェア | AntiMalware | windows-latestエージェントで既定スキャンされ、マルウェア検出時にビルドを中断 |
セキュリティ担当者にとっての価値は、CI/CDの中で検出した問題をDefender for CloudのDevOps Securityに集め、リポジトリ単位・重大度単位で見られることです。開発者にとっては、レビュー後や本番直前ではなく、pushやPRの段階で修正対象を把握できる点が大きなメリットです。
影響範囲：対象になる環境とならない環境
影響を受けるのは、主にGitHubリポジトリをDefender for Cloudに接続し、GitHub Actionsでmicrosoft/security-devops-actionを実行している、または今後導入する環境です。Defender for CloudのDevOps SecurityはAzure DevOps、GitHub、GitLabを扱えますが、この手順はGitHub Actions向けです。(Microsoft Learn)
| 対象者 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| Azure管理者 | Defender for Cloudの環境設定にGitHubコネクタがあるか | リポジトリがAzure側のDevOps Securityに表示されない |
| GitHub Organization Owner | Defender for Cloud GitHubアプリのインストール範囲 | 一部リポジトリだけスキャン・可視化から漏れる |
| リポジトリ管理者 | .github/workflows/配下のMSDOワークフロー | 権限不足、スキャン未実行、結果未反映が起きる |
| 開発者 | CIログと検出結果の修正フロー | 検出されても誰が直すか曖昧になる |
| セキュリティ運用担当 | Defender for Cloud > DevOps Securityの確認手順 | リポジトリ横断のリスク優先度付けができない |
| GHAS利用組織 | SARIFアップロードとSecurityタブ反映 | GitHub側のCode scanning alertsに出ないと誤認する |
GitHub環境をDefender for Cloudに接続するには、GitHub Organization OwnerやAzure側のContributorなど、一定の権限が必要です。また、オンボード後にDevOpsリソースがInventoryやDevOps securityページに表示されるまで最大8時間かかる場合があるため、設定直後に表示されないだけで失敗と判断しないことも重要です。(Microsoft Learn)
管理者が先に確認すべき設定チェックリスト
導入や見直しでは、まず「ワークフローが動くか」ではなく、「Defender for Cloudに正しくつながり、権限が過剰でも不足でもないか」を確認します。
| 確認項目 | 判断基準 | 実務上の注意点 |
|---|---|---|
| GitHubコネクタ | Defender for CloudのEnvironment settingsにGitHub接続がある | 組織単位で接続されているか、一部リポジトリだけかを確認 |
| GitHubアプリの範囲 | 保護対象リポジトリにDefender for Cloud GitHubアプリが入っている | 新規リポジトリが自動対象になる設定かも見る |
| Workflow権限 | Read and Writeが有効で、YAMLにid-token: writeがある | リポジトリ設定とワークフロー内permissionsの両方を見る |
| SARIFアップロード | GitHub Securityタブに出すならsecurity-events: writeを設定 | GHAS要件とライセンスを事前に確認 |
| 実行ブランチ | mainだけで十分か、PRでも検査するか | Public repoのフォークPRでは権限設計に注意 |
| 実行エージェント | windows-latestまたはLinuxエージェントを選択 | AntiMalwareの既定スキャンはwindows-latest前提 |
| スキャン範囲 | categories、languages、toolsで過不足がない | 全ツール実行はモノレポで時間・ノイズが増えやすい |
| 結果確認 | Azure側のDevOps Securityで確認できる | CIログだけを正式な確認先にしない |
GitHub Actionsの基本構成例
公式サンプルの要点は、ワークフローに必要なpermissionsを明示し、microsoft/security-devops-action@latestを実行することです。GitHub Securityタブに結果を表示したい場合は、github/codeql-action/upload-sarif@v3でMSDOのSARIFファイルをアップロードします。公式手順では、GitHub Securityタブへの表示にはGitHub Advanced Securityが必要と説明されています。(Microsoft Learn)
name: MSDO
on:
push:
branches:
- main
jobs:
sample:
name: Microsoft Security DevOps
runs-on: windows-latest
permissions:
contents: read
id-token: write
actions: read
security-events: write
steps:
- uses: actions/checkout@v3
- name: Run Microsoft Security DevOps
uses: microsoft/security-devops-action@latest
id: msdo
- name: Upload alerts to Security tab
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: ${{ steps.msdo.outputs.sarifFile }}このまま使う場合でも、組織のGitHub Actionsセキュリティ基準に合わせた調整は必要です。たとえば、公式サンプルは@latestを使っていますが、変更管理を厳格にしたい組織では、検証済みのタグやコミットSHAに固定する運用を検討します。GitHub Docsでは、Actionを完全なコミットSHAにピン留めすることが、Actionを不変のリリースとして使う唯一の方法だと説明されています。(GitHub Docs)
スキャン対象を絞る設定の考え方
Microsoft Security DevOps GitHub actionは、withでスキャンの範囲を調整できます。小規模リポジトリでは既定値で始めてもよいですが、大規模リポジトリやモノレポでは、最初から全スキャンを有効にするとCI時間が伸び、開発者が警告を無視しやすくなります。
| パラメーター | 役割 | 使う判断基準 |
|---|---|---|
config | .gdnconfigなどのMSDO設定ファイルを指定 | 組織標準のルールや例外管理を使う場合 |
policy | GitHub、microsoft、noneなどの既知ポリシーを指定 | まず標準ポリシーで始め、必要に応じて調整 |
categories | code、artifacts、IaC、containersを指定 | IaCリポジトリならIaC、コンテナー中心ならcontainersを優先 |
languages | 分析対象言語を指定 | JavaScript/TypeScriptなど、対象が明確な場合に絞る |
tools | 実行するアナライザーを指定 | ノイズが多いツールを一時的に外す、または特定ツールだけ検証する場合 |
実務では、最初に「検出できる最大範囲」を狙うより、開発チームが修正できる粒度に絞る方が定着しやすくなります。たとえばTerraform中心のインフラリポジトリなら、最初はcategories: IaCから始め、検出結果の棚卸し後にコンテナーやコード分析へ広げる方が現実的です。
展開・移行時の進め方
既存環境に導入する場合は、全リポジトリへ一括展開するより、リスクが高く運用協力を得やすいリポジトリから段階的に進めます。
- GitHub組織とリポジトリを棚卸しする
Defender for Cloudに接続済みのGitHub組織、保護対象リポジトリ、既存の.github/workflows/を確認します。 - 既存ワークフローとの差分を確認する
microsoft/security-devops-actionの有無、permissions、runs-on、SARIFアップロード、実行ブランチを比較します。 - パイロット対象を決める
本番影響が比較的小さく、IaCやコンテナーなど検出価値が高いリポジトリを選びます。 - まずは結果確認を優先する
初期段階からビルド失敗を厳しくしすぎると、開発チームが回避策を探し始めます。最初は結果の妥当性、重複、誤検知、修正担当を確認します。 - 重大度ごとの対応基準を決める
Critical/Highは期限付きで修正、Mediumはスプリント内で判断、Lowはバックログ化など、運用ルールを明文化します。 - Defender for Cloud側で横断確認する
DevOps Securityでリポジトリ別、重大度別、検出種別別に確認し、CIログだけに依存しない運用にします。 - 自動化と例外管理を整える
継続運用では.gdnconfigや組織標準テンプレートを使い、例外を個別リポジトリの暗黙ルールにしないことが重要です。
よくある失敗と回避策
| 失敗しやすいポイント | 症状 | 回避策 |
|---|---|---|
id-token: writeを入れていない | Defender for Cloudとの連携やフェデレーションで問題が起きる | サンプルどおりpermissionsに明示する |
| GitHubのWorkflow permissionsがRead only | SARIFアップロードやSecurityタブ反映が失敗する | リポジトリ設定でRead and Writeを確認 |
| GHASなしでSecurityタブ表示を期待する | CIは動くがGitHub側のCode scanning alertsに出ない | Defender for Cloud側のDevOps Security確認とGHAS要件を切り分ける |
| 全ツールを一括実行する | CI時間が伸び、警告が多すぎて運用されない | categoriesやtoolsで段階導入する |
@latestを無検証で本番適用する | Action側の変更が意図せず入る | 本番環境では検証済み参照に固定する運用を検討 |
| Azure側にすぐ表示されない | 設定失敗と誤認して再作業する | オンボード後の反映時間を考慮し、最大8時間程度は確認時間を置く |
| 修正責任者が決まっていない | 検出だけ増え、改善が進まない | リポジトリオーナー、期限、例外承認者を決める |
GitHub Advanced Securityとの関係を誤解しない
Microsoft Security DevOps GitHub actionは、GitHub Actions上でセキュリティ分析を実行し、Defender for Cloud側で結果を確認するための重要な部品です。一方、GitHubのSecurityタブにCode scanning alertsとして表示するには、SARIFアップロードの設定やGitHub Advanced Securityの利用条件が関係します。
つまり、次のように整理すると混乱しにくくなります。
| やりたいこと | 主に必要なもの |
|---|---|
| GitHub ActionsでMSDOを実行する | microsoft/security-devops-action |
| Defender for Cloudで結果を横断確認する | GitHubコネクタ、DevOps Security |
| GitHub Securityタブに結果を表示する | SARIFアップロード、security-events: write、GHAS要件の確認 |
| 組織全体のリスクを優先度付けする | Defender CSPMやDevOps Securityの運用設計 |
特に管理者は、「CIでスキャンが成功した」ことと「セキュリティ運用に必要な場所へ結果が集約された」ことを分けて確認する必要があります。前者だけでは、開発者個人のログに検出結果が閉じてしまい、組織としてのリスク管理につながりません。
管理者と開発者で役割を分ける
Microsoft Defender for CloudとGitHub Actionsの連携は、セキュリティ部門だけでも開発部門だけでも定着しません。導入前に役割を分けておくと、検出後の対応が進みやすくなります。
| 役割 | 担当すること |
|---|---|
| Azure管理者 | Defender for Cloudの有効化、GitHubコネクタ、権限設計 |
| GitHub管理者 | GitHubアプリのインストール、Workflow permissions、Actionsポリシー |
| セキュリティ担当 | 検出ルール、重大度基準、例外承認、横断レビュー |
| 開発リード | 修正優先度、スプリントへの組み込み、誤検知のフィードバック |
| リポジトリオーナー | ワークフローの保守、スキャン対象の調整、CI失敗時の一次対応 |
この役割分担がないまま導入すると、「セキュリティチームは検出しただけ」「開発チームは何を直せばよいか分からない」という状態になりがちです。MSDOの導入はツール設定ではなく、DevSecOpsの運用設計として扱うべきです。
まず実施すべき次のアクション
Microsoft Security DevOps GitHub actionを使う環境では、まず既存ワークフローを確認し、現在の公式サンプルに含まれるpermissionsと結果確認先を満たしているかを点検します。次に、スキャン対象をリポジトリ特性に合わせて絞り、Defender for Cloud > DevOps Securityで検出結果を横断的に確認できる状態にします。
最初の作業としては、次の順番が現実的です。
- Defender for CloudにGitHub組織が接続されているか確認する。
- 対象リポジトリの
.github/workflows/にMSDOワークフローがあるか確認する。 id-token: write、contents: read、actions: read、必要に応じてsecurity-events: writeを確認する。- 小規模なリポジトリで実行し、CIログとDefender for Cloud側の表示を照合する。
- 検出結果の修正ルールを決めてから、対象リポジトリを広げる。
Microsoft Defender for CloudのGitHub action連携は、設定すれば終わりではありません。スキャン結果を開発者が直せる形に整理し、管理者が横断的に見られる状態にして初めて、セキュリティ更新の効果が出ます。まずは権限、接続、スキャン範囲、結果表示の4点を確認し、段階的に展開してください。
コメント