Chrome 보안 버그 1,072개, AI가 바꾼 취약점 대응 속도

Chrome 보안 버그 1,072개, AI가 바꾼 취약점 대응 속도

AI 뉴스 썸네일

Google이 Chrome 149와 150에서 보안 버그 1,072개를 고쳤다고 밝혔어요. 앞선 23개 버전에서 수정한 보안 버그를 모두 합친 것보다 많은 수치예요. Gemini 기반 도구는 취약점 탐색에 머물지 않고 신고 분류, 후보 패치 작성, 테스트, 배포 준비까지 들어갔어요. 1 2

핵심 요약

구분	핵심	왜 볼 만한가요
수정 규모	Chrome 149·150에서 보안 버그 1,072개를 수정했어요	이전 23개 버전의 합계를 넘어섰어요
취약점 탐지	여러 AI 모델과 Chrome의 CVE·Git 이력을 함께 활용해요	13년 넘게 숨어 있던 샌드박스 탈출 결함도 찾았어요
신고 분류	스팸·중복 제거부터 재현, 심각도 판단, 담당자 배정까지 자동화했어요	Google은 매달 수백 시간의 개발자 작업을 줄인다고 추산해요
패치 작성	수정용 AI가 여러 패치를 만들고 별도 검토용 AI가 후보를 평가해요	개발자가 검토하기 전 테스트까지 준비해 수정 속도를 높여요
배포와 적용	주 2회 보안 릴리스와 재시작 부담을 줄이는 동적 패치를 시험해요	수정 공개 뒤 실제 적용까지 생기는 공격 가능 시간을 줄이려는 조치예요

1. Chrome 보안 대응이 발견부터 업데이트까지 이어졌어요

Chrome 보안팀은 2023년부터 LLM을 퍼징과 취약점 연구에 써 왔어요. 2024년에는 Project Zero와 Naptime을 만들었고, 2025년에는 DeepMind·Project Zero와 Big Sleep을 개발했어요. 2026년에는 Gemini를 더 넓은 Chrome 코드에 적용해 탐지 효율을 높이고 오탐을 줄였어요. 이 과정에서 침해된 렌더러가 로컬 파일을 읽게 만들 수 있는 샌드박스 탈출 결함도 발견했어요. 해당 코드는 13년 넘게 남아 있었어요. 2

탐지 시스템은 한 모델의 답에만 의존하지 않아요. 오픈 웨이트 모델과 상용 모델을 함께 쓰고, 과거 CVE와 Chrome의 전체 Git 이력을 지식 기반으로 연결해요. 코드의 신뢰 경계와 위협 모델은 SECURITY.md로 전달하고, 별도 검토용 AI가 결과를 다시 확인해요. 같은 코드도 여러 번 검사해 모델의 비결정성과 성능 개선을 활용해요.

728x90

접근 권한은 강하게 제한했어요. AI는 일반 인터넷에 연결되지 않은 잠금 환경에서 저장된 소스 코드만 분석해요. 네트워크 요청은 애플리케이션과 목적지별 허용 목록으로 통제해요. 지정된 소스 디렉터리 밖의 파일 접근과 로컬 시스템 변경도 막아요. AI를 보안 코드에 붙일 때 모델 성능만큼 실행 권한과 감사 범위가 중요하다는 점을 보여주는 대목이에요.

발견량이 늘자 신고 처리 방식도 바뀌었어요. 시스템이 스팸과 중복을 걷어 내고, 개념 증명을 실제 운영체제와 브라우저 버전에서 재현해요. 스택 추적과 최초 유입 시점, 심각도 같은 정보를 붙인 뒤 알맞은 구성요소와 담당자에게 보내요. 예전에는 신고 하나를 분류하는 데 5분에서 30분 이상 걸렸어요. Google은 새 절차가 매달 수백 시간의 개발자 작업을 줄인다고 추산해요. 다만 이 수치는 외부 검증 결과가 아니라 Google의 자체 추정치예요. 2

수정 단계에서는 여러 후보 패치를 만들고 서로 비교해요. 수정용 AI가 패치를 제안하면 검토용 AI가 기능 동작, Chromium 스타일, 주변 코드 관례를 확인해요. 테스트 작성 도구는 Chrome이 지원하는 여러 플랫폼과 구성에서 패치를 검사해요. 최종 판단과 병합은 개발자가 맡아요. Google에 따르면 현재 대부분의 취약점에서 LLM이 후보 수정을 만들고 있어요.

이 흐름은 Chrome 149와 150에서 큰 숫자로 나타났어요. 두 버전에서 수정한 보안 버그는 1,072개예요. Google은 이전 23개 버전의 합계보다 많다고 설명했어요. Big Sleep과 CodeMender는 CI에 연결돼 24시간마다 변경 코드를 검사해요. 2026년 5월에는 심각도 S1+ 문제를 포함해 20개가 넘는 취약점이 제품에 들어가기 전에 차단됐어요. 1 2

수정 개수만 늘려서는 사용자 보호가 끝나지 않아요. 공개 저장소에 패치가 올라온 뒤 Stable 버전이 사용자에게 도착하기 전까지 공격자가 수정 내용을 역분석할 수 있어요. Chrome은 이 기간을 줄이려고 매주 보안 업데이트를 제공하고, 주 2회 보안 릴리스도 시험하고 있어요. 릴리스 노트와 CVE 설명을 패치 정보에서 자동 생성하는 작업도 진행 중이에요.

업데이트를 내려받아도 브라우저를 다시 시작하지 않으면 패치가 적용되지 않는 문제가 남아요. Chrome은 Renderer와 GPU 같은 자식 프로세스를 새 바이너리로 차례로 교체하는 동적 패치를 개발하고 있어요. Chrome 150은 macOS에서 창이 모두 닫히고 앱만 백그라운드에 남아 있을 때 대기 중인 업데이트가 있으면 자동으로 다시 시작해요. 보안팀이 코드 수정 속도뿐 아니라 사용자 기기에 실제로 적용되는 시간까지 한 흐름으로 보고 있다는 뜻이에요. 2

왜 중요한가요

이번 발표에서 눈여겨볼 부분은 AI가 찾아낸 버그 수보다 업무 연결 방식이에요. 취약점 탐지 결과가 많아지면 분류와 수정이 따라가지 못해 새 병목이 생겨요. Chrome은 신고 재현, 메타데이터 작성, 담당자 배정, 후보 패치와 테스트 생성까지 함께 늘렸어요. 보안 자동화를 도입하는 팀이라면 단일 탐지 모델보다 발견 이후의 처리 용량을 먼저 계산해야 해요. 2

숫자를 해석할 때는 주의가 필요해요. 보안 버그 1,072개를 고쳤다는 사실이 Chrome의 코드 품질이 갑자기 나빠졌다는 뜻은 아니에요. 탐지 범위와 처리량이 함께 커졌다면 과거에 남았을 결함을 더 많이 찾아 고친 결과일 수 있어요. 반대로 수정 건수가 많다는 이유만으로 실제 위험이 같은 비율로 줄었다고 단정할 수도 없어요. 취약점의 심각도, 회귀 여부, Stable 배포와 사용자 적용 시간까지 봐야 해요.

기존 보안 기법도 계속 필요해요. Google은 AI 탐지가 퍼징을 대체하지 않는다고 밝혔어요. 서로 멀리 떨어진 코드의 상호작용이나 여러 연산이 결합될 때 생기는 문제는 퍼징이 잘 찾을 수 있어요. 외부 보안 연구자의 독립적인 검증도 남아 있어요. AI 기반 분석, 전통적인 테스트, 사람의 코드 리뷰를 겹쳐 쓰는 구조가 현재 공개된 방식에 더 가까워요. 1 2

참고 자료

1. Google, AI로 6월에 지난 2년치보다 많은 Chrome 버그 수정 — GeekNews
2. Stronger with every update: How we’re making Chrome and the web safer in the AI Era — Google Security Blog