MDASH 확장 프리뷰, 100개 에이전트와 Defender 취약점 검증

Microsoft Security는 Build 2026 보안 발표에서 codename MDASH를 expanded preview로 확대한다고 밝혔습니다. 발표 날짜는 2026년 6월 2일입니다. MDASH는 Microsoft Security multi-model agentic scanning harness의 코드명입니다. 발표의 새 부분은 단순한 “AI 취약점 스캐너” 출시가 아니라, MDASH가 eligible organizations 대상 preview로 넓어지고 Microsoft Defender와 통합됐다는 점입니다. Microsoft는 개발팀과 보안팀이 같은 취약점 후보를 보고, exploitability와 production signal을 기준으로 우선순위를 잡고, GitHub Code Security와 Copilot Autofix 쪽으로 수정 흐름을 이어가도록 설계했다고 설명했습니다.

Build 발표만 보면 MDASH는 Microsoft의 agent platform, Agent 365, ASSERT, Agent Control Specification 사이에 놓인 여러 보안 기능 중 하나입니다. 그러나 2026년 5월 12일 Microsoft의 MDASH 기술 글을 함께 읽으면 사건의 초점이 분명해집니다. Microsoft는 MDASH가 Windows networking and authentication stack에서 16개 신규 취약점을 찾는 데 도움을 줬고, 이 중 4개가 Critical remote code execution이었다고 밝혔습니다. 이 취약점들은 2026년 5월 Patch Tuesday cohort로 다뤄졌습니다.

MDASH의 구조는 모델 하나에 repository를 던져 “취약점 찾아줘”라고 묻는 방식과 다릅니다. Microsoft는 prepare, scan, validate, dedup, prove 단계를 가진 structured pipeline으로 설명합니다. Prepare 단계는 source target을 수집하고 language-aware index, attack surface, threat model을 만듭니다. Scan 단계는 specialized auditor agents가 후보 경로를 훑고 hypothesis와 evidence를 냅니다. Validate 단계에서는 다른 agent cohort가 reachability와 exploitability를 두고 찬반을 따집니다. Dedup 단계는 의미상 같은 finding을 묶고, prove 단계는 bug class가 허용하는 경우 triggering input을 만들어 실제 취약점 존재를 검증합니다.

이 구조에서 Microsoft가 강조한 문장은 “the model is one input, the system is the product”입니다. 한국어로 옮기면 모델은 입력 중 하나이고, 제품은 harness 전체라는 뜻에 가깝습니다. MDASH는 100개 이상 specialized agents를 사용합니다. Auditor, debater, prover가 같은 역할을 하지 않고, 각 단계마다 prompt regime, tool, stop criteria가 다릅니다. Microsoft는 state-of-the-art model을 heavy reasoner로 쓰고, distilled model을 high-volume debate에 쓰며, 별도의 SOTA model을 independent counterpoint로 쓰는 구성을 예로 들었습니다.

5월 기술 글의 실험 수치는 MDASH가 무엇을 주장하는지 보여줍니다. Microsoft는 StorageDrive라는 private device driver test에서 21개 deliberately injected vulnerabilities를 모두 찾았고, 해당 run에서 false positive가 없었다고 적었습니다. StorageDrive는 offensive security researcher interview에 쓰이는 sample driver이며 공개된 적이 없는 코드라서, 모델이 학습 데이터에서 답을 봤을 가능성을 낮추는 용도로 사용됐습니다. 취약점 유형에는 kernel use-after-free, integer handling issue, IOCTL validation gap, locking error가 포함됐습니다.

Microsoft는 retrospective benchmark도 제시했습니다. pre-patch snapshot을 대상으로 5년간 MSRC confirmed case를 다시 찾는 실험에서 clfs.sys는 28건 중 96% recall, tcpip.sys는 7건 중 100% recall이라고 밝혔습니다. 이 수치는 미래의 모든 버그를 같은 비율로 찾는다는 약속이 아닙니다. Microsoft도 글에서 retrospective recall은 finite case count를 가진 내부 benchmark이며, 다음 CLFS 버그 38개를 같은 비율로 찾는다고 예측하지 않는다고 선을 그었습니다. 그래도 이 수치가 의미 있는 이유는 MSRC case가 실제 Patch Tuesday와 공격 대응으로 이어진 ground truth였기 때문입니다.

Public benchmark에서는 CyberGym이 등장합니다. 5월 12일 글은 CyberGym을 188개 OSS-Fuzz project에서 나온 1,507개 real-world vulnerability reproduction tasks로 설명하고, MDASH가 level 1 default configuration에서 88.45% success rate를 기록했다고 적었습니다. 6월 2일 Build 보안 글에서는 MDASH가 3주 미만 사이 roughly 10% 올라 CyberGym industry benchmark score 96.55%에 도달했다고 밝혔습니다. 같은 글은 여러 모델, hundreds of agents, 하루 100조 개 이상 signals가 theoretical noise보다 exploitable risk를 찾는 데 도움을 준다고 주장했습니다.

벤치마크보다 더 실무적인 부분은 16개 CVE 목록입니다. 5월 Patch Tuesday cohort에는 tcpip.sys, ikeext.dll, telnet.exe, http.sys, netlogon.dll, dnsapi.dll이 들어갔습니다. Microsoft는 이 중 10개가 kernel-mode, 6개가 user-mode였고, 다수는 network position에서 credential 없이 reachable하다고 적었습니다. Critical로 언급된 예시는 네 가지입니다. tcpip.sys SSRR IPv4 packet use-after-free는 CVE-2026-33827이고, ikeext.dll IKEv2 SA_INIT double-free는 CVE-2026-33824입니다. 나머지는 netlogon.dll CLDAP stack overflow인 CVE-2026-41089와 dnsapi.dll crafted UDP DNS response heap out-of-bounds인 CVE-2026-41096입니다.

Microsoft가 긴 technical deep dive를 넣은 이유는 “AI가 찾았다”보다 “왜 단일 모델 분석으로 놓치기 쉬웠는가”를 보여주기 위해서입니다. CVE-2026-33827 설명에서 문제는 Windows IPv4 receive path의 Path object lifetime입니다. Reference를 drop한 뒤 SSRR processing에서 같은 pointer를 다시 쓰는 순서가 만들어집니다. 이후 path cache scavenger, flush routine, interface state-driven garbage collection 같은 외부 subsystem이 final reference를 떨어뜨릴 수 있습니다. 공격자는 crafted IPv4 packet metadata로 경로를 유발할 수 있지만, issue 자체는 한 함수 안의 명백한 release-then-use 패턴으로 보이지 않습니다.

CVE-2026-33824는 더 선명합니다. IKEEXT service에서 IKEv2 SA_INIT과 fragmentation 처리가 얽힌 double-free이며, Microsoft는 두 UDP packets, no race, no special timing이라고 설명했습니다. Root cause는 receive context를 flat memcpy로 복제하면서 heap allocation ownership까지 복제하지 못한 shallow copy입니다. 같은 pointer를 두 context가 자기 소유라고 믿고 teardown에서 각각 free합니다. 이 버그는 여섯 개 source file에 걸친 aliasing lifecycle bug였고, 같은 코드베이스 안의 올바른 pattern과 비교해야 missing step이 드러났습니다.

이 두 예시는 MDASH가 왜 prepare, validate, prove를 분리하는지 설명합니다. 취약점 후보를 찾는 일은 backlog를 만드는 일과 다르지 않을 수 있습니다. 보안팀이 실제로 필요한 것은 “이 후보가 외부 입력으로 reachable한가”, “동일 finding이 이미 보고됐는가”, “triggering input이나 ASan 재현이 있는가”, “patch 후보가 regression을 막는가”입니다. Microsoft는 CLFS proving plugin 예시도 들었습니다. 후보 finding이 있어도 triggering log file을 만들 수 없다면 triage queue에 남습니다. Domain plugin은 on-disk container layout, block validation sequence, in-memory state machine 같은 Microsoft-specific invariant를 harness에 주입합니다.

Build 2026에서 새로 붙은 Defender 통합은 이 이야기를 개발 조직의 workflow로 끌고 옵니다. Microsoft는 MDASH가 식별하고 검증한 exploitable risk를 Microsoft Defender와 GitHub Code Security 통합으로 이어간다고 밝혔습니다. 이 통합은 runtime context, internet exposure, data sensitivity 같은 production signal을 취약점 우선순위에 넣습니다. 이후 GitHub Copilot Autofix와 GitHub Copilot cloud agent가 AI-assisted fixes를 생성, 할당, 검증하는 흐름을 맡는다고 설명했습니다. 코드 스캔 결과가 security dashboard에만 머무르지 않고 PR과 issue 단위로 움직이는 그림입니다.

이 지점에서 Anthropic Project Glasswing과 비교할 수 있습니다. Anthropic은 Claude Mythos Preview를 gated access로 열어 critical infrastructure와 open-source maintainer 쪽 방어자를 먼저 지원한다는 메시지를 냈습니다. Microsoft MDASH는 gated frontier model 자체보다 agentic harness, Defender, GitHub Code Security, Patch Tuesday owner를 앞세웁니다. 둘 다 AI가 취약점 발견 속도를 높인다는 전제에서 출발하지만, Microsoft의 발표는 “어떤 모델인가”보다 “finding이 증명되고 수정 워크플로로 들어가는가”에 더 많은 지면을 씁니다.

커뮤니티 반응은 아직 대형 논쟁으로 커지지 않았습니다. Hacker News와 GeekNews에서 MDASH 자체의 활발한 토론은 찾기 어려웠고, Reddit의 r/AZURE, r/SecOpsDaily, r/accelerate에는 100개 이상 specialized agents와 16개 Windows flaws를 요약한 링크 공유가 중심이었습니다. 대신 GeekNews에는 “AI가 두 취약점 문화를 깨뜨리고 있다”, “AI 에이전트 프레임워크 9종의 런타임 보안 현황 분석”, “AI 시대의 코드 리뷰”처럼 AI가 보안 공개, 검증, 리뷰 책임에 주는 압력을 다룬 글들이 이미 올라와 있습니다. MDASH는 그 논의를 Microsoft 내부 보안 공정과 enterprise preview로 가져온 사례입니다.

개발팀이 지금 확인할 첫 번째 항목은 security finding의 evidence format입니다. AI scanner가 만든 report에 affected version, reachable source, sink, exploit precondition, duplicate key, proof artifact, suggested patch, regression test가 없다면 속도는 backlog 증가로 바뀝니다. Microsoft가 debater와 prover를 분리한 이유도 여기에 있습니다. “취약해 보입니다”라는 문장은 maintainer의 시간을 씁니다. “두 UDP packets로 IKEEXT double-free가 재현되고, 이 host policy에서 reachable하며, 같은 ownership pattern의 올바른 구현은 다른 파일에 있습니다”라는 report는 검증 가능한 작업 단위가 됩니다.

두 번째 항목은 production signal입니다. 취약점 severity만으로는 remediation 우선순위가 충분하지 않습니다. 같은 bug class라도 internet-facing service인지, sensitive data path인지, exploit precondition이 기본 설정인지에 따라 순서가 달라집니다. Microsoft가 Defender와 GitHub Code Security 통합에서 internet exposure와 data sensitivity를 언급한 이유입니다. AI가 finding을 많이 만들수록, 조직은 CVSS 점수만이 아니라 runtime context를 remediation queue에 넣어야 합니다.

세 번째 항목은 model portability입니다. Microsoft는 MDASH의 targeting, validation, dedup, prove stages가 model-agnostic이라서 새 모델이 나오면 configuration flip과 A/B test로 panel에 넣을 수 있다고 설명했습니다. AI 보안 도구를 구매하거나 내부 구축하는 팀은 “GPT 계열인가, Claude 계열인가”보다 “scope file, plugin, calibration, historical CVE knowledge가 다음 모델로 넘어가는가”를 봐야 합니다. 6개월마다 모델 이름이 바뀌는 시장에서, 프로젝트별 보안 지식과 proving plugin이 사라지면 도구의 총비용이 올라갑니다.

네 번째 항목은 책임 경계입니다. MDASH가 찾은 16개 CVE는 Microsoft 내부 code owner, MORSE, WARP, Patch Tuesday 공정과 연결됐기 때문에 발표 가능한 보안 결과가 됐습니다. 외부 기업이 비슷한 agentic scanner를 도입해도 maintainer, AppSec, product owner, release manager, customer communication owner가 정해져 있지 않으면 finding은 누군가의 inbox에 쌓입니다. AI 보안 제품의 도입 성공 여부는 scan throughput보다 triage SLA, embargo policy, fix validation, downstream release process에 걸립니다.

다섯 번째 항목은 misuse와 공개 범위입니다. Microsoft 글은 exploitation detail 일부를 제한한다고 적었습니다. 예를 들어 IKEEXT double-free 설명에서 corruption primitive는 말하지만 추가 exploit detail은 공개하지 않는다고 선을 그었습니다. AI가 취약점 경로를 재구성할 수 있는 시대에는 technical transparency와 exploit reproduction 사이의 경계가 더 예민해집니다. 개발 조직도 내부 ticket, prompt log, PoC artifact, crash dump 접근권을 따로 설계해야 합니다. 보안 모델의 출력은 일반 code review comment보다 민감할 수 있습니다.

이번 발표의 실무 결론은 취약점 발견 시장의 비교 기준이 바뀐다는 것입니다. 2024년과 2025년에는 “어떤 모델이 코드를 더 잘 이해하는가”가 앞에 섰습니다. 2026년 MDASH와 Glasswing류 발표는 “발견 뒤 누가 검증하고 고치는가”를 더 크게 만듭니다. Microsoft는 100개 이상 에이전트와 96.55% CyberGym 점수를 내세웠지만, 더 오래 남는 메시지는 Defender, GitHub Code Security, Copilot Autofix, Patch Tuesday로 이어지는 증명 가능한 공정입니다.

앞으로 볼 지표는 세 가지입니다. 첫째, MDASH expanded preview가 private preview에서 어떤 고객군으로 넓어지는지입니다. 둘째, CyberGym 96.55% 같은 benchmark가 실제 enterprise codebase의 false positive, duplicate rate, patch acceptance rate와 얼마나 맞는지입니다. 셋째, Defender와 GitHub Code Security 통합이 개발자의 PR 단위에서 얼마나 적은 마찰로 작동하는지입니다. AI가 취약점을 빨리 찾는다는 사실은 이제 출발점입니다. 보안팀과 개발팀이 확인해야 할 질문은 그 finding이 검증 가능한 증거, 우선순위, 수정 PR, 배포 기록으로 남는가입니다.