GitHub 버그 바운티 대개편: 프롬프트 인젝션이 최대 3만 달러짜리 정식 취약점이 됐어요

GitHub이 2014년부터 12년 넘게 운영해온 버그 바운티 프로그램을 역대 최대 규모로 개편한다고 발표했어요. 버그 바운티가 뭐냐면, 외부 보안 연구자가 서비스의 취약점을 찾아 신고하면 회사가 심각도에 따라 보상금을 지급하는 제도인데요. GitHub은 지금까지 연구자들에게 총 450만 달러 이상을 지급해왔대요. 이번 개편의 핵심은 두 가지예요. 보상 체계를 티어로 단순화하면서 상한을 크게 올렸고, AI 기능의 취약점을 정식 카테고리로 승격시켰어요.

3개 티어로 정리된 스코프

기존에는 제품별로 스코프가 흩어져 있었는데, 이제 세 티어로 통합돼요. Tier 1은 github.com 코어, Actions, Packages, 그리고 Copilot 백엔드 서비스로, 크리티컬 원격 코드 실행(RCE) 기준 최대 6만 달러까지 보상해요. Tier 1의 기본 보상액도 전반적으로 2배 정도 올랐고요. Tier 2는 Enterprise Server, 모바일 앱, npm 레지스트리 인프라. Tier 3는 인수한 지 1년 이내인 회사들과 마케팅용 사이트예요. 기존에 제출된 리포트는 새 구조로 자동 이관되고, 두 체계 중 보상이 더 큰 쪽으로 쳐준다고 하니 기존 신고자에게 손해가 없도록 설계했네요.

진짜 뉴스는 AI 취약점 분류 체계

이번 발표에서 눈여겨볼 부분은 Copilot과 에이전트 기능에 전용 취약점 분류가 생겼다는 거예요. 구체적으로 세 가지가 명시적으로 스코프에 들어왔어요. 프롬프트 인젝션으로 권한 없는 저장소에 접근하는 것, 모델 출력을 통해 비공개 코드가 유출되는 것, 그리고 에이전트의 권한 상승이요. 테넌트 경계를 넘는 데이터 접근, 그러니까 내 계정으로 남의 조직 데이터를 보게 되는 유형은 최대 3만 달러까지 보상하고요.

프롬프트 인젝션이 뭐냐면, AI가 읽는 외부 텍스트(이슈, README, 코드 주석 등)에 몰래 지시문을 심어서, AI가 원래 사용자 대신 공격자의 명령을 따르게 만드는 공격이에요. AI 에이전트가 저장소를 읽고 코드를 수정하는 시대에는 이게 이론이 아니라 실질적인 침투 경로가 되거든요. 흥미로운 건 GitHub이 리포트 요건을 꽤 엄격하게 정의했다는 점이에요. 재현 가능한 인젝션 페이로드와 실제 데이터 경계 침범의 증명을 요구하고, 실증 없는 추측성 시나리오는 스코프 밖이라고 못 박았어요. Copilot이 무례한 말을 하게 만드는 것 같은 콘텐츠 정책 우회는 보안 취약점이 아니라고 명시한 것도 눈에 띄고요. AI 보안 분야는 '이론상 위험하다'는 리포트가 쏟아져서 노이즈가 심한데, 증명 가능한 경계 침범만 받겠다고 선을 그은 거죠.

절차도 손봤어요

Tier 1 크리티컬 리포트는 24시간 내 첫 응답, 모든 유효 리포트는 30일 내 보상 결정을 약속했어요. 지금까지 보상까지 걸리는 시간의 중앙값은 11일이었지만 오래 걸리는 케이스의 꼬리가 길었다는 걸 스스로 인정했고요. 연구자용 리포트 상태 대시보드, 원하는 사람만 공개되는 리더보드, 그리고 취약점 수정 사항을 재검증해주면 원래 보상금의 20%를 추가로 주는 재테스트 보상도 새로 생겼어요. 신고자 입장에서 가장 답답한 게 '내 리포트가 어디쯤 가 있는지 모르는 것'이었는데, 그 부분을 직접 겨냥한 개선이에요.

업계 흐름에서 보면

이번 발표는 AI 기능 보안이 바운티 프로그램의 정식 카테고리로 자리 잡는 흐름의 연장선이에요. Google, Microsoft, OpenAI도 AI 관련 바운티를 운영하고 있고요. 그중에서도 GitHub의 발표가 의미 있는 건, '무엇이 AI 보안 취약점이고 무엇이 아닌지'를 구체적인 증명 요건과 함께 문서화했다는 점이에요. 프롬프트 인젝션 같은 개념은 아직 업계 전반에서 심각도 산정 기준이 정립되지 않았는데, 대형 플랫폼이 payout 밴드까지 붙여 기준을 제시하면 다른 회사들의 AI 바운티 설계에 참고 틀이 될 가능성이 높거든요.

한국 개발자에게

보안 연구에 관심 있는 분들에겐, 프롬프트 인젝션과 에이전트 권한 문제가 이제 실제 돈이 되는 취약점 클래스가 됐다는 신호예요. 웹 취약점 헌팅에 비해 아직 경쟁자가 적은 분야이기도 하고요. 그리고 연구자가 아니더라도, 자기 서비스에 LLM 기능을 붙이고 있는 팀이라면 GitHub이 정의한 세 가지 유형(인젝션을 통한 무단 접근, 출력을 통한 데이터 유출, 에이전트 권한 상승)을 그대로 자기 서비스의 위협 모델링 체크리스트로 쓸 수 있어요. 우리 서비스의 AI 기능은 어떤 데이터 경계를 갖고 있고, 그 경계를 넘는 시나리오를 테스트해봤는지 점검해볼 좋은 계기죠.

정리하면, AI 기능의 취약점이 추측의 영역에서 증명과 보상의 영역으로 들어왔다는 발표예요. 여러분이 만드는 서비스의 AI 기능에는 어떤 데이터 경계가 있나요? 그 경계를 공격자 관점에서 테스트해본 적 있으신가요?