今回のMicrosoft Defenderのセキュリティ更新でまず確認すべき点は、マルウェア検知エンジンやエンドポイント保護ポリシーの変更ではなく、SARIFログの検証・最適化に関する更新であることです。2026年5月21日に確認された公式情報では、SARIF2004.OptimizeFileSizeが、SARIF内のindex、ruleIndex、parentIndexに明示的な-1を出力しているケースを「ログサイズを不必要に増やす要素」として警告できるよう拡張されています。PR自体はmicrosoft/sarif-sdkの#2913として2026年5月20日にmainへマージされています。(GitHub)
Microsoft Defender for Cloud、Microsoft Security DevOps、Azure DevOps、GitHub Advanced SecurityなどでSARIFを扱っている管理者や開発者は、CI/CDで生成・公開しているSARIFファイルに"index": -1、"ruleIndex": -1、"parentIndex": -1が含まれていないかを確認するのが最初の対応です。Microsoft Defender for Endpointだけを通常利用しており、SARIFログを生成・アップロードしていない環境では、今回の変更による直接的な設定変更は基本的にありません。
Microsoft Defenderのセキュリティ更新で押さえるべき結論
今回の更新は、Microsoft Defenderの検知能力そのものを変える更新ではなく、セキュリティスキャン結果をやり取りするSARIFファイルの品質改善に関するものです。SARIFは静的解析結果を表現するJSONベースの形式で、MicrosoftのMSVCコンパイラも診断結果をSARIFとして出力できます。(Microsoft Learn)
| 確認項目 | 内容 | 対応の優先度 |
|---|---|---|
| 変更対象 | SARIF2004.OptimizeFileSizeの検証ルール | SARIFを扱う環境では中〜高 |
| 主な変更 | 明示的に出力された-1のインデックス値をログ肥大化として警告 | 高 |
| 影響する可能性がある環境 | Microsoft Security DevOps、Defender for CloudのDevOps連携、Azure DevOps/GitHubのコードスキャン連携 | 利用状況により変動 |
| 直接影響が小さい環境 | SARIFを生成・アップロードしていない通常のDefender for Endpoint運用 | 低 |
| すぐ行うこと | SARIF成果物内のindex、ruleIndex、parentIndexの-1出力を検索 | 高 |
管理者が誤解しやすいポイントは、「-1が不正な値になった」のではない点です。SARIFでは-1は「未設定のインデックス」を表すセンチネル値として扱われ、プロパティを省略した場合と意味的に同等です。今回の更新は、意味が同じならJSONに明示出力せず、ログを小さく保つべきだという最適化ルールの追加です。(GitHub)
SARIF2004の変更点：明示的な-1出力をログ肥大化として検出
SARIF2004.OptimizeFileSizeは、SARIFログを不必要に大きくしないための検証ルールです。今回のPRでは、このルールがindex、ruleIndex、parentIndexに明示的に出力された-1を検出するよう拡張されました。対象にはArtifactLocation、ReportingDescriptorReference、ThreadFlowLocation、LogicalLocation、Address、Artifact、Result.RuleIndexが含まれます。(GitHub)
問題となる例は次のようなSARIFです。
{
"artifactLocation": {
"uri": "src/foo.cs",
"index": -1
}
}この場合、indexが-1であることは「配列上の特定要素を指していない」ことを意味します。つまり、次のように省略しても意味は変わりません。
{
"artifactLocation": {
"uri": "src/foo.cs"
}
}今回の更新では、SDK内部でデシリアライズ時に既定値として-1になっただけのケースと、実際のJSONに"index": -1が物理的に書かれているケースを区別します。後者だけを警告対象にするため、単にC#側のプロパティ値が-1であるだけでは警告しない設計です。(GitHub)
何が変わらないのか
今回の変更で、-1の意味そのものは変わりません。-1を0に置き換える対応は避けてください。0は多くの場合「配列の先頭要素を参照する」という別の意味になるため、ログサイズの最適化どころか、スキャン結果の参照先を誤らせる可能性があります。
| やってよい対応 | やってはいけない対応 |
|---|---|
値が-1のindexを省略する | -1を0に置き換える |
値が-1のruleIndexを省略する | ruleIndexを機械的に全削除する |
値が-1のparentIndexを省略する | 正のインデックス値まで削除する |
| SARIF生成側で出力抑制する | アップロード先の警告だけを無視し続ける |
Microsoft Defender環境で影響を受ける可能性がある範囲
Microsoft Defender for Cloudでは、サードパーティのセキュリティツールから出力されたSARIF結果を取り込めます。Azure DevOpsリポジトリがDefender for Cloudにオンボードされている場合、Defender for CloudはSARIF出力のCodeAnalysisLogs成果物を監視します。Microsoft Learnでは、PublishBuildArtifacts@1でSARIFファイルをCodeAnalysisLogs成果物として公開する例も示されています。(Microsoft Learn)
そのため、今回のSARIF2004更新は、次のような環境で確認対象になります。
| 環境・運用 | 確認すべき理由 |
|---|---|
| Microsoft Security DevOpsをAzure DevOpsで実行している | スキャン結果がSARIFとして出力・公開される可能性がある |
| Defender for CloudにAzure DevOpsを接続している | CodeAnalysisLogs経由でSARIFを取り込む運用がある |
| サードパーティSASTツールの結果をDefenderやAdvanced Securityへ連携している | 変換後のSARIFに-1が明示出力される可能性がある |
| 独自ツールでSARIFを生成している | Serializer設定や出力ロジックの影響を受けやすい |
| SARIF SDKやSarif.MultitoolをCIで使っている | 更新後に新しい警告が出る可能性がある |
一方で、Windows端末のマルウェア対策、Defender for Endpointのデバイス制御、EDRアラート、攻撃面の縮小ルールなどを通常運用しているだけで、SARIFを生成していない環境では、この更新を理由にDefenderポリシーを変更する必要はありません。
管理者がまず確認すべきSARIFファイルの場所
最初に見るべき場所は、Defender管理画面そのものではなく、CI/CDの成果物です。Azure DevOpsやGitHub Actionsでセキュリティスキャンを実行している場合、SARIFファイルはビルド成果物、アーティファクト、ログ出力ディレクトリ、またはコードスキャンへのアップロード直前のパスに保存されています。
Microsoft Security DevOpsのAzure DevOps拡張では、publishが有効な場合にSARIF結果ファイルをパイプライン成果物へ公開し、Defender for Cloud連携ではartifactNameにCodeAnalysisLogsが必要とされています。(Microsoft Learn)
PowerShellで確認する例
Windowsエージェントやローカル環境では、次のように検索できます。
Select-String -Path ".\CodeAnalysisLogs\*.sarif" `
-Pattern '"(index|ruleIndex|parentIndex)"\s*:\s*-1' `
-Listサブフォルダーも含めて検索する場合は次のようにします。
Get-ChildItem -Path ".\CodeAnalysisLogs" -Filter "*.sarif" -Recurse |
Select-String -Pattern '"(index|ruleIndex|parentIndex)"\s*:\s*-1'Linuxエージェントで確認する例
GitHub ActionsやLinuxベースのAzure Pipelinesでは、次のように確認できます。
grep -RInE '"(index|ruleIndex|parentIndex)"[[:space:]]*:[[:space:]]*-1' ./CodeAnalysisLogs出力が多い場合は、まず件数だけ確認します。
grep -RIE '"(index|ruleIndex|parentIndex)"[[:space:]]*:[[:space:]]*-1' ./CodeAnalysisLogs | wc -l件数が数件なら手動修正でも対応できますが、数百件以上ある場合は、SARIF生成側のSerializer設定や変換処理を見直すべきです。
開発者が見直すべき実装ポイント
SARIFを独自生成している開発者は、出力後に-1を削るよりも、生成時点で不要なプロパティを出力しない設計にするのが理想です。今回のPRでも、明示的な-1は正しいがログサイズを増やすだけで、下流処理に価値を追加しないという整理がされています。(GitHub)
確認すべき実装箇所は次の通りです。
| 実装箇所 | 確認内容 | 修正方針 |
|---|---|---|
| SARIF生成クラス | Index = -1を明示設定していないか | 未設定を表す場合はプロパティを省略 |
| JSON Serializer | 既定値を常に出力する設定になっていないか | 対象プロパティの既定値を出力しない |
| SARIF変換処理 | 他形式から変換する際に-1を埋めていないか | 値が未設定なら出力しない |
| 後処理スクリプト | すべてのindexを削除していないか | 値が-1の対象プロパティだけ削除 |
| CIの品質ゲート | SARIF2004警告をエラー扱いしていないか | 移行期間中は警告扱いにするか先に修正 |
特に注意したいのは、index系プロパティを一括削除する対応です。index: 0やruleIndex: 2のような値は、配列内の有効な要素を参照している可能性があります。削除すると、コードスキャン画面でルール情報やファイル情報の関連付けが弱くなる場合があります。
Sarif.Multitoolで検証する方法
SARIF SDKのドキュメントでは、Sarif.Multitoolを使ってSARIFファイルのスキーマや追加の正当性ルールを検証できます。利用例としてSarif.Multitool validate Other.sarifが示されています。(GitHub)
Sarif.Multitool validate results.sarifnpmで利用している環境では、次のように実行する構成もあります。
npx @microsoft/sarif-multitool validate results.sarifCI/CDへ組み込む場合は、いきなりビルド失敗にせず、まずは非ブロッキングの検証ステップとして追加するのがおすすめです。新しいSARIF2004警告が大量に出る場合、ビルドを止めるより先に、どのツールが-1を明示出力しているかを特定する方が安全です。
CI/CDでの展開手順
今回の更新は、セキュリティ運用に関わるものではありますが、緊急パッチのように全環境へ即時展開する性質のものではありません。SARIFを扱うパイプラインでは、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 現状把握 | 既存SARIFに-1の明示出力があるか検索 | 件数、対象ツール、対象リポジトリを確認 |
| 影響確認 | Sarif.Multitoolで検証 | SARIF2004の警告件数を見る |
| 修正方針決定 | 生成側修正か後処理かを選ぶ | 独自ツールなら生成側、外部ツールなら一時後処理 |
| 検証環境へ反映 | 代表リポジトリでテスト | コードスキャン結果の件数・表示に差異がないか確認 |
| 本番反映 | CIテンプレートや共通Actionへ展開 | 警告が減り、アップロードや表示に問題がないこと |
| ゲート強化 | 必要ならSARIF2004警告を品質基準に追加 | 全体の運用が安定してから実施 |
全社共通のパイプラインテンプレートを使っている場合は、個別リポジトリで修正する前に、共通テンプレート側でSARIF出力パスと検証ステップを標準化すると運用が楽になります。
一時的な後処理を使う場合の注意点
外部ツールが生成するSARIFをすぐ修正できない場合は、アップロード前に-1の対象プロパティだけを削除する後処理を検討できます。ただし、後処理はあくまで一時回避です。将来的には、SARIF生成元のツールや変換ロジックを修正する方が安定します。
jqを使う場合の考え方は、「キーがindex、ruleIndex、parentIndexで、値が正確に-1のものだけ削除する」です。
jq 'walk(
if type == "object" then
with_entries(
select(
((.key == "index" or .key == "ruleIndex" or .key == "parentIndex") and .value == -1) | not
)
)
else
.
end
)' results.sarif > results.cleaned.sarifこの処理を使う場合は、必ず修正前後で以下を比較してください。
| 比較項目 | 見るべきポイント |
|---|---|
| SARIF検証結果 | SARIF2004以外の警告やエラーが増えていないか |
| コードスキャン結果 | アラート件数が不自然に減っていないか |
| ルール名・ファイル名表示 | 参照情報が欠落していないか |
| ファイルサイズ | 期待通りに小さくなっているか |
| Defender側の表示 | 推奨事項やコードスキャン結果が通常通り表示されるか |
失敗しやすいポイント
今回の変更は小さく見えますが、CI/CD運用では意外なトラブルにつながることがあります。
まず、ツール更新後にSARIF2004の警告が増え、品質ゲートでビルドが失敗するケースです。SARIF2004をエラー扱いしている場合、SDKやMultitoolのバージョン更新だけでパイプラインの結果が変わる可能性があります。PRでは既存のSARIF2004に新しいメッセージ文字列が追加され、明示的な-1出力を検出するテストも追加されています。(GitHub)
次に、-1を削除すべきところで0に変換してしまうケースです。これはログサイズの最適化ではなく、参照先の意味を変える修正です。特にruleIndexはルール配列を参照するため、誤った値に変えるとアラートのルール情報がずれる可能性があります。
最後に、Defenderの問題だと思って管理ポータル側だけを調査してしまうケースです。今回見るべき主な場所は、Defenderポータルの設定画面ではなく、SARIFを生成するビルドステップ、変換ツール、アップロード前の成果物です。
すぐ対応すべき環境と様子見でよい環境
すべてのMicrosoft Defender利用者が同じ優先度で対応する必要はありません。次の基準で判断すると、過剰対応を避けられます。
| 優先度 | 対象環境 | 対応 |
|---|---|---|
| 高 | Microsoft Security DevOpsやサードパーティSASTのSARIFをDefender for Cloudへ取り込んでいる | すぐにSARIF成果物を検索・検証 |
| 高 | SARIF2004をCIの品質ゲートに使っている | ツール更新前に検証環境で警告数を確認 |
| 中 | 独自ツールでSARIFを生成している | Serializer設定と出力ロジックを見直す |
| 中 | GitHub/Azure DevOpsのCode ScanningへSARIFをアップロードしている | アップロード前のSARIFを検証 |
| 低 | Defender for Endpointのみを端末保護として利用している | 今回の変更による直接対応は基本不要 |
| 低 | SARIFを使っていない | 情報把握のみでよい |
管理者向けチェックリスト
公開・更新情報を確認したら、次の順に進めると実務上の抜け漏れを減らせます。
- CI/CDでSARIFを生成しているリポジトリを洗い出す
CodeAnalysisLogsやビルド成果物内の.sarifを検索するindex、ruleIndex、parentIndexに-1が明示出力されている件数を確認する- Sarif.Multitoolで代表ファイルを検証する
- SARIF生成元がMicrosoft Security DevOps、サードパーティツール、独自変換処理のどれかを特定する
- 独自実装なら生成時に対象プロパティを省略する
- 外部ツールならバージョン更新、設定変更、一時後処理の順に検討する
- CIの品質ゲートでSARIF2004をエラー扱いしている場合は、段階展開にする
- 修正後にDefender for CloudやCode Scanning上の表示が変わっていないか確認する
今回の更新を運用改善につなげるポイント
今回のSARIF2004更新は、単なるログサイズ削減の話に見えます。しかし、Defender for CloudやDevSecOpsの運用では、スキャン結果の品質がそのままアラートの見やすさ、重複調査の少なさ、CI/CDの安定性に影響します。
特に大規模リポジトリやモノレポでは、スキャン結果のSARIFが大きくなりやすく、不要なプロパティの積み重ねがアップロード時間や保管コスト、レビュー時のノイズにつながります。-1の明示出力は1件あたりの影響は小さいものの、全リポジトリ・全ブランチ・全パイプラインで蓄積すると無視できない運用負荷になります。
次に取るべき行動はシンプルです。まず、直近のCI/CD成果物からSARIFファイルを1つ選び、"(index|ruleIndex|parentIndex)": -1に該当する出力があるか確認してください。該当があれば、Sarif.Multitoolで検証し、生成元のSerializer設定または変換処理で-1の明示出力を省略します。該当がなければ、SARIF関連ツールを更新する際の確認項目として、今回のSARIF2004変更を運用手順に追加しておけば十分です。
コメント