안드로이드 보안 패치 방식이 바뀐다? 구글이 변경한 부분을 알아보자

안녕하세요, Alternative입니다.

출처: 9to5Google

안드로이드 스마트폰은 보안 취약점에 대한 대응을 월별로 공개하는 '보안 패치'를 통해 하고 있습니다. 이 보안 패치를 적용하는 속도나 일관성은 각 안드로이드 제조사들이 사후 지원에 얼마나 신경쓰는지를 보여주는 척도가 되기도 하죠.

최근 구글이 안드로이드 보안 업데이트 방식에 꽤 중요한 변화를 주고 있습니다. 사용자 입장에서 큰 체감은 없겠지만, 흥미로운 부분들이 몇 가지 있어 새로운 방식을 소개해 드리려고 합니다.

 

---

 

기존의 보안 업데이트 방식

출처: Mishaal Rahman / Android Authority

지금까지 구글은 보안 취약점이 보고되면 CVE 번호 부여 → 심각도 평가(Triage) → 패치 개발 및 검증 → Android Security Bulletin(ASB) 공개라는 프로세스를 거쳐 왔습니다.

이 과정에서 그 달에 발견된 모든 취약점은 매달 보안 공지에 모두 포함되었고, 제조사(OEM)들은 구글로부터 사전(private) ASB를 받아 자사 기기의 소프트웨어에 맞게 패치를 병합하고 테스트했습니다.

문제는 일부 제조사가 이 과정을 버거워했다는 것이었습니다. 다수의 기종을 동시에 관리(삼성 등)하거나 인력·예산·테스트 리소스가 부족한 소규모 제조사(낫싱 등)의 경우, 매달 수십 개 이상의 보안 패치를 모든 기기에 검증해 배포하는 것은 현실적으로 어려웠습니다. 그 결과 일부 제조사는 기기 출시 후 시간이 지남에 따라 격월 혹은 분기 단위 업데이트 정책을 채택하기도 했습니다.

 

바뀐 점 톺아보기

출처: Mishaal Rahman / Android Authority

구글 안드로이드 팀은 기존의 “매달 모든 보안 취약점을 공개 및 배포하는 방식”에서 벗어나, 취약점의 위험도(risk)를 기준으로 공개 시점과 빈도를 조정하는 새 정책, Risk-Based Update System (RBUS)을 도입할 예정이라고 합니다. 특히 “실제 악용되었거나 악용 가능성이 높은 고위험(high-risk) 취약점”은 매달 계속 다루되, 나머지는 분기별로 묶어서 대응하겠다는 것이 핵심입니다. 

자세히 살펴보면 

고위험 취약점의 우선 처리

• 실제로 알려진 익스플로잇(exploit) 체인이 존재하거나, 공격 가능성이 높다고 평가되는 취약점들은 기존처럼 매달 Bulletin에 포함되어 공개됩니다. 예컨대, 원격 코드 실행(remote code execution), 권한 상승(elevation of privilege), 정보 유출 등의 유형.
• 이렇게 매우 위험한 취약점의 경우 원래와 같이 최대한 지연 없이 사용자 보호할 수 있게 매달 공개됩니다.

저위험 / 중등도 위험 취약점의 공개 시점 조정

• 위험도 중간 이하로 판단된 취약점들은 매달 공개하지 않습니다. 대신, 각 분기마다 누적된 목록을 정리한 Bulletin에서 한꺼번에 공개됩니다.
• 이는 크게 위험하지 않은 취약점들은 각 분기마다 한 번씩만 업데이트됨으로서, 제조사가 패치 테스트와 병합(merge) 작업을 더 효율적으로 진행할 수 있게 해 줍니다.

OEM 및 생태계 테스트 과정의 변화

• 사전(private) ASB(안드로이드 보안 공지)를 OEM에 먼저 보내는 것은 기존 방식대로 유지될 가능성이 높습니다. 다만, OEM이 매달 작업해야 하는 항목 수가 줄어들면 테스트 주기와 병합 타이밍이 좀 더 안정적으로 조정될 수 있습니다.
• 이전에는 매번 공개된 모든 취약점을 매달 패치해야 했다면, 바뀐 방식으로는 중요한 취약점들만 매달 패치하고, 중요하지 않은 취약점은 분기마다 한 번에 몰아서 패치할 수 있으므로 좀 더 예측 가능하고 정기적으로 진행할 수 있습니다.

정보 공개의 투명성 및 보안 연구자 관점

• 외부 연구자나 개발 커뮤니티에는 고위험 취약점 정보가 즉시 제공되겠지만, 중간 위험 이하 취약점에 대해서는 공개 시점이 늦어지므로, 보안 연구 및 커스텀 롬 개발자 등의 대응 속도가 떨어질 수 있습니다.
• 특히 이렇게 바뀐 방식 이후로 안드로이드 소스 코드는 매달 패치가 있을 때마다 업데이트해 공개하지 않고, 분기별로 한 번씩만 공개한다고 합니다. 따라서 커스텀 롬 개발자들은 분기별로 한 번씩만 보안 패치 업데이트를 진행할 수 있을 겁니다.

 

새로운 방식의 장단점

장점

제조사 입장에서 자원 배분의 효율성이 증가합니다. 낮은 위험도 취약점의 패치 병합 및 테스트에 드는 시간과 인력이 매달 분산되는 부담이 줄어듭니다. 따라서 테스트 퀄리티와 안정성 확보 여유가 생길 수 있습니다.

고위험 취약점에 대한 대응 속도는 유지됩니다. 이미 악용 가능성이 있거나 exploit 이 존재하는 취약점은 계속해서 월 단위로 대응됨으로써, 보안 사고 발생 가능성이 줄어듭니다.

예측 가능한 보안 주기: 분기별 공개되는 취약점들도 일정한 패턴을 가지면, 사용자나 개발자 모두 “다음 분기는 언제 공개될지” 예측이 가능해져 일정 관리가 쉬워질 것입니다.

우려되는 점

취약점 등급을 오판할 가능성이 있습니다. 위험도가 처음에는 낮다고 분류되었으나, 이후 기존의 알려지지 않은 Exploit이 발견되면 상황이 바뀔 수 있습니다. 예컨대 어떤 API 취약점이나 미묘한 권한 혼용(permission bleed-through) 등이 처음엔 Low/Moderate로 보였다가 나중에 큰 보안 구멍이 될 수 있죠. 

저/중등도 위험 패치가 지연됨에 따라 노출되는 기간이 늘어납니다. 공개가 분기 단위로 늦춰지면, 해당 취약점을 아는 공격자가 일반 사용자에게 패치가 배포되기 전까지 악용할 가능성이 더 늘어납니다.

외부 연구자의 정보가 상대적으로 부족해집니다. 커뮤니티 기반의 보안 실험·도구 개발자들은 취약점 세부 정보가 조기에 공개되지 않으면 대응 매핑(mapping)이나 예방 연구가 늦는 문제가 생깁니다.

 

---

 

제 생각

구글의 RBUS는 “보안 실용주의(pragmatic security)” 쪽으로 무게추를 옮긴 변화라고 봅니다. 모든 취약점을 동등하게 다루기보다는, 사용자가 실제 위험에 노출되는 부분에 우선 집중하겠다는 뜻이니까요.

다만 이 변화가 말단 사용자에게도 긍정적이려면, OEM의 의지가 매우 중요하다고 생각합니다.

구글의 입장에서는 제조사의 부담을 줄여주기 위해 공개 시기와 방법을 조정했지만, 고위험 취약점의 경우 여전히 달마다 공개되므로 제조사가 얼마나 패치를 빠르게 진행시키는지가 핵심입니다.

개인적으로는 지금도 달마다 패치를 잘 해주는 제조사는 부담이 좀 줄겠지만, 원래도 패치가 늦거나 자주 건너뛰는 제조사들은 부담이 덜해진다고 해서 규칙적으로 패치를 해줄 것 같지는 않네요.

앞으로 보안 업데이트 관련해서는 “어떤 취약점이 고위험으로 분류되었는지”, “OEM이 그에 얼마나 빠르게 대응하는지”를 지켜보면서 제조사를 선택하면 좋겠습니다.

 

---

 

👇같이 보면 좋은 글👇

C2PA Content Credentials 리뷰 - 당신이 찍은 사진은 진짜입니까?

 

안드로이드 16 QPR2 베타 출시 - 새로운 기능이 의외로 많다?