Windows 취약점 16개, MDASH가 바꾼 보안 AI의 병목

AI 요약

• 무슨 일: Microsoft가 MDASH를 공개하며 100개 이상 전문 에이전트가 Windows 취약점 16개를 찾았다고 밝혔습니다.
  • 대상은 tcpip.sys, ikeext.dll, http.sys, netlogon.dll, dnsapi.dll 등이며 4개는 Critical RCE로 설명됐습니다.
• 의미: 보안 AI의 차별점이 단일 모델 점수에서 검증, 반박, 증명, 패치 루프를 묶는 하네스로 이동합니다.
• 개발자 영향: AI 보안 도구를 평가할 때 "어떤 모델인가"보다 "어떤 증거가 남고 누가 triage 비용을 감당하는가"를 봐야 합니다.
• 주의점: Microsoft 수치는 강하지만 내부 코드와 특정 벤치마크 맥락이 섞여 있어, 일반 조직의 재현 가능성은 별도 검증이 필요합니다.

Microsoft가 2026년 5월 12일 Security Blog에서 codename MDASH를 공개했습니다. 이름은 Multi-Model Agentic Scanning Harness의 약자입니다. 발표 문장만 보면 또 하나의 AI 보안 제품처럼 보일 수 있습니다. 하지만 이번 뉴스의 핵심은 "AI가 취약점을 찾았다"가 아닙니다. 더 정확히는 "취약점 후보를 찾는 AI"가 "Patch Tuesday에 들어갈 수 있는 증명된 보안 엔지니어링 흐름"으로 이동했다는 신호입니다.

Microsoft의 설명에 따르면 MDASH는 Windows 네트워킹 및 인증 스택에서 16개 CVE를 찾는 데 사용됐습니다. 이 중 4개는 Critical 원격 코드 실행 취약점으로 분류됐습니다. 공개된 대상에는 tcpip.sys, ikeext.dll, http.sys, netlogon.dll, dnsapi.dll, telnet.exe가 포함됩니다. 10개는 kernel-mode, 6개는 user-mode였고, 다수는 네트워크 위치에서 자격 증명 없이 도달 가능한 경로였다고 Microsoft는 설명합니다.

숫자도 공격적입니다. Microsoft는 비공개 테스트 드라이버에 심은 취약점 21개를 MDASH가 모두 찾았고 false positive가 없었다고 밝혔습니다. 또 5년 동안의 MSRC 확정 사례를 기준으로 clfs.sys에서는 96% recall, tcpip.sys에서는 100% recall을 기록했다고 말합니다. CyberGym 1,507개 real-world vulnerability task에서는 88.45%를 얻어 공개 리더보드에서 최상위였다고 설명합니다.

여기까지만 읽으면 "더 똑똑한 보안 모델" 이야기로 흘러가기 쉽습니다. 그러나 Microsoft가 반복해서 강조하는 문장은 다릅니다. 모델은 입력 중 하나이고, 제품은 시스템이라는 것입니다. MDASH의 뉴스 가치는 바로 이 문장에 있습니다. 보안 AI의 병목은 이제 모델이 취약점 냄새를 맡느냐가 아니라, 그 냄새를 누가 반박하고, 누가 중복을 제거하고, 누가 실제 trigger를 만들고, 누가 Patch Tuesday에 들어갈 증거로 바꾸느냐입니다.

단일 모델이 아니라 역할 분리입니다

MDASH의 구조는 prepare, scan, validate, dedup, prove 단계로 설명됩니다. Prepare 단계는 소스 타깃을 받아 언어 인덱스를 만들고, 과거 commit을 보며 attack surface와 threat model을 그립니다. Scan 단계는 auditor agent가 후보 코드 경로를 훑어 가설과 증거를 냅니다. Validate 단계에서는 별도 agent들이 각 finding의 reachability와 exploitability를 두고 찬반 토론을 합니다. Dedup 단계는 의미적으로 같은 finding을 접고, prove 단계는 가능한 버그 클래스에 대해 실제 trigger 입력을 만들고 실행합니다.

이 설계는 일반적인 "LLM에게 코드 전체를 주고 취약점을 찾아보라"와 거리가 있습니다. Microsoft는 MDASH가 100개 이상 specialized agents를 갖고 있다고 설명합니다. Auditor는 debater처럼 추론하지 않고, debater는 prover처럼 행동하지 않습니다. 각 단계마다 역할, prompt regime, 도구, stop criteria가 다릅니다. 한 프롬프트가 모든 일을 하도록 기대하지 않는다는 점이 중요합니다.

이 구조가 필요한 이유는 취약점이 대부분 한 줄짜리 실수로 보이지 않기 때문입니다. Microsoft가 공개한 CVE-2026-33827은 tcpip.sys의 use-after-free입니다. 단순히 같은 함수 안에서 free 후 use가 보이는 유형이 아니라, reference ownership과 concurrent cleanup path, SSRR option 처리, path cache lifecycle이 얽힙니다. Microsoft는 단일 모델 harness가 이런 버그를 놓치기 쉬운 이유로 release와 later reuse가 중간 control flow에 의해 분리되고, 결정적 신호가 다른 파일의 "올바른 패턴"과 비교해야 드러난다는 점을 듭니다.

CVE-2026-33824도 비슷합니다. IKEEXT 서비스에서 shallow copy가 heap allocation ownership을 제대로 복제하지 않아 double-free로 이어지는 경로입니다. 문제는 여섯 개 파일에 걸쳐 나타납니다. 하나의 파일만 읽는 분석기는 aliasing lifecycle의 전체 흐름을 보기 어렵습니다. 반대로 MDASH는 cross-file pattern comparison, reachability analysis, debate, proof construction을 이어 붙입니다. 이 지점에서 "에이전트"라는 단어는 마케팅 문구가 아니라 작업 분해 방식에 가깝습니다.

보안팀이 싫어하는 것은 후보 목록입니다

취약점 발견 도구의 실무 병목은 false positive입니다. 보안팀은 이미 backlog가 많습니다. 정적 분석 도구, dependency scanner, pentest report, bug bounty, 고객 제보, 내부 red team 결과가 모두 triage queue로 들어옵니다. AI가 후보를 더 많이 뱉는다고 보안 상태가 좋아지는 것은 아닙니다. 오히려 소유자 지정, 재현, severity 판단, exploitability 검증, patch 우선순위 조정 비용이 늘어날 수 있습니다.

Microsoft가 MDASH에서 validate와 prove를 크게 강조하는 이유가 여기에 있습니다. Scan 단계의 finding은 아직 보안 결과물이 아닙니다. Debater가 반박하고, dedup이 중복을 접고, prover가 trigger를 만들며, 도메인 플러그인이 시스템별 invariant를 주입해야 비로소 "고칠 수 있는 취약점"이 됩니다. Microsoft는 CLFS proving plugin을 예로 듭니다. 많은 CLFS finding은 흥미로워 보이지만 실제 triggering log file을 구성하지 못하면 triage backlog에 그칩니다. 플러그인은 on-disk container layout, block validation sequence, in-memory state machine을 알고 있어 candidate path를 sink까지 몰고 갑니다.

이 대목은 AI 보안 도구를 사거나 만들려는 팀에게 실용적인 기준을 줍니다. "모델이 취약점을 찾아준다"는 말은 충분하지 않습니다. 어떤 source indexing을 하는지, project-specific rule을 넣을 수 있는지, 후보를 반박하는 별도 단계가 있는지, proof-of-concept를 만들 수 있는 bug class가 어디까지인지, 결과를 기존 ticketing과 patch process에 어떻게 붙이는지가 더 중요합니다. 보안 AI의 가격은 API token만으로 계산되지 않습니다. 잘못된 finding 하나가 senior security engineer의 반나절을 태울 수 있기 때문입니다.

Patch Tuesday에 들어갔다는 점이 큽니다

이번 발표에서 가장 흥미로운 부분은 벤치마크보다 Patch Tuesday입니다. 벤치마크는 중요하지만, 조직 내부 운영 체계와 분리될 수 있습니다. 반면 Patch Tuesday는 Microsoft 보안 프로세스의 실제 출하 지점입니다. 취약점은 owner가 있어야 하고, severity가 매겨져야 하며, 재현과 수정과 회귀 검증을 거쳐야 합니다. 고객이 받을 advisory와 update package로 이어져야 합니다.

MDASH가 찾은 16개 CVE가 이 흐름에 들어갔다는 것은, AI가 단순한 research assistant가 아니라 보안 엔지니어링 파이프라인의 입력으로 쓰였다는 뜻입니다. 물론 사람의 검토와 Microsoft 내부 프로세스가 빠졌다는 의미는 아닙니다. 오히려 반대입니다. AI finding이 실제 보안 업데이트로 이어지려면 사람과 프로세스가 더 많이 필요합니다. 그래서 이번 사건은 "AI가 보안 연구자를 대체했다"보다 "AI가 보안 연구자의 단위를 바꿨다"에 가깝습니다.

TechRadar도 5월 14일 보도에서 MDASH가 100개 이상 AI 에이전트를 조율해 16개 flaws를 찾았고, 그중 일부는 원격 인증 전 경로에서 도달 가능하다는 점을 강조했습니다. 커뮤니티 반응은 아직 넓게 형성된 상태는 아니지만, Reddit의 Azure 관련 토론에서는 IKEv2 LocalSystem RCE와 disclosure timeline 문제가 주로 언급됩니다. AI가 방어자에게 취약점을 더 빨리 찾아준다면 공격자도 patch diff, advisory, proof pattern을 더 빨리 weaponize할 수 있다는 질문입니다.

이 질문은 과장으로만 볼 수 없습니다. AI 취약점 탐지가 생산 단계에 들어오면, 90일 disclosure 같은 기존 리듬도 압력을 받습니다. 방어자는 더 빨리 찾아 더 빨리 고쳐야 하고, 공격자는 같은 도구적 이점을 악용할 수 있습니다. MDASH의 존재는 "AI 보안 도구를 쓰면 안전해진다"보다 "보안 경쟁의 clock speed가 올라간다"는 신호에 가깝습니다.

CyberGym 88.45%를 어떻게 읽어야 하나

Microsoft는 CyberGym에서 88.45%를 얻었다고 밝혔습니다. CyberGym은 real-world vulnerability reproduction task를 통해 defensive cyber workflow와 vulnerability-oriented agent performance를 평가하는 벤치마크입니다. Microsoft 설명에 따르면 이 평가는 188개 OSS-Fuzz 프로젝트에서 뽑은 1,507개 task를 대상으로 했고, vulnerable source code와 high-level vulnerability description이 제공되는 default level 1 설정에서 진행됐습니다.

그런데 이 숫자는 조심해서 읽어야 합니다. Microsoft 발표는 "public CyberGym benchmark"와 "published leaderboard at the time of writing"이라고 표현하지만, 외부 미러인 BenchLM의 2026년 5월 13일 스냅샷은 Claude Mythos Preview 83.1%, GPT-5.5 81.8%, GPT-5.4 79.0%를 표시합니다. 이것이 Microsoft 발표를 반박한다는 뜻은 아닙니다. 리더보드 반영 시점, 평가 범위, 엔트리 표시 방식이 다를 수 있습니다. 다만 기사에서는 88.45%를 독립적으로 확정된 범용 모델 순위처럼 쓰기보다 "Microsoft가 공개한 MDASH 평가 수치"로 다루는 편이 안전합니다.

더 중요한 것은 Microsoft의 실패 분석입니다. 남은 약 12% 실패 중 wrong code area를 타깃한 사례의 82%는 설명이 모호하고 function 또는 file identifier가 부족한 task에서 나왔다고 합니다. 또 일부는 libFuzzer-style input을 만들었지만 실제 benchmark harness가 honggfuzz-format input을 요구해 실패했습니다. 이 실패 유형은 매우 현실적입니다. AI 에이전트의 한계가 "추론을 못 한다"가 아니라 "문제 정의와 harness contract가 틀어지면 맞는 답도 실패한다"로 나타납니다.

OpenAI Daybreak와 다른 메시지

최근 OpenAI는 Daybreak와 Codex Security 흐름을 통해 사이버 방어용 프런티어 AI를 전면에 내세웠습니다. Daybreak의 메시지는 모델 접근권한, trusted access, 보안 파트너 생태계, Codex agentic harness를 묶는 방향이었습니다. Microsoft MDASH는 조금 다른 면을 보여줍니다. 여기서는 "방어자에게 어떤 모델을 열어줄 것인가"보다 "대규모 소프트웨어 회사가 AI finding을 어떻게 보안 업데이트 공장에 넣을 것인가"가 핵심입니다.

두 흐름은 경쟁하면서도 같은 결론으로 수렴합니다. 보안 AI의 제품성은 단일 프롬프트나 단일 모델 이름에서 나오지 않습니다. OpenAI는 접근권한과 파트너 통합을 강조하고, Microsoft는 내부 codebase, Patch Tuesday, proof plugin, model ensemble을 강조합니다. Anthropic이나 다른 모델 제공사가 더 강한 cyber model을 내더라도, 실무 조직은 결국 같은 질문으로 돌아갑니다. 이 모델이 내 코드와 내 운영 절차와 내 감사 요구사항 안에서 어떤 증거를 남기는가입니다.

이 관점에서 MDASH는 "Microsoft가 또 하나의 보안 제품을 냈다"보다 "AI 보안 도구의 평가 기준을 바꿨다"에 가깝습니다. 앞으로 보안 AI vendor의 데모는 취약점 후보를 보여주는 것으로 부족해질 것입니다. 발견한 finding이 왜 reachable한지, 어떤 반박을 통과했는지, 어떤 PoC나 sanitizer evidence가 있는지, 어떤 patch candidate가 회귀 테스트를 통과했는지, 어떤 사람에게 어떤 권한으로 넘어갔는지를 보여줘야 합니다.

개발팀이 지금 가져갈 질문

대부분의 개발팀은 MDASH 같은 내부 보안 하네스를 당장 만들 수 없습니다. Microsoft는 거대한 proprietary codebase, MSRC case history, Patch Tuesday process, 전문 보안 연구자, 도메인 플러그인을 갖고 있습니다. 이 조건을 일반 스타트업이나 엔터프라이즈 개발팀이 그대로 복제하기는 어렵습니다. 하지만 이번 발표에서 가져갈 운영 원칙은 있습니다.

첫째, AI 보안 스캔 결과를 곧바로 ticket으로 쌓지 말아야 합니다. 후보 finding과 검증된 finding을 구분해야 합니다. 둘째, agent workflow에는 반박 단계가 필요합니다. 같은 모델이 낸 finding을 같은 모델이 검증하는 구조는 유혹적이지만, 실제 triage 비용을 줄이기 어렵습니다. 셋째, proof 가능성을 product requirement로 봐야 합니다. 모든 취약점이 자동 PoC로 증명되는 것은 아니지만, 적어도 어떤 bug class에서 어떤 dynamic evidence를 만들 수 있는지 명확해야 합니다. 넷째, 도메인 지식은 prompt에만 넣을 것이 아니라 플러그인, rule, CodeQL database, sanitizer harness, test fixture 같은 형태로 시스템에 남겨야 합니다.

이것은 AI coding agent에도 그대로 적용됩니다. 코드 작성 에이전트가 늘면서 보안 review agent도 늘어납니다. 그러나 review comment가 많아진다고 품질이 올라가지 않습니다. 중요한 것은 comment가 build, test, repro, exploitability, ownership, merge gate와 연결되는지입니다. 보안 AI의 진짜 경쟁은 더 많은 경고를 만드는 쪽이 아니라, 조직이 고칠 수 있는 경고만 남기는 쪽으로 갈 가능성이 큽니다.

아직 남은 빈칸

MDASH 발표는 강하지만, 공개 정보만으로는 몇 가지를 알 수 없습니다. Limited private preview가 어떤 제품 경계로 제공되는지, 고객 코드가 어떤 환경에서 처리되는지, 어떤 모델이 어떤 단계에 쓰이는지, domain plugin을 고객이 직접 만들 수 있는지, 자동 patch 생성이 실제 고객 환경에서 어디까지 지원되는지는 명확하지 않습니다. 또한 Microsoft 내부 코드와 MSRC history를 기반으로 한 수치가 외부 조직의 다양한 언어, framework, legacy system에서도 같은 효과를 낼지는 별도 문제입니다.

그럼에도 이번 발표의 방향은 분명합니다. 취약점 탐지는 점점 에이전트 시스템 문제가 됩니다. 모델은 계속 강해지겠지만, 보안팀이 돈을 내는 것은 모델이 아니라 운영 결과입니다. 후보를 줄이고, 증거를 남기고, 패치를 통과시키고, 감사 가능한 기록을 만드는 흐름입니다. MDASH가 흥미로운 이유는 Windows 취약점 16개라는 숫자뿐 아니라, 그 숫자가 프롬프트 데모가 아니라 실제 보안 업데이트 루프와 연결됐기 때문입니다.

AI 보안의 다음 질문은 "어느 모델이 제일 잘 찾는가"에서 "어느 하네스가 finding을 고칠 수 있는 일로 바꾸는가"로 바뀌고 있습니다. Microsoft MDASH는 그 전환을 가장 직접적으로 보여준 사례입니다.