Codename MDASH の Azure Government 展開、エージェント型セキュリティを公共部門で試す
Microsoft は、100を超える専門AIエージェントを備えた Codename MDASH Azure Government 機能を展開し、そのコードスキャナーを厳格なセキュリティ環境へ移行した。対象となる米国政府顧客と認定パートナーは、プレビュー版のシステムにアクセスできるようになった。
この展開が重要なのは、Microsoft が単なる静的解析の高速化以上を約束しているためだ。Codename MDASH は複数のモデルとエージェントの役割を用い、疑われるソフトウェア上の欠陥が到達可能で悪用可能かどうかを調査する。このアプローチは、従来のアプリケーションセキュリティツールの利用を制約してきた誤検知の問題を対象としている。
ただし、Azure Government 内での展開は、このスキャナーが連邦政府のコードベース全体で信頼性高く機能することを示すものではない。Microsoft は有望なベンチマーク結果と社内テスト結果を公開している。各機関は今後、それらの結果が正確な検出結果、管理可能なレビュー負荷、迅速な修正へと結び付くかを判断しなければならない。
したがって中心となる争点は、Microsoft と別のセキュリティベンダーの競争ではない。自動化された脆弱性発見と、政府のセキュリティ運用に求められる証拠要件との対比である。不審なコードをより多く発見しても、チームが重要なリスクを検証し、優先順位を付け、修正できる場合にのみ役立つ。
Codename MDASH Azure Government で何が変わったのか
Codename MDASH は、Microsoft の社内セキュリティ研究および商用プレビューから、対象となる政府ワークロード向けに構築された環境へと進出した。
Microsoft は2026年9月8日にこの展開を発表した。Azure Government deploymentにより、対象となる米国政府顧客と認定パートナーはプレビュー版へアクセスできる。
このシステムは、複数段階のパイプラインでソースコードを分析する。まずコードベースをマッピングし、複雑さや潜在的リスクなどの要因に基づいて領域を順位付けする。その後、専門エージェントが選定されたコードパスを調査し、異なる脆弱性カテゴリを検査する。
Microsoft によると、1回のスキャンには100を超えるエージェントが参加できる。同社が示した例には、インジェクション脆弱性、メモリ安全性の問題、認証回避に重点を置くエージェントが含まれる。
別のエージェント群が初期の検出結果に異議を唱える。これらのエージェントは、疑われる欠陥が到達可能で危険かどうかについて、賛否双方の論拠を提示する。その後、システムは重複する結果を統合し、信頼度情報を付与する。
動的テストが可能な脆弱性クラスでは、Codename MDASH は欠陥を誘発する入力の生成を試みることができる。この検証ステップは、悪用可能な状態と、実行中のシステムに影響しない不審なコードとを区別することを目的としている。
この区別は重要である。従来の静的アプリケーションセキュリティテストは、既知のパターンやデータフロー規則とコードを照合することが多い。こうしたツールは高速にスキャンできる一方、実際の露出を確立するために必要な実行時コンテキストを欠くアラートを出すことがある。
Codename MDASH は、より調査的なアプローチを取る。言語モデルを、コード解析、型情報、呼び出しグラフ、エージェント間の対抗的レビューと組み合わせる。Microsoft はこれを、セキュリティ研究者に近い形でコードを推論するものとして説明している。
政府環境への導入は、この技術を評価する対象者も変える。民間企業は、限定的な開発プログラム内で新興のセキュリティツールを試験できる。政府機関は、認可境界、機密性の高いソースコード、監査要件、任務への影響を考慮しなければならない。
この製品は依然としてプレビュー版であり、これは重要な留保条件である。Microsoft は、確立されたスキャナー、ペネトレーションテスト、人によるレビューを全面的に置き換えるものとして提示しているわけではない。アクセスも一般提供ではなく、限定されている。
ここに本稿の主要な緊張関係がある。Codename MDASH は、より深い形の自動解析を政府環境にもたらすが、その検出結果にはベンチマーク上の成功より高い基準が求められる。
政府のセキュリティチームが今プレッシャーに直面する理由
政府ソフトウェアの所有者には、より優れた発見ツールが必要である一方、追加されるすべてのアラートが限られた修正能力を奪い合う。
連邦システムは、カスタムアプリケーション、商用製品、オープンソースコンポーネント、そして政府機関の任務に不可欠であり続ける旧式ソフトウェアに依存している。微妙な弱点が悪用可能になるまでに、複数のモジュールをまたぐこともある。
従来のスキャナーは、既知のパターン、依存関係、設定上の問題に対して依然として価値がある。しかし、ロジックエラーや複雑な攻撃経路は、あらかじめ定義されたルールに大きく依存するツールでは見逃される可能性がある。
攻撃者も、防御側が使うのと同じ種類の言語モデルや自動コーディングツールを利用できるようになっている。AI は、未知のリポジトリの調査、テストケースの提案、大量のコードにまたがる関係の追跡に役立つ。
この共有された能力は、防御側に残された時間を圧縮する。自動化されたシステムが先に欠陥を見つけたとしても、その欠陥が無害になるわけではない。政府機関は依然として結果を確認し、影響を受けるデプロイメントを特定し、修正を準備し、テストし、リリースしなければならない。
Microsoft は、時間を持続的な優位性と位置付けている。攻撃者より先に防御側が弱点を発見してパッチを適用できれば、自動化は実質的な価値を生み出したことになる。検出結果がキューに滞留するなら、発見の高速化は単にバックログを拡大するだけになり得る。
政府の要件はすでに、継続的な可視性と脆弱性管理を重視している。CISA の連邦向けガイダンスには、定期的な資産スキャン、既知の悪用済み脆弱性の優先付け、対象システムに対する修正への期待が含まれる。
これらの要件は一般に、展開済み資産と既知の露出に焦点を当てる。Codename MDASH は、ソースコードおよび開発パイプライン内の弱点へと注意を早い段階で移す。これは、欠陥が運用システムに到達する前に発見するという、より広範な目標を支える。
CISA のsecure development guidelinesも、システムのライフサイクル全体にわたるセキュリティ成果への責任を重視している。エージェント型コードスキャンは、証拠と開発者へのフィードバックを強化する場合、この方向性に合致する。
そのプレッシャーは、政府機関のアプリケーション所有者、セキュリティ運用チーム、認可担当者にかかる。AIが生成した検出結果が、リリース判断やリスク評価にどのような影響を与えるかを決めなければならない。
開発者にも、実用的な修正情報が必要になる。アラートは脆弱なパスを特定し、セキュリティ上の影響を説明し、レビュー担当者が再現できる証拠を提示すべきである。重大度ラベルだけでは、ほとんど役に立たない。
セキュリティチームは、関連するガバナンス上の問いにも直面する。ある検出結果が、決定論的なコード解析、確率的なモデル推論、動的テスト、あるいはそれらの組み合わせのどれから生まれたかを判断しなければならない。
その由来は信頼性に影響する。また、基盤となるモデル、プロンプト、またはエージェントのオーケストレーションが変化した後に、チームが結果をどのように再現するかにも影響する。
求められる対応は、修辞的なものではなく運用上のものである。Codename MDASH を採用する機関には、受け入れルール、人によるレビューの責任者、エスカレーションの閾値、検出結果と完了した修正を結び付ける測定指標が必要だ。
この構造がなければ、エージェント型スキャンは別のアラート発生源になる危険がある。構造があれば、このシステムは既存ツールでは優先順位を付けにくい複雑な欠陥へと、セキュリティ作業を移すことができる。
本当の賭けはAIエージェントの増加ではなく検証にある
Codename MDASH が成功するのは、エージェント間の議論が単にモデル生成の意見量を増やすのではなく、より強力な証拠を生み出す場合に限られる。
このシステムの仕組みは、発見と検証を分けている。一方のエージェント群が不審な挙動を探し、もう一方が各候補が現実的な条件下で発生し得るかを検証する。
このアーキテクチャは、単一パスのモデル解析の弱点に対処しようとするものだ。言語モデルは、プログラムの実際の制御フローや実行時の挙動と一致しない、もっともらしい説明を生成することがある。
Microsoft は、エージェントの推論をより従来的な技術シグナルと組み合わせている。scanner documentationでは、呼び出しグラフ解析、コード複雑度メトリクス、テイント解析、型解決、信頼度スコアリング、結果の重複排除が説明されている。
呼び出しグラフは、関数間の関係をマッピングする。テイント解析は、信頼できない情報が入力から機微な操作へ移動し得るかを追跡する。型解決は、特定の言語内で値や関数がどのように振る舞うかをスキャナーが解釈する助けとなる。
これらの手法は、リポジトリに関する構造化された情報をエージェントに与える。また、不完全なコード断片から推論しかねないモデルを制約する助けにもなる。
その後の議論段階では、到達可能性と悪用可能性を検証する。到達可能性は、実行が疑われるパスに入れるかを問う。悪用可能性は、攻撃者がそのパスを意味のあるセキュリティ上の結果へ転換できるかを問う。
これらは異なる問いである。危険な関数が存在しても、攻撃者からアクセス可能とは限らない。到達可能なパスにも、悪意ある入力による被害を防ぐ制御が含まれることがある。
報道によると、Codename MDASH は信頼度を割り当てる前に、エージェントに双方の論拠を構築させる。この内部的な対立は、各結果の信頼性を対象としているため、その設計で最も重要な部分である。
実行可能な場合、最終的な検証段階はさらに踏み込む。このシステムは、脆弱な状態を示す入力を生成して実行することを試みることができる。再現可能なトリガーは、人間のレビュー担当者にモデルの説明より強い根拠を与える。
ただし、重大な脆弱性のすべてが安全かつ簡単な検証を可能にするわけではない。認可上の弱点、分散ロジックのエラー、競合状態、環境依存の欠陥は、単独での再現に抵抗することがある。
政府ソフトウェアには、特殊なアーキテクチャと運用上の制約も含まれる。一部のコードは、制限された環境の外部では実行できない。他のリポジトリには、露出を判断するために必要なデプロイメント設定が欠けている場合もある。
エージェントの数自体が、こうした制約を解決するわけではない。モデル呼び出しを増やせば仮説を多様化できるが、類似システム間の合意は独立した検証と同義ではない。
モデルは、訓練データ、前提、盲点を共有し得る。また、各エージェントが同様の証拠を受け取る場合、説得力はあるが誤った解釈を相互に強化する可能性もある。
したがって、より強い主張は狭いものになる。Codename MDASH は、専門化された探索、対抗的レビュー、プログラム解析を、単一の脆弱性調査パイプラインへ統合する。
この仕組みが注目に値するのは、人間のセキュリティチームがすでに行っている作業を反映しているためだ。研究者は仮説を立て、実行を追跡し、前提に異議を唱え、挙動を再現し、重複した報告を除外する。
自動化はこのプロセスを加速できる。しかし、政府機関の実際の運用コンテキストで検出結果がなぜ正しいのかを立証する必要性はなくせない。
Azure Government はセキュリティ上の論拠の一部である
政府機関は機密性の高いソースコードを商用AIサービスへ気軽に送ることはできないため、展開境界は単なるパッケージング上の詳細ではない。
ソースコードは、システムアーキテクチャ、内部インターフェース、認証ロジック、防御的制御を明らかにし得る。任務に関わるアプリケーションでは、コードが正式に機密指定されていなくても、こうした詳細は機微な情報となる可能性がある。
Microsoftによれば、このマルチモデル・ハーネスは、ソースコードと関連する学習データを承認済みの境界内に保ちながら、適切なモデルを利用できる。この主張は、政府機関による導入における大きな障壁に直接応えるものだ。
Azure Governmentは、対象となる米国政府機関およびパートナー向けに提供される、Microsoftクラウドの物理的に分離されたインスタンスである。そこで提供されるサービスは、別個の可用性、認可、運用プロセスに従う。
Codename MDASHをこの環境に導入することで、承認済みのユーザーは、リポジトリを通常の商用サービス境界へ移動させることなくスキャナーを評価できる。また、ID管理、アクセス、ログ記録、監督についても、政府機関にとってよりなじみのある経路を提供する。
ただし、このプレビューには慎重な構成が依然として必要だ。政府クラウドへのアクセスがあるからといって、すべてのワークロードがすべてのサービスに適しているわけではない。政府機関には引き続き、データの機微性およびシステム要件を関連する認可に適合させる責任がある。
チームは、スキャン中にどの情報がリポジトリ外へ出るのかも理解しなければならない。機微情報となり得るものには、コード断片、依存関係情報、コミット履歴、生成された証明、プロンプト、モデル出力が含まれる。
保持期間にも同等の注意が必要だ。セキュリティチームは、スキャン成果物がいつまで利用可能か、結果がどこに保存されるか、そしてサービス改善に寄与するかを把握すべきである。
モデルルーティングは別の疑問をもたらす。Microsoftは、タスクごとに異なるモデルを利用できる能力を訴求している。政府機関は、どの承認済みモデルが関与するのか、またルーティング変更が認可に関する前提へ影響するかを可視化する必要がある。
商用版はGitHubおよびAzure DevOpsと統合され、Defender CLIを通じたローカルまたは継続的インテグレーションのスキャンをサポートし、検出結果をMicrosoft Security Exposure Managementへ公開する。
これらの接続は摩擦を減らせる一方、システムの権限を拡大する。スキャナーには、リポジトリと関連メタデータを読み取るために十分なアクセスが必要となる。修正機能には、コードを変更したり、提案された変更を作成したりする権限が必要になる場合がある。
最小権限の設計が不可欠になる。検出、証明生成、自動修復は、同一のワークフローに属するというだけで同一の権限を与えられるべきではない。
生成された修正には特に注意が必要だ。パッチは直接的なトリガーを取り除く一方で、回帰を導入したり、別の悪用経路を残したりする可能性がある。政府機関はAI生成の変更を、レビューとテストの対象となる提案コードとして扱うべきである。
監査ログは、最初の検出から最終判断までの連鎖を保持しなければならない。レビュー担当者は、影響を受けたリビジョン、裏付けとなる証拠、信頼度の変化、人間による判断、最終的なパッチを確認できるべきだ。
ここでAzure Governmentは、製品の信頼性の一部となる。この環境はスキャナーを取り巻く制御を提供できるが、政府機関は、それらの制御が説明責任を伴う利用に十分な透明性をもたらすかを検証しなければならない。
したがって、この導入はMicrosoftの政府向けセキュリティ戦略を前進させる。ただし、リスクの所有権を政府機関からベンダーへ移すものではない。
強力なベンチマークスコアは本番環境での証明ではない
Microsoftが公表した結果は真剣な評価を正当化するが、未知の政府機関リポジトリ全体における性能を確立するものではない。
Microsoftは2026年5月、Codename MDASHを初めて公に説明した。同社は、このシステムが研究者による、重大なリモートコード実行の脆弱性4件を含む、これまで未知だったWindows脆弱性16件の特定を支援したと述べた。
影響を受けた領域には、Windowsのネットワークおよび認証スタックが含まれる。Microsoftのセキュリティテスト結果では、非公開のテストドライバーにおいて、誤検知なしで埋め込まれた脆弱性21件をすべて検出したことも報告されている。
Microsoftは、Windows Common Log File Systemドライバーにおける5年分の確認済み事例に対して96%の再現率を報告した。Windows TCP/IPドライバーの過去事例については100%の再現率を報告している。
これらは第一者による評価である。Microsoftが単なる人工的なコード断片の集合以上をテストしたことを示すが、外部の関係者が異なる言語やアーキテクチャでも同じ性能を期待できるわけではない。
同社の9月の政府向け発表では、CyberGymで96.55のスコアを記載している。この結果はMicrosoftが5月に公表した88.45を上回っており、システムまたはベンチマーク構成が変更されたことを示唆する。
CyberGymは、188のソフトウェアプロジェクトから得られた1,507件の過去の脆弱性を含む公開ベンチマークである。そのベンチマーク手法では、エージェントが動作する概念実証テストを生成することで脆弱性を再現できるかを評価する。
このベンチマークは実際のリポジトリと公開済みの脆弱性を用いるため、孤立した関数分類よりも要求が厳しい。そのコードベースには相当数のファイルとコード行が含まれる。
しかし、このタスクではエージェントに脆弱性の説明と対応する未修正リポジトリが与えられる。本番環境での検出は通常、スキャナーがどの脆弱性が存在するかを知らないため、より困難な位置から始まる。
したがって、説明済みの過去の欠陥を再現することは、未知の弱点を発見することと同一ではない。この違いはスコアを無効にするものではないが、その数値が立証できる範囲を限定する。
公開ベンチマークは、システムがそれらに直接最適化されるほど情報価値が低下する。政府機関は、96.55という結果を生んだ構成、その構成がAzure Governmentと一致するか、結果がどの程度再現可能かを確認すべきである。
Microsoftの5月と9月のスコア差には文脈が必要だ。これは製品の改善、評価ハーネスの変更、モデルアクセスの拡張、または別のベンチマーク提出設定を反映している可能性がある。
政府の評価担当者は、再現率と適合率も分けて考えるべきだ。再現率は、システムが実際の欠陥をどれだけ見つけるかを測る。適合率は、報告された検出結果のうち実際に有効なものがどれだけあるかを測る。
再現率が高くても適合率が低いスキャナーは、レビュー担当者を圧倒しかねない。適合率が高くてもカバレッジが狭いスキャナーは、完全性について誤った安心感を与える可能性がある。
先行する学術研究は、注意が必要な理由を示している。IEEE Security and Privacyの評価では、テストされた言語モデルは高い誤検知率を示し、繰り返し実行間で脆弱性判断に一貫性がなかった。
より新しい研究はマルチエージェント・フィルタリングを支持しているが、モデルおよび脆弱性カテゴリ間で性能には依然としてばらつきがあると説明している。結果はプロンプト、分析ツール、リポジトリの文脈、成功の定義に左右される。
NISTの2026年エージェント・セキュリティ分析は、より広範な結論に達した。既存のサイバーセキュリティ原則は引き続き有効だが、エージェントシステムには適応された評価手法とガイダンスが必要である。
Codename MDASHについて、必要な証拠は管理された政府機関のパイロットから得るべきだ。評価担当者には、未知のリポジトリ、隠された脆弱性、修正済みコード、検出結果を出すべきでないクリーンなコードからの結果が必要である。
一貫性を測定するため、スキャンを繰り返すべきだ。また、結果を専門家レビューおよび確立された静的・動的ツールと比較すべきである。
決定的な指標は、スキャナーが生成した脆弱性の件数ではない。スキャナーが関与したことで、政府機関がより迅速に修正できた、検証済みで重大な検出結果の割合である。
エージェント型コードセキュリティにも人間の権限が必要だ
最も安全な運用モデルでは、AIが調査を担い、人間がリスク受容、コード変更、デプロイに関する権限を維持する。
Codename MDASHは、コードパスの追跡や潜在的な検出結果の検証に伴う機械的な作業を減らせる。これにより、セキュリティ専門家はアーキテクチャ上の判断や難しい修正判断により多くの時間を割ける。
ただし、このシステムは新たな運用リスクも生み得る。AI生成の証明は信頼できないコードを実行する可能性がある。提案された修正は、セキュリティ上重要な動作を変更する可能性がある。リポジトリコネクターは、スキャンに必要な範囲を超える情報を公開する可能性がある。
政府機関は、証明生成を管理された環境内に隔離すべきである。ネットワークアクセス、認証情報、シークレット、ビルドツール、テストデータには、広範な開発者権限を継承させるのではなく、明示的なポリシーを適用すべきだ。
人間のレビュー担当者には、検出結果を受け入れるための明確な基準も必要である。信頼度スコアは優先順位付けを支援できるが、到達可能性、攻撃者の前提条件、影響を受けるバージョン、運用上の影響に関する証拠を置き換えるべきではない。
レビュー担当者は、隠されたモデル推論に頼ることなく、重要な経路を再現できるべきだ。サービスだけがアラートの存在理由を説明できるなら、政府機関は不透明な評価に依存することになる。
同じ原則は、スキャナーが問題なしと報告する場合にも当てはまる。検出結果がないことは、リポジトリが安全である証拠ではない。サポートされないビルド条件、欠落した文脈、またはモデルエラーにより、システムは脆弱なコードを見逃す可能性がある。
したがってCodename MDASHは、既存の制御を補完すべきである。依存関係分析、シークレットスキャン、静的解析、ファジング、ペネトレーションテスト、コードレビュー、ランタイム監視は、それぞれ異なる障害モードを観測する。
エージェント型スキャンは、それらのレイヤーをまたいで証拠を結び付ける場合に価値を加える。たとえば、デプロイメントの文脈がインターネット公開サービスが影響を受ける関数に到達することを示す場合、疑わしいデータフローの緊急性は高まる。
MicrosoftのExposure Management統合は、その方向性を示している。このシステムは、すべてのコードの弱点を同等に重要なものとして扱うのではなく、組織リスクに関するより広い見方の中に検出結果を位置付けられる。
この文脈はガバナンス上の責務も生む。政府機関は、デプロイメント情報が検出結果の重大度を変更した場合、また人間が自動順位付けを上書きした場合を文書化すべきである。
チームはモデル更新も監視しなければならない。変更されたモデルは、製品の見えるインターフェースを変えずに、検出カバレッジ、信頼度スコアリング、一貫性を変化させる可能性がある。
リリースノートは、重要なスキャン変更を特定すべきである。政府機関は、機微なワークロード向けに新しい構成を受け入れる前に、検証スイートを再実行する必要があるかもしれない。
調達チームは、Microsoftがモデルの廃止およびフォールバック動作をどのように扱うかを確認すべきだ。マルチモデル設計は柔軟性を提供するが、数か月後には結果の再現をより難しくする可能性がある。
サポート対象外または専門的な言語では、独立テストが特に重要である。Microsoftは、Codename MDASHが主要言語全般で幅広く機能しつつ、C、C++、Java、C#にはより深いチューニングを施していると述べている。
この表現は、どの環境でも同等の性能を確立するものではない。一般的でない言語、レガシーフレームワーク、運用技術を使用する政府機関は、代表的なコード内でカバレッジを測定すべきである。
正しい導入モデルは段階的なものだ。既知のテストケース、成熟した所有体制、異論のある検出結果を評価するために十分なセキュリティ専門知識を備えたリポジトリから始める。
その後、MDASHが成果を変えるかを測定する。有用な問いには、見逃されていた欠陥を発見するか、トリアージ時間を短縮するか、修正品質を改善するか、あるいは単に異なるアラートを生み出すだけかが含まれる。
米国政府機関が次に注視すべきこと
Codename MDASHが信頼できる政府向け制御となるか、それとも有望なプレビューにとどまるかは、3つのシグナルによって決まる。
第一のシグナルは、政府機関のパイロットから得られる独立した精度データである。政府機関は、ポリシーが許す場合、検証済みの検出結果、誤検知率、見逃した欠陥、レビュー担当者の作業時間を含む匿名化された指標を公表すべきである。
未知のリポジトリ全体で強い適合率と再現率を示せれば、Microsoftの主張を裏付けることになる。言語間や繰り返しスキャン間で大きなばらつきが見られれば、広範な導入への信頼は弱まる。
第2のシグナルは、修正対応に関する運用上の証拠です。評価担当者は、生成された検出件数だけでなく、スキャン完了からパッチ適用の確認までに要する時間を追跡すべきです。
修正サイクルの短縮は、エージェント型AIセキュリティが成果を改善していることを示します。一方、バックログの増加は、検出能力の向上が、政府機関の対応能力を上回っていることを示すでしょう。
第3のシグナルは、プレビュー段階から文書化された政府向けサービスへ至る道筋です。購入担当者がMDASHを標準的な統制セットの一部として扱うには、可用性、認可、モデルルーティング、保持、監査に関するより明確な情報が必要です。
透明性のある本番運用計画は、この展開の意義を高めるでしょう。プレビュー状態が長引いたり、サービスの境界が不明確だったりすれば、このシステムは厳重に管理された実験に限定され続けます。
これらのシグナルはMicrosoftにとどまらず重要です。エージェント型の脆弱性発見は、アプリケーションセキュリティプラットフォーム全体で標準的な機能となる可能性が高いでしょう。政府による導入は、ベンダーが証拠、再現性、人間による監督をどのように文書化するかに影響を与えます。
開発者が注目すべきなのは、スキャナーの検出結果がリリース判断に与える影響がますます大きくなるためです。セキュリティ責任者が注目すべきなのは、こうしたツールが脆弱性キューの量と質の両方を変え得るためです。
企業の購入担当者が政府のパイロットを注視すべき理由は別にあります。公共部門の環境では、データ境界、認可、追跡可能性、説明責任に関して厳しい要件が課されます。
Codename MDASHがこうした制約下で十分に機能すれば、エージェント型コードスキャンの有用性は他の領域でもより強く裏付けられます。苦戦すれば、その失敗モードも同様に価値ある指針をもたらすでしょう。
したがって、Azure GovernmentへのCodename MDASHの展開は、確定した結論ではなく重要な試験です。Microsoftは、注目すべき自社一次データとベンチマーク結果に支えられた高度なスキャンアーキテクチャを、ミッションソフトウェアにより近づけました。
今後は、日々のセキュリティ業務から証拠を得る必要があります。政府機関は検出結果を再現できるのか、その優先度を信頼できるのか、そして攻撃者に到達される前に重要な弱点を修正できるのか。
追跡すべきなのは、この成果です。Codename MDASHを評価する政府の技術チームは、アクセスを拡大する前に、統制された比較、監査可能な証拠、修正対応の指標を求めるべきです。
