안드로이드 취약점 24건, 중형 저장소 1~2시간

내 앱 코드를 보안 전문가에게 맡기면 얼마가 들까. GitHub는 9월 28일 블로그에서 다른 길을 보여 줬다. 자사의 오픈소스 AI 보안 에이전트를 안드로이드 앱 여러 개에 돌려 취약점 24건을 찾았다. 1천만 다운로드가 넘는 내비게이션 앱 OsmAnd에서는 설정 가져오기 기능을 타고 위치 추적이 가능했고 위키백과 안드로이드 앱에서는 딥링크 조작으로 계정 탈취 경로가 나왔다.

에이전트는 중형 저장소 하나를 1~2시간에 훑는다. GitHub Copilot 라이선스가 필요하고 프리미엄 모델 요청을 많이 쓴다는 경고가 붙어 있다. 실행은 스크립트 한 줄이다.

한 줄 정리

GitHub가 오픈소스로 공개한 AI 보안 에이전트가 안드로이드 앱에서 취약점 24건을 찾아냈고, 이제 중형 앱 하나의 1차 점검이 반나절이 아니라 1~2시간 작업이 됐다.

한눈에 보기

에이전트를 잘게 나눠 돌렸다

이 글에서 눈에 띄는 건 모델 이름이 아니라 작업을 쪼갠 방식이다. 먼저 앱 안에서 외부 입력이 들어오는 진입점을 모바일용과 아닌 것으로 갈라 모으고 그다음 진입점 종류별로 점검할 취약점 유형을 좁혀 들어간다. 인텐트로 받는 진입점이면 권한 대행 공격이나 방송 수신 취약점을, 다른 진입점이면 다른 유형을 본다. 두 개의 작업 흐름 파일이 이 순서를 정한다.

"이 앱의 보안 문제를 찾아라"는 한 줄 지시로는 잡음만 나온다. 단계를 나눠 각 단계에서 볼 것을 좁히니 사람이 읽을 만한 결과가 나왔다. 프롬프트가 길어서 성능이 나온 게 아니라 업무 절차를 문서로 옮겼기 때문에 성능이 나왔다.

오탐은 여전히 사람 몫이다

글이 솔직한 대목이 하나 있다. 모델은 취약점의 심각도를 판단하는 데 약하다. 낮은 위험도의 오탐이 많이 섞여 나오고 그래서 모든 발견 건을 모바일 앱을 아는 보안 연구자가 검토해야 한다고 못 박는다. 결과는 SQLite 뷰어에 쌓이고 has_vulnerability 열로 걸러 본다. 24건은 전체 후보에서 사람이 확인하고 남은 숫자다.

anyAX 관점

앱이나 웹서비스를 외주로 만든 소규모 팀의 현실을 보자. 납품받은 코드를 보안 관점에서 읽어 본 사람은 없다. 회원 계정과 결제 정보가 붙은 앱이 그 상태로 돌아간다. 이번 사례는 그 공백에 돌려 볼 수 있는 저렴한 1차 도구가 생겼다는 뜻이다. 전문가 감사 비용의 일부로 위험한 구멍 후보를 먼저 추려 놓으면 사람이 쓰는 시간이 가장 위험한 곳에만 간다.

하지만 위키백과 앱의 딥링크 사례는 경계선도 보여 준다. 딥링크 하나가 계정 탈취로 이어지는 건 코드 한 줄이 아니라 앱의 설계 의도를 알아야 판단되는 문제다. 에이전트가 후보를 던지면 이게 실제로 악용되는지, 고칠 때 다른 기능이 깨지지 않는지를 가르는 건 사람이다. 쉽게 돌릴 수 있게 된 도구일수록 결과를 읽는 사람의 자격이 더 무거워진다.

실전 순서는 이렇다. 우리 앱 저장소 하나에 돌려서 나온 후보를 심각도순으로 뽑고 상위 다섯 건만 외주 개발사나 보안 전문가에게 확인을 요청한다. 고객 데이터를 만지는 앱을 굴리는 팀이라면 이 정도는 분기마다 해 볼 만한 비용이다. 돌리기 전에 Copilot 요청량이 얼마나 나갈지 작은 저장소로 먼저 재 보는 것도 잊지 않는다.

참고

• GitHub Blog: 오픈소스 AI 보안 에이전트로 안드로이드 취약점 24건을 찾은 과정