AI 버그 헌터가 검토 대기열을 몰아넣으면서 벌어진 Apple과 Google의 보안 격차

AI 버그 헌터가 Apple의 취약점 접수 절차의 약점을 드러내면서 Apple과 Google의 보안 전략은 새로운 국면에 들어섰다. 보도에 따르면 Apple은 머신 생성 결과물이 검토 역량을 압박하자 활성 제출 건수를 제한했다.

당면한 문제는 단순한 오탐 보고가 아니었다. 이탈리아 보안 기업 Bynario의 연구진은 자동화 워크플로가 훨씬 많은 발견 결과 속에서 실제 macOS 권한 부여 결함을 찾아냈다고 밝혔다. 이 회사는 결국 root 권한으로 파일을 생성할 수 있는 공격 경로를 검증했다.

Apple은 2026년 7월 이 취약점을 패치했다. 그러나 이 사례는 결함을 찾아내는 일과 신뢰할 수 있는 사람이 이를 평가하는 일 사이에 존재하는 더 넓은 운영상 격차를 드러냈다. Google은 Project Zero와 AI 시스템 Big Sleep을 중심으로 이 검증 계층을 구축하는 데 수년을 투자해 왔다.

이것이 핵심적인 역전이다. AI는 벤더가 더 많은 코드를 점검하도록 도울 것으로 예상됐지만, 외부 연구자들이 벤더의 처리 속도보다 더 빠르게 보고서를 만들어낼 수 있게도 했다. 병목은 발견 단계에서 검증, 우선순위 결정, 패치 배포 단계로 이동했다.

Apple에 이 변화는 단일 macOS 결함을 넘어선 압박을 만든다. 보안 프로그램은 정당한 보고를 막지 않으면서 가치 있는 AI 보조 연구와 그럴듯하지만 틀린 제출물을 구분해야 한다. Google의 접근법은 하나의 모델을 제시하지만, 여전히 전문가 검토에 크게 의존한다.

패치된 Mac 결함이 드러낸 더 큰 접수 문제

중요한 변화는 자동화된 발견이 사람의 보고 물량에 맞춰 설계된 취약점 절차와 충돌했다는 점이다.

Bynario는 Apple이 관련 업데이트를 배포한 지 이틀 뒤인 7월 29일 기술 분석 내용을 공개했다. 연구진은 macOS Screen Sharing에서 서로 연관된 두 가지 권한 부여 문제를 식별하고 이를 CVE-2026-43760으로 묶었다.

이 결함은 Virtual Network Computing, 즉 VNC가 사용하는 레거시 인증 경로에 영향을 미쳤다. VNC는 원격 사용자가 다른 컴퓨터의 화면을 보고 제어할 수 있게 하는 프로토콜이다.

악용에는 여러 조건이 필요했다. Screen Sharing 또는 Remote Management가 활성화되어 있어야 했다. 레거시 VNC 비밀번호 옵션도 구성되어 있어야 했고, 공격자는 해당 비밀번호를 알아야 했다.

이러한 조건 때문에 이 결함은 인증되지 않은 제로클릭 공격보다 범위가 좁다. 그렇다고 중요성이 사라지는 것은 아니다. VNC 비밀번호는 화면 제어를 승인하기 위한 것이지, 권한 있는 파일 시스템 접근을 승인하기 위한 것은 아니었다.

연구진은 macOS가 기본 Apple 인증과 레거시 VNC 인증을 서로 다르게 처리한다는 점을 발견했다. 기본 세션은 활동을 인식된 macOS 사용자와 연결했다. 반면 레거시 경로는 같은 사용자 ID를 제공하지 않았다.

해당 ID가 없을 때 파일 복사 도우미는 root 권한을 유지했다. 따라서 원격 뷰어는 보호된 파일을 요청하거나 권한 있는 위치에 공격자가 제어하는 파일을 생성할 수 있었다.

macOS 익스플로잇 분석에서 Bynario는 보호된 구성 디렉터리 내부에 정책 파일을 배치한 과정을 설명했다. 이 파일은 비밀번호 없는 관리 명령을 활성화했으며 원격 root 명령 실행 시연을 뒷받침했다.

연구진은 System Integrity Protection이 활성화된 최근 Apple silicon 시스템에서 이 동작을 테스트했다. 이 결함은 메모리 손상 익스플로잇이 아니라 권한 부여 오류였기 때문에 Apple의 메모리 보호 기능을 우회하지는 않았다.

이 구분은 중요하다. 현대적 방어 체계는 버퍼 오버플로와 위조된 포인터의 악용을 어렵게 만들 수 있다. 하지만 잘못된 ID로 권한 있는 작업을 수행하는 정당한 시스템 구성 요소까지 막을 수는 없다.

Apple의 권고문은 민감한 사용자 데이터에 접근할 가능성이 있다고 더 절제된 표현을 사용했다. Bynario는 이 설명이 권한 있는 파일 생성이 초래하는 전체 영향을 포착하지 못한다고 주장했다.

공개된 설명은 심각도 측면에서도 차이를 보였다. Apple의 권고문과 연구진의 평가는 서로 다른 점수와 가정을 적용했다. 이러한 불일치는 자동화된 레이블을 받아들이는 것 이상으로 검증이 필요한 이유를 뒷받침한다.

Apple은 7월 27일 macOS Tahoe 26.6 및 Sonoma 14.8.8에서 이 문제를 수정했다. 회사의 보안 업데이트는 이번 릴리스에서 해결된 여러 취약점에 대해 외부 연구자들에게 공을 돌렸다.

사용자에게 실질적인 대응은 명확하다. 최신 macOS 업데이트를 설치해야 한다. 업데이트할 수 없는 조직은 레거시 VNC 비밀번호 옵션을 비활성화하거나, 필요하지 않을 때 Screen Sharing을 꺼야 한다.

더 큰 이야기는 패치 이전부터 시작된다. 보도에 따르면 Bynario 연구진은 수주 동안 이미 수십 건의 발견 결과를 제출했다. 이후 활성 보고 건수 제한으로 인해 잠재적으로 심각한 또 다른 문제를 즉시 제출할 수 없게 됐다.

Apple은 이후 연구진에게 연락해 결함을 조사했다. 이 조치는 패치로 이어지는 데 도움이 됐지만, 정상적인 접수 경로의 예외 처리에 의존했다. 확장 가능한 보안 프로그램은 대기열이 연구 결과 접수를 중단한 뒤 연구자에게 개별적인 관심이 제공되는 방식에 의존할 수 없다.

AI 버그 헌터가 인간 검토를 압도하는 이유

AI 버그 헌터는 검증의 경제성을 개선하는 속도보다 더 빠르게 발견의 경제성을 바꾼다.

전통적인 취약점 연구는 사람의 시간 측면에서 비용이 많이 든다. 연구자는 코드베이스를 분석하고, 가설을 세우며, 이를 테스트하고, 잘못된 단서를 제거한 뒤 재현 가능한 보고서를 작성한다.

AI는 이 과정의 일부를 압축할 수 있다. 모델은 의심스러운 패턴을 찾고, 유사한 코드 경로를 비교하며, 테스트 사례를 생성하고, 권한 부여 가정이 실패할 수 있는 지점을 제안할 수 있다.

시스템이 증거를 만들어낼 때 이 규모는 유용하다. 하지만 에이전트가 모든 불확실한 패턴을 확신에 찬 보고서로 바꾸면 비용이 커진다.

보안팀은 여전히 동작을 재현하고, 영향을 받는 버전을 식별하며, 악용 조건을 평가하고, 담당자를 지정하고, 수정 작업을 조율해야 한다. 모델이 생성한 매끄러운 설명은 이러한 의무를 줄여주지 않는다.

Apple의 자체 보고 가이드라인도 이러한 긴장을 반영한다. 해당 지침은 긴 AI 생성 설명을 권장하지 않으며 적절한 검증이 없는 이론적 AI 발견 결과는 제외한다.

이 규칙은 합리적이다. 벤더에게 필요한 것은 추측성 추론이 수 페이지에 달하는 문서가 아니라 재현 가능한 증거다. 그러나 한 연구자가 미약한 단서와 고영향 발견 결과를 함께 제출할 때 보고서 제한은 둔감한 통제 수단이 된다.

Bynario 사례는 AI가 만든 물량과 AI 보조 보안 연구의 차이를 보여준다. 회사는 시스템이 자격 증명 불일치를 찾아냈지만, 사람은 결과를 처음부터 끝까지 검증했다고 말한다.

그 검증에는 음성 대조군이 포함됐다. 기본 인증에서는 보호된 작업이 일반 사용자 권한으로 실패했다. 레거시 경로에서는 유사한 작업이 root 권한으로 성공했다.

이 차등 테스트는 모델의 신뢰도 점수보다 훨씬 더 가치 있다. 인증 경로 하나가 바뀔 때 보안 결과가 달라진다는 점을 입증하기 때문이다.

이 발견은 익스플로잇 테스트도 견뎠다. 연구진은 이례적인 권한 차이에서 출발해 권한 있는 파일 생성, 그리고 명령 실행으로 이어졌다. 각 단계는 다음 단계를 위한 구체적인 증거를 제공했다.

저품질 보고서에는 흔히 이 연결 고리가 없다. 도달 가능성을 보여주지 않은 채 의심스러운 코드를 식별할 수 있다. 보안 영향을 입증하지 못한 충돌을 설명하거나, 공격자가 내부에 남아 있는 데이터를 제어한다고 가정할 수 있다.

생성형 모델은 이런 보고서를 완성된 것처럼 보이게 만든다. 기본 주장이 입증되기 전에도 취약점 분류, 공격 시나리오, 완화 조치 문구를 제공할 수 있다.

이로 인해 비대칭적인 업무 부담이 생긴다. 그럴듯한 보고서 10건을 생성하는 데 걸리는 시간은 한 건을 신중하게 반증하는 데 드는 시간보다 짧을 수 있다. 보고자가 발견 결과를 검증하지 않으면 수신자가 대부분의 비용을 부담한다.

따라서 Apple의 AI 보안 운영은 서로 연관된 두 가지 과제에 직면한다. 더 나은 접수 통제가 필요하지만, 반복적으로 신뢰할 만한 작업을 입증하는 연구자를 위한 경로도 마련해야 한다.

평판 시스템이 도움이 될 수 있다. 검증된 보고 이력, 완전한 proof of concept, 결정론적 재현 단계, 명확한 영향 버전 데이터는 보고서의 우선순위를 높여야 한다.

머신 보조 분류는 제출물을 비교하고, 중복을 식별하며, 기본 주장을 시험할 수도 있다. 다만 근거 없는 모델 출력을 또 다른 모델로 판단하면 공통된 오류가 증폭될 수 있다.

가장 강력한 접근법은 자동화된 필터링과 반증을 결합하는 것이다. 보고서가 신뢰할 만하게 들리는지 묻는 대신, 분류 시스템은 그 보고서를 거짓으로 만들 조건을 적극적으로 테스트해야 한다.

이를 위해서는 빌드, 로그, 구성 상태, 통제된 테스트 환경에 접근할 수 있어야 한다. 또한 보고서가 넘었다고 주장하는 경계를 이해하는 인간 검토자가 필요하다.

발견 결과를 생성하는 비용은 계속 낮아지고 있으므로 접수 과제는 더 커질 것이다. 모든 제출물을 똑같이 다루는 벤더는 잡음에 파묻힐 것이다. 자동화를 무차별적으로 차단하는 벤더는 실제 결함을 놓칠 것이다.

Apple과 Google의 접근법은 검증 계층에서 갈린다

Apple과 Google의 차이는 AI 모델 접근성보다 각 회사가 전문가 검증을 어떻게 조직하느냐에 더 가깝다.

Google은 심각한 취약점에 집중하는 전문 연구 그룹으로 2014년 Project Zero를 시작했다. 이러한 제도적 경험은 Google에 목표 선정, 발견 결과 재현, 결함 공개를 위한 기존 절차를 제공했다.

Big Sleep은 Google DeepMind의 모델 연구와 이러한 보안 경험을 결합한다. 이 시스템은 소프트웨어를 조사하고, 가설을 테스트하며, 전문가 검토를 거치는 보고서를 만드는 용도로 설계됐다.

2025년 8월 Google은 Big Sleep이 오픈소스 프로젝트에서 취약점 20건을 찾아 재현했다고 밝혔다. 영향을 받은 소프트웨어에는 널리 쓰이는 미디어 및 이미지 처리 구성 요소가 포함된 것으로 전해졌다.

수정 작업이 아직 진행 중이어서 Google은 기술적 세부 정보를 즉시 공개하지 않았다. 대변인은 시스템이 취약점을 자율적으로 찾아 재현했지만, 보고되기 전 모든 문제를 인간 전문가가 검토했다고도 밝혔다.

이러한 인간 검증 지점이 Big Sleep 결과의 핵심이다. 이 절차를 완전히 자율화하는 것은 아니지만, 유지관리자가 정제되지 않은 모델 출력을 받지 않도록 보호한다.

Google Big Sleep은 공개 기한과 하위 의존성을 이해하는 팀 안에서도 운영된다. 그 발견 결과는 맥락 없이 관련 없는 벤더 대기열에 단순히 투입되지 않는다.

Project Zero의 공개 시스템은 또 다른 이점을 만든다. Google은 문제가 보고된 시점, 기한이 만료되는 시점, 영향을 받은 사용자가 실제로 패치를 받는 시점을 추적한다.

해당 공개 정책은 업스트림 수정과 최종 사용자 기기 설치 사이의 패치 격차를 인정하면서 표준 기한을 사용한다. Big Sleep도 같은 프레임워크에 참여한다.

Apple 역시 상당한 보안 엔지니어링 자원을 보유하고 있다. 플랫폼 보안 강화 기능, 보안 연구 기기 프로그램, 공개 버그 바운티 절차를 운영한다.

Apple의 바운티 프로그램 역시 연구자에게 기술 설명과 proof of concept을 요구한다. 더 새로운 target flag는 특정 익스플로잇 조건에 도달했음을 입증하는 객관적 방법을 제공한다.

이러한 투자는 Apple이 취약점 연구를 무시하고 있지 않다는 뜻이다. 여기서 드러난 격차는 외부 조직에서 자동화된 제출물이 들어올 때의 처리량과 신뢰 문제에 관한 것이다.

Google은 AI 시스템과 그 결과물을 검토하는 전문가 팀을 모두 통제한다. 반면 Apple은 서로 다른 모델, 프롬프트, 도구, 검증 기준을 사용하는 많은 독립 연구자로부터 보고서를 받는다.

이는 더 어려운 접수 문제다. Apple은 외부 모델 에이전트가 Project Zero의 방법론을 따르거나, 제보자가 제출 전에 해당 주장을 검증했다고 가정할 수 없다.

그럼에도 보고 채널의 설계 책임은 Apple에 있다. 검증된 연구자가 이전 보고서가 아직 열려 있다는 이유로 중대한 문제를 제출할 수 없다면, 이 시스템은 보안 영향보다 대기열 규모를 최적화하고 있는 셈이다.

성숙한 프로그램에는 여러 경로가 필요하다. 최소한의 문서만 갖춘 자동화 단서는 낮은 우선순위 대기열로 들어갈 수 있는 반면, 재현 가능한 증거가 있는 입증된 익스플로잇은 즉시 사람의 주의를 받아야 한다.

Apple은 대량 제출을 부추기지 않으면서 신뢰할 수 있는 제보자의 수용 능력을 늘릴 방법도 필요하다. 더 높은 할당량은 단순히 더 많은 공간을 요청하는 데가 아니라, 검증된 품질에 따라 제공돼야 한다.

Google의 접근법도 실수가 없지는 않다. 이 시스템에는 비용이 많이 드는 전문가 감독이 필요하며, 최초 공개 결과는 Big Sleep이 독점 플랫폼 전반에서 얼마나 잘 작동하는지를 입증하지 못했다.

또한 보고된 발견에 이르기 전 시스템이 얼마나 많은 후보를 폐기했는지도 여전히 불분명하다. 그 분모가 없다면 외부인은 오탐률이나 검토 비용을 계산할 수 없다.

유용한 교훈은 더 좁다. AI 기반 발견은 모델이 책임 있는 전문가가 관리하는 증거 파이프라인 안에 있을 때 가장 잘 작동한다. Apple의 과제는 개방형 외부 보고 프로그램 전반에서 그 기준을 재현하는 것이다.

보안의 핵심 트레이드오프는 속도와 신호다

더 많은 발견이 보안을 개선하는 것은 공급업체가 공격자가 같은 도구를 사용하기 전에 이를 검증된 수정으로 전환할 수 있을 때뿐이다.

AI 보조 취약점 발견은 공개 절차의 양측 모두에 압박을 가한다. 연구자는 더 많은 코드를 조사할 수 있고, 악의적 행위자 역시 같은 소프트웨어에서 악용 가능한 실수를 찾을 수 있다.

Google은 2026년 5월 AI 보조 제로데이 발견과 관련된 범죄 시도를 차단했다고 밝혔다. 회사는 영향을 받은 제품과 공격자가 사용한 것으로 알려진 모델을 공개하지 않았다.

AI 공격 관련 보도에 따르면, 이 취약점은 시스템 관리 제품의 2단계 인증을 우회할 수 있었다. Google은 피해가 발생하기 전에 공급업체와 법 집행기관에 통보했다고 밝혔다.

세부 사항은 여전히 제한적이므로, 이 사례만으로 모델이 얼마나 많은 작업을 완료했는지는 알 수 없다. 다만 보고서 처리 지연이 이제 더 큰 위험을 수반하는 이유는 보여준다.

대기열에서 기다리는 결함은 정적인 상태가 아니다. 다른 연구팀, 범죄 조직 또는 국가 지원 운영자가 독립적으로 이를 발견할 수 있다. 더 빠른 탐색은 그러한 충돌 가능성을 높인다.

Apple은 모든 자동화 제출을 받아들이는 방식으로 이 문제를 해결할 수 없다. 그렇게 하면 검토자의 시간이 소모되고 가장 중대한 보고서의 처리가 늦어진다.

기계 보조 연구를 억제해서도 문제를 해결할 수 없다. Bynario 결함은 유효한 권한 부여 결함이 자동화된 워크플로에서 발견되고 엄격한 사람의 테스트를 통과할 수 있음을 보여준다.

올바른 트레이드오프는 선별적 속도다. 강력한 증거가 있는 보고서는 신속히 상향 처리해야 하며, 불완전한 주장은 선임 엔지니어에게 도달하기 전에 더 저렴한 자동화 검증을 거쳐야 한다.

보고서는 영향을 받은 빌드, 필요한 구성, 공격자 전제조건, 관찰된 결과, 예상 결과 및 재현 가능한 테스트를 제시해야 한다. 보안 영향은 모델이 생성한 추측이 아니라 증거에서 도출돼야 한다.

권한 문제라면, 통제된 작업 중 프로세스 ID를 기록하는 방식이 될 수 있다. 메모리 결함이라면 sanitizer 추적과 최소 재현 사례를 포함할 수 있다.

공급업체는 이러한 요구사항을 중심으로 구조화된 제출 템플릿을 공개할 수 있다. 기계가 읽을 수 있는 증거는 유창한 문장을 증거로 취급하지 않고도 자동 분류가 보고서를 테스트하는 데 도움이 된다.

연구자에게도 책임이 있다. 불확실한 발견 수십 건을 보내는 것은 검증 비용을 공급업체에 전가하고 이후 모든 제출물에 대한 신뢰를 약화시킨다.

AI 보안 도구는 보고서를 생성하기 전에 반증 단계를 포함해야 한다. 에이전트는 놓친 접근 제어를 찾아보고, 패치된 빌드와 패치되지 않은 빌드를 테스트하며, 주장된 공격자가 필요한 모든 입력을 통제하는지 확인해야 한다.

고영향 주장에는 사람의 검토가 필수로 남아야 한다. 검토자는 문제를 독립적으로 재현하고 테스트 환경이 인위적인 조건을 만들지 않았는지 살펴봐야 한다.

이 요구사항은 AI의 가치를 줄이지 않는다. 규모의 이점이 있는 반복적 조사 작업으로 모델을 유도하는 동시에, 책임은 이름이 명시된 연구자에게 유지한다.

대중 역시 취약점 수를 순위표처럼 취급해서는 안 된다. 승인된 결함 20건이 검증된 공격 체인 1건보다 자동으로 더 중요한 것은 아니다.

건수는 얕은 스캔과 중복 보고를 보상할 수 있다. 더 나은 지표에는 검증까지의 시간, 확인된 심각도, 패치 제공, 오탐 부담, 사용자의 수정 적용률이 포함된다.

Apple의 보고서 상한은 이 가운데 하나의 지표만 다룬다. 열려 있는 제출물 수를 줄일 수는 있지만, 가장 위험한 보고서가 빠르게 적절한 엔지니어에게 도달한다는 사실을 입증하지는 못한다.

더 큰 보상금보다 더 나은 분류가 중요해질 것이다

AI 보안에서 다음 경쟁 우위는 기계 발견에서 사람이 검증한 완화 조치까지 이어지는 신뢰할 수 있는 파이프라인이 될 것이다.

Apple은 이미 고급 연구에 인센티브를 제공하지만, 돈만으로는 혼잡한 접수 과정을 고칠 수 없다. 연구자는 충분한 근거를 갖춘 발견이 읽히고, 재현되며, 올바르게 전달될 것이라는 확신이 필요하다.

첫 번째 개선책은 증거 기반 우선순위 설정이어야 한다. 작동하는 개념 증명, 명확한 전제조건, 검증된 영향은 제출 순서보다 더 큰 비중을 가져야 한다.

두 번째는 단계적 접근 권한이어야 한다. 이전 작업으로 확인된 수정으로 이어진 연구자는 더 큰 활성 보고서 할당량과 직접적인 기술적 상향 경로를 받을 수 있다.

세 번째는 투명한 상태 정보여야 한다. 의미 있는 피드백 없이 긴 시간이 지나면 중복 메시지, 성급한 공개, 보고서가 올바른 팀에 도달했는지에 대한 불확실성이 커진다.

Apple의 target-flag 개념은 이 방향을 가리킨다. 객관적 신호는 악용 가능성을 둘러싼 분쟁을 줄이고 의미 있는 통제를 입증한 연구자에게 보상할 수 있다.

그러나 플래그는 정의된 행동 범주만 포괄한다. 새로운 논리 결함은 미리 선택된 대상에 맞지 않을 수 있으며, 특히 취약점이 여러 신뢰된 구성 요소를 가로지를 때 그렇다.

CVE-2026-43760은 이러한 어려움을 보여준다. 각 파일 복사 작업은 개별적으로는 정상적으로 동작했다. 오류는 인증 ID, 헬퍼 권한, 파일시스템 접근이 상호작용하는 방식에서 발생했다.

이런 유형의 버그에는 의미론적 추론이 필요하다. 의미론적 분석은 단지 코드가 충돌하는지가 아니라 시스템의 동작이 보안 의도와 일치하는지를 살핀다.

AI 모델은 함수와 구성 요소 전반의 관계를 추적할 수 있기 때문에 도움을 줄 수 있다. 하지만 존재하지 않는 관계를 만들어낼 수도 있으므로, 실행 가능한 검증이 필수다.

강력한 분류 플랫폼은 모델의 추론을 보존하되 증거와 분리할 것이다. 검토자는 어떤 주장이 관찰된 것인지, 추론된 것인지, 아직 테스트되지 않았는지 확인할 수 있다.

팀은 내부 엔지니어링 기록에도 같은 원칙을 적용할 수 있다. 검색 가능한 기술 지식 베이스는 생성된 요약을 권위 있는 정보로 취급하지 않으면서 과거 결함, 설계 가정, 테스트 결과, 담당자를 연결하는 데 도움이 된다.

새로운 보고서가 이전 문제와 유사할 때 이러한 맥락은 중요하다. 시스템은 원본 아티팩트에 대한 접근을 유지하면서 관련 구성 요소와 수정 사항을 식별해야 한다.

Apple은 취약점을 노출하지 않고도 집계 처리 데이터를 공개할 수 있다. 유용한 지표에는 검증 시간의 중앙값, 중복률, 추가 정보 요청, 근거 부족으로 종결된 보고서의 비율이 포함된다.

이러한 보고는 AI 제출물이 주로 잡음인지, 아니면 단순히 처리 역량이 유효한 연구의 속도를 따라가지 못했는지를 명확히 할 것이다.

Google도 같은 투명성 기준을 적용받아야 한다. 검토 비용을 공개하지 않은 채 성공적인 발견을 알리는 것은 자동화된 보안 연구에 대한 불완전한 그림을 제공한다.

이 비교가 Google이 AI 보안을 해결했다는 주장으로 발전해서는 안 된다. Big Sleep의 사람 검토는 강점이지만, 자율 취약점 연구에 여전히 전문가의 통제가 필요하다는 증거이기도 하다.

Apple은 Google의 조직 구조를 그대로 복제하지 않고도 따라잡을 수 있다. 제안된 발견이 풍부해지더라도 입증된 증거를 희소하고 가치 있게 만드는 보고 시스템이 필요하다.

Apple이 따라잡고 있는지 보여줄 세 가지 신호

앞으로 몇 달은 Apple이 이 사안을 일시적인 대기열 문제로 다루는지, 아니면 보안 연구의 영구적인 변화로 보는지를 보여줄 것이다.

첫 번째 신호는 Apple의 제출 통제 변경이다. 의미 있는 업데이트라면 검증된 연구자와 재현 가능한 익스플로잇을 테스트되지 않은 자동화 발견과 구분할 것이다.

단순한 상한 인상만으로는 충분하지 않다. 보고서가 주의를 받는 순서를 개선하지 않은 채 물량만 늘릴 것이다.

증거 기반 상향 처리는 Apple이 적응하고 있다는 근거를 강화할 것이다. 개별적인 연락에 계속 의존한다면 절차가 여전히 취약하다는 뜻일 수 있다.

두 번째 신호는 향후 보안 권고에서 AI 보조 발견을 Apple이 어떻게 다루는지다. 명확한 공로 표기, 정확한 영향 설명, 일관된 완화 세부 사항은 자동화가 보고서의 위상을 낮추지 않는다는 점을 보여줄 것이다.

CVE-2026-43760을 둘러싼 사례 같은 이견을 주시해야 한다. 서로 다른 심각도 판단은 일반적이지만, 권고문과 입증된 익스플로잇 사이에 설명되지 않은 간극이 있으면 방어자의 우선순위 설정이 어려워진다.

더 충실한 설명이 무기화된 세부 정보를 공개할 필요는 없다. 공급업체는 공격자에게 도움이 될 지침은 보류하면서 전제조건과 영향을 설명할 수 있다.

세 번째 신호는 Google Big Sleep과 유사 시스템이 최초 공개 배치 밖에서 어떻게 작동하는지다. 확인된 논리 결함, 낮은 오탐률, 효율적인 패치 조정은 Google의 모델을 강화할 것이다.

약한 보고서가 쏟아지면 이를 약화시킬 것이다. 문서화되지 않은 수준의 사람 노동에 의존하면서 자율 발견으로 제시되는 결과 역시 마찬가지다.

이 신호는 취약점 처리가 모든 기기 환경에 영향을 미치기 때문에 기업 구매자에게 중요하다. 유효한 보고서가 검토에 도달하지 못하거나 배포된 수정이 설치되지 않은 경우, 보안 기능의 가치는 제한적이다.

개발자 역시 변화하는 증거 기준에 관심을 가져야 한다. AI는 코드 검토를 도울 수 있지만, 유지관리자는 보고서에 시간을 쓰기 전에 점점 더 재현 가능한 테스트를 요구하게 될 것이다.

보안 연구자도 같은 선택에 직면한다. 모델을 사용해 제출 물량을 늘릴 수도 있고, 각 제출을 더 쉽게 기각할 수 없도록 더 강력한 실험을 구축하는 데 사용할 수도 있다.

따라서 Apple과 Google의 경쟁은 가장 많은 취약점 주장을 생성하는 경쟁이 아니다. 불확실한 기계 출력을 신뢰할 수 있는 방어 조치로 전환하는 경쟁이다.

그 경쟁은 이미 일반 소프트웨어 팀에 도달했다. 취약점 접수 규칙을 검토하고, 상향 처리에 필요한 증거를 정의하며, 고영향 보고서가 일반적인 대기열 제한을 우회할 수 있는지 테스트하라. 그렇지 못하다면 다음 유효한 AI 보조 발견은 코드를 드러내기 전에 그 절차의 문제를 드러낼 수 있다.