Microsoft Windows 취약점 관리는 빨라졌지만 배포는 더디다

Microsoft는 AI를 활용해 Windows 취약점 관리를 가속하고 있지만, 최신 수치는 더딘 마지막 단계를 드러낸다. 바로 수정 사항을 기기에 적용하는 일이다. 회사는 11월 5일 업데이트에서 10월 Windows 보안 업데이트가 1,100건이 넘는 취약점을 해결했다고 밝혔다. 기업 환경 측정 결과에서는 조직이 제공된 보호 조치를 설치하는 데 수 주가 걸리는 것으로도 나타났다.

이는 Microsoft의 엔지니어링 조직과 업무용 컴퓨터를 관리하는 관리자 모두에게 압박을 가한다. 추가적인 취약점을 찾아내는 일은 중요하지만, 영향을 받는 기기가 그대로라면 공개된 수정 사항이 주는 안도감은 제한적이다.

Google의 Big Sleep은 AI 지원 발견의 유용한 역사적 기준점이 된다. Microsoft의 발표는 논의를 더 폭넓은 운영상 질문으로 옮긴다. 발견, 수정, 테스트, 배포가 함께 빨라질 수 있는지에 대한 질문이다.

Windows 취약점 관리는 이제 배포 병목 현상에 직면해 있다

이번 발표의 핵심 쟁점은 보호 조치를 출시하는 일과 이를 설치하는 일 사이의 간극이다.

Microsoft의 취약점 관리 업데이트는 발견, 해결, 검증 전반에서의 AI 지원을 설명한다. 의사 결정과 최종 결과물에 대한 책임은 엔지니어에게 남는다.

회사의 2026년 8월 기업 표본은 후속 단계의 문제를 보여준다. 측정 대상 기기 가운데 절반 미만만이 2주 후 보안 업데이트를 설치했다. 약 4분의 1은 4주 후에도 이를 설치하지 않은 상태였다. Microsoft는 이 측정 결과를 모든 Windows 조직의 전수 조사로 제시하지 않았다.

이 수치는 운영상의 결과를 보여주기 때문에 주목할 만하다. 공격자가 악용할 수 있는 소프트웨어 약점을 뜻하는 취약점은 개발사가 수정 사항을 공개한 뒤에도 계속 중요할 수 있다.

이 구분은 독자가 이번 발표를 해석하는 방식을 바꾼다. 이는 Microsoft의 보안 엔지니어링 프로세스에 관한 업데이트이며, 고객의 더 빠른 배포를 촉구하는 내용이 함께 담겼다. 새로 식별된 모든 문제가 즉시 차단된 공격으로 이어진다는 증거는 아니다.

CVE(Common Vulnerabilities and Exposures) 식별자는 공개된 취약점에 표준화된 참조 번호를 부여한다. 이러한 참조 번호를 집계하면 해결 활동을 설명하는 데 도움이 된다. 하지만 그것만으로 조직에서 얼마나 많은 위험이 사라졌는지는 입증할 수 없다.

따라서 더 큰 월간 합계를 보는 보안 책임자는 몇 가지 별개의 질문을 마주한다. 어떤 취약점이 조직의 시스템에 영향을 주는가? 그 시스템은 어디에서 노출되어 있는가? 어떤 기기가 실제로 적용 가능한 보호 조치를 받았는가?

답은 서로 다른 방향으로 움직일 수 있다. 발견 역량은 개선되는 반면 배포는 여전히 느릴 수 있다. 설치 적용률은 높아질 수 있지만, 중요한 업무용 애플리케이션이 특정 그룹의 업데이트를 계속 막을 수도 있다.

이 때문에 월간 취약점 총수는 분석의 출발점이다. 이를 완전한 성과 점수로 취급하면 서로 다른 엔지니어링 및 운영 문제를 하나의 숫자로 축소하게 된다.

Microsoft에 과제는 관리자가 자신 있게 배포할 수 있는 수정 사항을 만드는 일이다. 고객에게 과제는 출시 발표를 컴퓨터 전반에서 검증된 변경으로 전환하는 일이다.

사무용 노트북, 공동 사용 워크스테이션, 소규모 부서가 사용하는 특수 애플리케이션을 갖춘 가상의 조직을 생각해 보자. 업데이트는 대부분의 노트북에 신속하게 도달하지만, 특수 기기는 호환성 승인을 기다린다.

회사 전체 완료율은 안심이 될 만한 수준으로 보일 수 있다. 그러나 해결되지 않은 해당 부서에는 책임 있는 담당자, 지연 사유에 대한 문서화, 남은 노출에 관한 구체적인 결정이 여전히 필요하다.

이 사례는 Microsoft 고객에 대한 설명이 아니라 이해를 돕기 위한 예시다. 배포 상태를 파악하려면 헤드라인 비율을 넘어선 맥락이 필요한 이유를 보여준다.

핵심 분석 관점의 전환은 완료된 공급업체 작업을 세는 데서 미완료 고객 작업을 살피는 데로 이동하는 것이다. 수정 사항은 영향을 받는 환경에 적용되고 그 환경이 허용 가능한 수준으로 계속 작동할 때 의미 있는 보호가 된다.

따라서 Microsoft AI 취약점 발견은 스캐닝 팀을 넘어선 기대를 높인다. 실행 가능한 발견 사항이 늘어나도, 나머지 프로세스가 이를 처리할 수 있을 때에만 가치가 생긴다.

더 많은 발견 사항은 엔지니어링 팀에 압박을 가한다

발견 역량이 증가할수록 각각의 발견 사항의 품질은 더 중요해진다.

Microsoft 문서는 MDASH를 에이전트형 코드 스캐너로 설명한다. 이는 소프트웨어 약점을 조사하기 위해 전문화된 에이전트를 사용하는 AI 시스템을 뜻한다. 에이전트형 코드 스캐닝 개요는 준비, 스캐닝, 검증, 중복 제거 과정을 설명한다.

문서에 따르면 이 시스템은 코드를 우선순위화하고, 전문 분석을 적용하며, 후보 발견 사항을 평가하고, 반복되는 보고서를 통합한다. 이는 독립적인 성능 측정이 아니라 Microsoft가 자사 시스템을 설명한 내용이다.

이 구조는 자동화된 발견에서 제기되는 실질적인 우려를 다룬다. 엔지니어링 팀에는 의심스러워 보이는 코드 조각이 계속 늘어나는 대신, 조사할 수 있는 설명이 필요하다.

조사 결과 성립하지 않는 보고 문제를 뜻하는 오탐은 유용한 수정 없이 주의를 소모한다. 중복 발견 사항 역시 피할 수 있는 작업을 만든다.

따라서 중요한 질문은 AI 시스템이 설득력 있는 보안 서사를 생성할 수 있는지가 아니다. 증거가 엔지니어가 약점을 확인하고 무엇을 바꿔야 하는지 결정하는 데 도움이 되는지다.

이 구분은 Microsoft AI 취약점 발견을 평가할 때 중요하다. 스캐너의 결과물은 영향받는 제품, 수정 범위, 호환성, 출시 준비 상태에 관한 결정의 상류에 놓인다.

예를 들어, 비정상적인 입력의 안전하지 않은 처리를 가리키는 예시 발견 사항을 상상해 보자. 프로덕션 코드를 바꾸기 전에 검토자는 현실적인 조건에서 해당 입력이 그 위치에 도달할 수 있는지 이해해야 한다.

또한 의도된 동작도 파악해야 한다. 좁은 범위의 수정은 보고된 사례를 해결하면서 관련 경로는 그대로 둘 수 있다. 더 광범위한 수정은 다른 소프트웨어가 의존하는 동작을 방해할 수 있다.

이러한 가능성은 AI가 상당한 지원을 제공하더라도 인간의 책임성이 중요한 이유를 설명한다. 제안된 수정을 검토하려면 그 함의를 이해해야 하며, 그럴듯한 설명을 단순히 받아들이는 것만으로는 충분하지 않다.

같은 논리는 신뢰도 점수에도 적용된다. 점수는 작업의 우선순위를 정하는 데 도움이 될 수 있지만, 근거 자체를 대체하거나 발견 사항의 사업상 중요성을 확정하지는 못한다.

개발자에게 실행 가능한 보고서는 다음 조사 단계를 더 명확하게 해야 한다. 관찰된 동작, 관련 코드, 제안된 수정에 대한 불확실성을 줄여야 한다.

보안 리더에게 유용한 평가는 발견 사항을 프로세스 전반에 걸쳐 추적해야 한다. 수정 대기열이 다음 병목 지점이 된다면 인상적인 발견 시연도 중요한 질문을 남긴다.

이는 확장된 스캐닝에서 도출되는 분석적 함의이지, Microsoft 내부 백로그에 관한 보고된 측정치는 아니다. 검토한 공개 자료만으로는 엔지니어링 팀이 과부하 상태라는 점을 입증할 수 없다.

다만 전체 프로세스의 역량을 살펴볼 이유는 분명히 제시한다. 한 단계를 개선하면 다른 곳의 제약이 드러날 수 있으며, 특히 후속 단계에 전문적인 판단이 필요할 때 그렇다.

조달 측면의 시사점도 직접적으로 이어진다. AI 보안 시스템을 평가하는 구매자는 증거의 품질과 검토자 투입 노력을 포함해 완료된 조사가 어떤 모습인지 물어야 한다.

더 적지만 근거가 탄탄한 발견 사항을 내놓는 제품이 인상적인 원시 총계를 생성하는 제품보다 조직에 더 효과적으로 맞을 수 있다. 이 판단은 이후에 필요한 작업에 달려 있다.

발견을 그것이 가능하게 하는 엔지니어링 의사 결정과 함께 평가할 때 업계 논의는 더 유용해진다.

결함을 찾는 일과 안전한 수정 사항을 출시하는 일은 다르다

더 빠른 조사는 결과 소프트웨어 변경에 대한 신뢰를 유지해야 한다.

Microsoft는 이미 7월에 방향성을 제시했다. 이전의 AI 지원 Windows 서비스 관리 게시물은 수정 및 테스트를 위한 AI 지원과 함께 전용 스캐닝 및 입증 인프라를 설명했다.

이 게시물은 더 폭넓은 검증과 고객 테스트 기회도 설명했다. 이 이력은 11월 발표가 처음으로 AI 지원 Windows 보안을 도입한 것이 아니라, 기존 엔지니어링 프로그램을 이어가는 것임을 보여주기 때문에 중요하다.

기본적인 구분은 간단하다. 발견은 무엇인가 잘못되었는지 묻는다. 수정은 무엇을 바꿔야 하는지 묻는다. 검증은 수정 사항이 문제를 해결하면서 다른 곳에서 허용할 수 없는 결과를 만들지 않는지 묻는다.

기존에 작동하던 동작을 깨뜨리는 변경을 뜻하는 회귀는 원래의 보안 약점과는 다른 문제다. 소프트웨어에 의존하는 조직에는 둘 다 중요하다.

이는 일정 수립에서 절충을 만들지만, 속도와 품질을 무기한 상반된 목표로 취급할 근거가 되지는 않는다. 운영 목표는 출시 결정에 더 이르고 더 강한 증거를 제공하는 것이다.

제안된 수정은 국지적으로 타당해 보여도 더 폭넓은 질문을 제기할 수 있다. 다른 지원 구성에서는 다르게 동작하는가? 종속 애플리케이션이 해당 변경이 제거하는 가정에 의존하는가?

이는 특정 Windows 결함에 대한 설명이 아니라 예시 검토 질문이다. 패치를 자동 생성하는 것만으로 엔지니어링 작업이 완료되지 않는 이유를 보여준다.

이전 지원 소프트웨어 버전에 맞게 조정한 수정을 뜻하는 백포트는 또 다른 차원을 더한다. 원하는 보안 결과는 비슷하게 유지되지만, 주변 구현은 다를 수 있다.

고객의 관점에서 이러한 복잡성은 AI가 수정 사항을 작성한다는 일반적인 설명 뒤에 사라져서는 안 된다. 관리자는 여전히 자신의 환경에서 평가할 수 있는 신뢰할 만한 릴리스가 필요하다.

가장 유용한 증거는 보고된 약점을 제안된 수정 사항 및 적절한 테스트와 연결한다. 검토자는 해당 테스트가 무엇을 입증하며 어떤 부분이 범위 밖에 남는지 이해해야 한다.

통제된 약점 시연을 뜻하는 개념 증명은 이 조사를 뒷받침할 수 있다. 하지만 그것이 최종 수정의 모든 운영상 결과를 자동으로 확정하지는 않는다.

이 지점에서 지식 관리는 이 이야기를 소프트웨어 추천으로 바꾸지 않으면서도 중요해진다. 기술적 증거와 배포 맥락이 분리되면 결정을 검토하기가 더 어려워진다.

메시지에 기록된 예외, 티켓의 호환성 관찰, 회의 메모의 승인은 동일한 미해결 문제를 설명할 수 있다. 누군가는 이를 연결해야 한다.

팀이 적절한 접근 권한과 소유권을 유지한다면 검색 가능한 지식 베이스는 이러한 연속성을 지원할 수 있다. 이는 배포를 담당하는 시스템을 보완한다.

의사결정의 근거를 보존하는 데 실질적인 가치가 있다. 나중에 검토하는 사람은 무엇을 테스트했는지, 어떤 불확실성이 남았는지, 잔여 위험을 누가 수용했는지를 파악할 수 있어야 한다.

이러한 문서는 더 신속한 재검토도 뒷받침한다. 새로운 증거가 나오면 팀은 전체 이력을 다시 구성하지 않고도 이전 판단을 재검토할 수 있다.

더 넓게 보면, AI 지원 수정에도 그에 못지않게 명확한 책임 추적 체계가 필요하다. 엔지니어가 변경 사항이 왜 배포 준비가 되었는지 설명할 수 있을 때 가속화의 신뢰성도 높아진다.

Google의 결과가 AI가 모든 테스트 방식을 대체하지 못하는 이유를 보여준다

AI 지원 탐색에 관한 증거는 각 실험이 실제로 무엇을 측정하는지 세심하게 살피면서 여러 방법을 함께 사용해야 함을 뒷받침한다.

Google은 Big Sleep의 작업에 관한 기술적 설명을 공개했기 때문에 관련 비교 사례를 제공한다. 이 비교는 Windows 제품의 직접적인 벤치마크가 아니라 연구 방법에 관한 것이다.

Project Zero는 2024년 SQLite 취약점 발견 설명에서 공식 릴리스에 포함되기 전에 수정된 AI 발견 취약점을 소개했다. 팀은 결과가 실험적 성격을 지닌다는 점도 강조했다.

이 사례는 매력적인 방어적 결과를 보여준다. 릴리스 전에 문제를 수정하면 하위 사용자들이 해당 결함에 대한 수정 사항을 설치할 필요가 없어진다.

동시에 맥락이 중요한 이유도 보여준다. 한 프로젝트에서 성공한 조사가 운영 체제, 애플리케이션 또는 취약점 범주 전반의 일반적인 성공률을 입증하는 것은 아니다.

Google의 2026년 10월 퍼징 비교는 더 신중한 관점을 제시한다. 퍼징은 예상치 못한 동작을 찾아내기 위해 생성된 입력값으로 소프트웨어를 테스트하는 방식이다.

역사적 실험에서 BigSleep은 원래 버그의 약 62%를 재발견했다. Project Zero는 특화된 퍼징과 AI 에이전트가 여전히 상호 보완적이라고 결론지었다.

이러한 결과는 MDASH를 측정한 것이 아니며, Microsoft 성능 데이터로 제시해서도 안 된다. 다만 유능한 AI 조사자가 기존 테스트를 불필요하게 만든다는 단순한 가정에는 의문을 제기한다.

이 구분은 엔터프라이즈 구매자에게 유용하다. 시연은 시스템이 어려운 문제를 찾아낼 수 있음을 보여줄 수 있다. 그러나 다른 방법이 찾아낼 모든 문제를 시스템이 안정적으로 포괄한다는 점까지 입증할 수는 없다.

따라서 평가 설계가 중요하다. 검토자는 시작 정보, 허용된 도구, 대상 소프트웨어, 그리고 조사를 성공으로 판정하는 기준을 이해해야 한다.

유용한 시작 단서가 있는 테스트는 낯선 코드베이스 전반을 대상으로 한 개방형 탐색과는 다른 질문에 답한다. 둘 다 가치 있을 수 있지만, 결과는 구별되어야 한다.

이전에 알려지지 않은 취약점을 찾는 것과 알려진 과거 버그를 재발견하는 것 사이에도 차이가 있다. 과거 테스트는 비교를 뒷받침하지만, 실제 배포는 추가적인 불확실성을 수반한다.

어느 구분도 연구의 타당성을 훼손하지 않는다. 대신 기술적 결과가 증거가 뒷받침하는 범위를 넘어선 더 광범위한 주장으로 확대되는 일을 막는 데 도움이 된다.

Windows 취약점 관리에서의 함의는 AI를 엔지니어링 시스템의 일부로 평가해야 한다는 것이다. 유용한 질문은 적용 범위, 증거, 수정 품질, 기존 테스트와의 상호작용에 관한 것이다.

핵심 불확실성은 AI가 취약점 연구에 기여할 수 있는지 여부가 아니다. 검토한 사례들은 기여할 수 있음을 입증한다. 아직 해결되지 않은 문제는 이러한 기여가 종단 간 결과를 얼마나 일관되게 개선하는가이다.

Microsoft의 공개 설명은 AI가 이제 여러 단계를 지원한다는 주장을 뒷받침한다. 그러나 각 단계가 얼마나 개선되었는지 입증하는 통제된 비교 자료는 제공하지 않는다.

독립적인 평가는 발견의 개선과 수정 시간 또는 배포된 보호의 개선을 구별하는 데 도움이 될 것이다. 이 결과들은 서로 관련되어 있지만, 서로 다른 측정이 필요하다.

이것이 이 이야기에 적절한 회의적 입장이다. 문서화된 활동은 받아들이되, 공급업체의 주장은 출처를 밝히고, 측정되지 않은 이점은 확립된 결과와 분리해야 한다.

또한 이는 Microsoft와 Google 사이에 인위적인 경쟁 구도를 만드는 일을 피한다. 양사의 공개 설명은 서로 다른 시스템과 환경에 관한 것이므로, 수치 순위는 독자를 오도할 수 있다.

더 빠른 Windows 패치 배포에는 여전히 운영상의 신뢰가 필요하다

관리자에게는 신뢰성 우려를 해소하는 증거를 포함해 더 빠른 의사결정으로 이어지는 신뢰할 만한 경로가 필요하다.

Microsoft의 Windows 업데이트 정책 지침은 디바이스가 최신 상태로 간주되려면 3일 이내에 설치할 것을 권고한다. 3일에서 7일 사이의 디바이스는 노출 상태로 분류한다.

같은 논의에는 애플리케이션 중단과 압축된 테스트 일정에 대한 관리자들의 우려도 포함되어 있다. 이러한 의견은 대표성 있는 설문 증거가 아니라 개별 경험담이다.

그 중요성은 드러나는 충돌에 있다. 보안 권고는 명확할 수 있지만, 조직이 이를 따를 수 있는 능력은 여전히 운영상의 책임으로 인해 제약을 받을 수 있다.

기업은 보호와 정상 작동하는 시스템 모두에 의존한다. 배포 시점을 결정하는 관리자는 지연의 결과와 실패한 변경의 결과를 함께 고려해야 한다.

책임과 증거가 명시적일 때 이 결정은 쉬워진다. 보안 팀이 긴급성을 요청하는 반면 애플리케이션 소유자에게 호환성 우려를 보고할 정해진 방식이 없으면 더 어려워진다.

따라서 Windows 패치 배포에는 기술뿐 아니라 거버넌스도 포함된다. 누군가는 진행을 승인하고, 롤아웃을 일시 중지하며, 문제를 조사하고, 예외가 언제 만료되는지 결정할 권한을 가져야 한다.

더 광범위한 대상 집단보다 먼저 업데이트를 받는 정의된 그룹을 의미하는 배포 링은 이 과정을 체계화할 수 있다. 그 유용성은 조직이 해당 그룹으로부터 무엇을 학습하는지에 달려 있다.

중요한 애플리케이션을 놓치는 초기 그룹은 해당 애플리케이션에 대해 제한적인 증거만 제공한다. 설치가 성공했더라도 영향을 받은 워크플로가 계속 정상적으로 작동하는지에 대한 의문은 남는다.

이는 Microsoft 고객이 보편적으로 비효율적인 테스트를 사용한다는 주장이 아니라 롤아웃 설계에 관한 분석적 관찰이다. 조직마다 애플리케이션, 인력 수준, 서비스 요구 사항이 다르다.

실질적인 긴장은 유용한 증거가 얼마나 빨리 확보되는가에 관한 것이다. 조사를 담당하는 사람이 없다면 더 오래 기다린다고 해서 자동으로 더 나은 증거가 만들어지는 것은 아니다.

반대로 기한을 단축한다고 해서 확인된 호환성 문제가 해결되지는 않는다. 기한은 아직 마무리되지 않은 결정을 드러낼 수 있지만, 결국 누군가는 그 결정을 내려야 한다.

이 때문에 배포 보고서는 실행을 지원해야 한다. 팀이 차단 요인, 책임 소유자, 다음 검토 시점을 파악할 수 있을 때 남은 디바이스 수는 더 유용해진다.

같은 논리는 예외에도 적용된다. 상황이 바뀐 뒤 아무도 다시 검토하지 않는 상세한 설명은 조직에 거의 도움이 되지 않는다.

지식 근로자에게 미치는 영향은 더 직접적이다. 업데이트 중단과 애플리케이션 문제는 업무 완료 능력에 영향을 주며, 보호가 지연되면 조직의 위험은 해결되지 않은 채 남는다.

명확한 커뮤니케이션은 이러한 우려를 연결하는 데 도움이 된다. 직원들은 언제 조치가 필요한지, 더 광범위한 롤아웃에 영향을 줄 수 있는 문제를 어떻게 보고해야 하는지 알 때 이점을 얻는다.

엔터프라이즈 구매자에게 이 발표는 AI 기능과 함께 운영 적합성을 평가할 이유를 제공한다. 관련 제품 경험에는 보고, 조사, 책임성, 복구가 포함된다.

압박은 공동의 것이다. Microsoft는 릴리스 품질을 통해 배포 신뢰를 얻어야 한다. 조직은 그 신뢰가 증거로 뒷받침될 때 신속히 대응할 수 있는 프로세스를 마련해야 한다.

더 빠른 Windows 패치 배포는 이러한 책임이 함께 작동하도록 만드는 데 달려 있다.

다음 릴리스는 설치된 보호 수준으로 평가해야 한다

가장 강력한 후속 증거는 발견, 릴리스 품질, 고객 배포 결과를 연결할 것이다.

Microsoft의 발표가 주장된 모든 이점을 입증하기 위한 별도의 기한을 정한 것은 아니지만, 향후 몇 달은 유용한 관찰 기간을 제공한다.

첫 번째 신호는 릴리스 이후의 배포 적용 범위다. 독자는 영향을 받은 디바이스가 업데이트를 얼마나 빨리 받는지 보여주는 비교 가능한 측정치를 Microsoft가 공개하는지 지켜봐야 한다.

보기 좋은 비율보다 비교 가능성이 더 중요하다. 표본이나 측정 방법이 바뀌면 겉보기 진전은 해석하기 어려워질 수 있다.

일관된 측정 기준 아래 적용 범위가 개선되면 운영상의 보호가 엔지니어링 속도를 따라잡고 있다는 근거가 강화된다. 변화가 거의 없다면 배포는 눈에 띄는 제약으로 남을 것이다.

두 번째 신호는 릴리스 신뢰성과 배포 차단 요인의 처리다. 독자는 보고된 문제가 고립된 사례인지, 이해되고 있는지, 신속히 해결되는지를 설명하는 증거를 찾아야 한다.

일시적인 문제가 자동으로 가속화된 엔지니어링의 신뢰를 훼손하는 것은 아니다. 그 중요성은 영향을 받는 환경, 실질적 결과, 대응의 품질에 달려 있다.

지속되는 차단 요인은 고객이 일정을 안전하게 압축할 수 있다는 주장을 약화시킬 것이다. 명확한 해결책과 이해하기 쉬운 지침은 더 빠른 롤아웃 결정에 대한 신뢰를 뒷받침할 것이다.

세 번째 신호는 수정 프로세스 자체에 관한 증거다. 유용한 공개는 AI 지원 발견 사항과 완료된 수정을 구분하고, 엔지니어가 그 결과 변경을 어떻게 평가하는지 설명할 것이다.

취약점 총수만 늘어난다고 해서 이러한 질문에 답할 수는 없다. 더 상세한 보고는 지원이 어디에서 작업량을 줄이고, 어디에서 인간 검토가 여전히 결정적인지 독자가 이해하는 데 도움이 된다.

이 신호들은 함께 고려해야 한다. 발견 결과가 강하더라도 배포가 느리면 노출은 해결되지 않는다. 허용할 수 없는 중단을 수반하는 빠른 배포는 이후 릴리스에 필요한 신뢰를 약화시킨다.

바람직한 결과는 뒷받침된 수정을 만들고 이를 관련 디바이스에 적용하는 반복 가능한 프로세스다. 이 결과에는 공급업체와 고객 환경 모두의 증거가 필요하다.

이 프레임워크는 개발자와 보안 구매자에게 향후 발표를 평가할 실용적인 방법도 제공한다. 어떤 단계가 개선되었는지, 어떤 측정이 주장을 뒷받침하는지, 그 이후 어떤 일이 있었는지 물어야 한다.

Microsoft의 발표는 Windows 취약점 관리를 더 폭넓은 운영 이야기로 만든다. AI는 결함 탐색을 확장할 수 있지만, 공공의 가치는 그 뒤따르는 결정과 설치에 달려 있다.

다음 보안 검토에서는 최근 Windows 업데이트를 릴리스부터 배포까지, 아직 대기 중인 디바이스를 포함해 추적하라. 어떤 증거가 승인을 뒷받침했는지, 어떤 차단 요인이 해결되지 않았는지, 각 예외를 누가 담당하는지 파악하라. 각 측정값이 명확한 질문에 답하도록 발견 총계와 설치 적용 범위를 분리하라. 그런 다음 지연의 설명을 이를 해결하는 데 필요한 정보와 비교하라. 달력상의 기한은 팀이 그로 인해 드러난 결정에 행동할 수 있을 때만 유용하다. 조직에 다시 가져갈 질문은 구체적이다. 검증된 수정 사항을 사용할 수 있게 되었을 때, 영향을 받은 디바이스가 실제로 보호를 받는 속도를 결정하는 것은 무엇인가?