구글은 2026년 10월 1일부터 자사의 오픈소스 소프트웨어를 대상으로 하는 취약점 보상 프로그램(OSS VRP)에서 신규 제품 취약점 신고를 받지 않기로 했다. 신고를 계속 받으면 더 많은 보안 결함을 발견할 기회도 늘어날 텐데, 오히려 접수 범위를 줄였다. 이미 제출된 신고나 공급망 관련 신고까지 모두 막은 것은 아니다. 영향을 받는 창구와 남아 있는 창구를 구분해야 이 결정의 의미가 보인다.[^1]
구글이 공식 계정에서 밝힌 이유는 자동화된 신고의 급격한 증가와 그중 대부분이 유효하지 않다는 판단이었다. 다만 그 공지는 automated submissions라고 표현했지, 접수된 신고가 전부 AI로 생성됐다는 수치나 비율을 제시하지 않았다. 기사 제목에 등장하는 AI는 그 배경을 해석하는 데 필요한 기술적 맥락이지, 구글이 발표한 미공개 통계를 대신하지 않는다.[^2]
내가 주목하는 변화는 신고를 만드는 비용과 신고를 검증하는 비용이 서로 다른 속도로 내려가고 있다는 점이다. AI가 코드에서 의심스러운 부분을 찾아 설명하는 작업은 이전보다 쉽게 자동화할 수 있다. 그러나 어떤 코드 경로가 실제로 도달 가능한지, 어떤 조건에서 공격이 재현되는지, 사용자의 데이터에 실질적인 영향이 있는지 판단하는 일은 여전히 실행 환경과 맥락을 요구한다. 이 비대칭이 커지면 버그 바운티는 발견 능력이 부족해서가 아니라 유효한 발견을 구분하는 능력 때문에 멈출 수 있다.
구글이 닫은 것은 보안 신고 전체가 아니다
OSS VRP는 구글의 오픈소스 프로젝트에 영향을 주는 보안 문제를 제보받고, 조건을 충족하는 연구에 보상을 지급하는 프로그램이다. 공식 규정에는 10월 1일부터 이 프로그램으로 새로운 제품 취약점 신고를 받지 않는다는 문구가 명시돼 있다. 일부 Google Cloud 제품에 영향을 주는 저장소는 별도의 Cloud VRP에서 신고를 받을 수 있으며, 10월 1일 이전에 제출한 제품 취약점 신고에도 변경이 소급 적용되지 않는다. 구글은 2027년 1분기에 해당 프로그램의 개편 방향을 알리겠다고 했다.[^1]
공급망 보안과 관련된 신고는 다른 범위다. 소스 저장소의 권한, 빌드와 배포 체인, 패키지 서명 등 공급망 문제는 제품 코드의 일반 취약점과 위험 전파 방식이 다르다. 접수 범위를 조정하면서 공급망 보안 신고를 계속 취급하는 결정은 구글이 보안을 포기한 것보다 한정된 검토 역량을 배분하고 있음을 시사한다. 다만 구글이 분야별로 얼마만큼의 인력을 재배치했는지는 공개 자료만으로 알 수 없다.[^1][^2]
AI가 늘린 것은 ‘확정된 취약점’이 아니라 먼저 ‘후보와 보고서’다
올해 3월 구글은 OSS VRP 규정 개편을 설명하면서 AI를 활용한 보안 연구의 성과를 인정하는 동시에 두 가지 유형의 신고를 문제 삼았다. 하나는 공격 조건이나 취약점 작동 방식을 잘못 설명하는 AI 생성 보고서였다. 다른 하나는 코드상의 오류를 제대로 가리키더라도, 프로젝트의 위협 모델에서 공격이 불가능하거나 실제로 도달하지 않는 코드에 있어 보안상 영향이 작은 보고서였다.[^3]
두 번째 유형이 특히 중요하다. 컴파일 가능한 코드에서 범위를 벗어난 메모리 접근 같은 패턴을 찾았다고 해서 곧바로 원격 공격이 가능한 보안 취약점이 되는 것은 아니다. 해당 함수가 배포 빌드에 들어가는지, 공격자가 입력을 통제할 수 있는지, 추가 권한이나 사전 조건이 필요한지까지 설명해야 한다. 코드상의 결함과 보상 대상으로 인정할 보안 위험은 겹치지만 같은 집합은 아니다.
따라서 자동화된 탐색이 많은 후보를 만들었다는 사실만으로 실제 취약점 수가 같은 폭으로 늘었다고 결론 내릴 수 없다. 구글은 이번 접수 중단과 관련해 전체 신고 건수, AI 작성 비율, 유효 신고율, 평균 검증 시간을 구체적인 숫자로 공개하지 않았다. 그 수치를 임의로 채우면 오히려 이 글이 비판하는 저품질 보고서와 다르지 않게 된다.[^2]
검증은 왜 탐색만큼 쉽게 빨라지지 않을까
한 건의 취약점 신고가 유효하다고 판정되기까지에는 적어도 네 단계가 필요하다.
- 중복 확인 — 이미 알려진 이슈나 기존 신고와 같은 현상인지 비교한다.
- 재현 — 버전, 환경, 입력, 권한, 로그를 맞춰 신고자가 설명한 결과가 실제로 발생하는지 시험한다.
- 영향 판단 — 취약 코드가 도달 가능한지, 악용할 수 있는지, 기밀성·무결성 등에 어떤 영향을 주는지 평가한다.
- 우선순위·수정 협의 — 프로젝트 유지보수자와 보안 담당자가 실제 조치 및 공개 절차를 결정한다.
이 과정은 보고서 문장만 읽어 자동으로 끝낼 수 없다. 재현 환경을 만드는 데 필요한 의존성 버전이 달라졌을 수 있고, 같은 증상이 전혀 다른 원인에서 나올 수도 있다. 유효하지 않은 신고라도 검토자는 그 결론에 도달하기 전까지 일정한 시간을 사용한다. 신고 한 건의 작성 비용은 낮아졌는데, 그 신고가 잘못됐다는 사실을 증명하는 비용은 충분히 낮아지지 않은 셈이다.
구글은 3월 규정 개편에서 일부 메모리 손상 신고에 대해 OSS-Fuzz로 재현하는 절차 또는 이미 병합된 패치를 요구하는 식으로 증거의 기준을 높였다.[^3] 이 조건은 단순히 제보자를 귀찮게 하려는 장치가 아니다. 검토자가 다시 확인할 수 있는 형태로 문제를 제출하게 만들어, 검증 부담의 일부를 신고 생성 단계로 돌리는 방법이다.
자동화가 무조건 문제인 것은 아니다
여기에는 중요한 반론이 있다. AI 연구 도구는 이전에 놓쳤던 실제 버그를 찾는 데에도 도움이 된다. 자동으로 생성한 후보가 많다는 이유만으로 자동화 보고서를 일괄 배척하면 중요한 취약점의 발견이 늦어질 수 있다. 또한 신고의 품질 문제는 AI 이전에도 있었다. 중복 제출, 재현할 수 없는 주장, 영향 범위를 과장한 보고서는 사람이 직접 작성해도 발생한다.
그래서 이 문제의 해법을 ‘AI 보고서 금지’로 단순화하기는 어렵다. 검증 가능한 자동화와 검증이 빠진 자동화는 운영상 다른 결과를 만든다. 좋은 도구는 의심스러운 위치를 찾는 데서 멈추지 않고, 테스트 케이스, 실행 로그, 영향을 받는 버전, 재현 환경을 함께 제공할 수 있다. 사람이 모든 후보를 처음부터 다시 분석할 필요를 줄이는 것이다.
2026년 10월 발표된 Google Chrome VRP의 보상 체계 개편도 재현 가능하고 영향도가 높은 연구를 중시한다는 방향을 보여준다. 다만 Chrome VRP와 이번에 일부 접수를 멈춘 OSS VRP는 별도 프로그램이다. 두 사건을 하나의 전면 중단으로 묶어 설명해서는 안 된다.[^4]
다음 버그 바운티는 신고의 양보다 ‘한 건을 확정하는 비용’을 관리해야 한다
운영자가 먼저 봐야 할 숫자는 단순 접수 건수보다 다음 지표에 가깝다. 전체 신고 중 재현에 성공한 비율, 중복 신고의 비중, 최초 접수부터 유효성 판정까지 걸리는 시간, 심각도별 유효 신고 비율, 확인된 문제 한 건에 들어간 검토 비용이다. 이 지표를 누적해서 보지 않으면 리포트가 쌓이는 현상이 실제 공격 표면이 늘어난 결과인지, 보고서 생산만 쉬워진 결과인지 구분하기 어렵다.
제출 단계에서는 PoC(개념증명 코드)·실행 로그·영향받는 버전·공격 조건을 구조화해 받는 편이 낫다. 1차 필터는 중복과 형식 오류를 식별하고, 재현 가능한 테스트는 격리 환경에서 자동으로 실행할 수 있다. 마지막에 사람이 담당할 일은 기계가 불확실성을 낮춘 사례에 대해 실제 피해 가능성과 수정 우선순위를 판단하는 것이다. 자동 선별의 오탐으로 중요한 신고가 사라지지 않도록 이의제기와 재검토 경로도 필요하다.
신고자 보상도 제출 수 자체에 반응하기보다 재현 가능한 증거, 실질적 영향, 문제 해결에 기여한 정도를 중심으로 설계할 수 있다. 이는 운영 방향에 관한 제안이지, 구글이 향후 모든 보상에 해당 방식을 도입하겠다고 발표했다는 뜻은 아니다.
발견이 쉬워질수록 신뢰할 수 있는 증거의 가치가 커진다
구글의 이번 결정에서 확인되는 사실은 제한적이다. 10월 1일부터 OSS VRP의 신규 제품 취약점 신고가 중단됐고, 구글은 대부분 유효하지 않은 자동화 제출의 증가를 이유로 들었으며, 기존 신고와 공급망 관련 신고는 중단 대상이 아니다. 그 밖의 AI 생성 비율, 정확한 대기열 길이, 인력 규모는 공개되지 않았다.[^1][^2]
내가 여기서 읽는 더 긴 흐름은 보안 연구의 중심이 ‘얼마나 많은 의심 지점을 제시할 수 있는가’에서 ‘얼마나 빨리 사실로 확인하고 고칠 수 있는가’로 조금씩 이동한다는 점이다. AI가 후보를 만드는 속도를 계속 높인다면, 가치가 커질 것은 단순한 목록이 아니라 다른 사람이 같은 결과를 재현할 수 있도록 남긴 증거다.
출처
[^1]: Google, Open Source Software Vulnerability Reward Program Rules, 2026-10-01 이후 규정: https://github.com/google/bughunters/blob/main/bughunters/articles/about/rules/open-source/google-open-source-software-vulnerability-reward-program-rules.md [^2]: Google VRP(@GoogleVRP) 2026-10-01 공식 공지 내용, TechCrunch의 2026-10-04 보도 및 후속 팩트체크: https://techcrunch.com/2026/10/04/google-froze-its-open-source-bug-bounty-program-due-to-a-significant-rise-in-ai-submissions/ ; https://www.securityweek.com/google-narrows-open-source-bug-bounty-amid-wave-of-invalid-automated-reports/ [^3]: Google Bug Hunters, Streamlining Google’s OSS VRP: Key Rule Updates (2026-03, 2026-04 개정): https://bughunters.google.com/blog/ossvrp-rule-updates-2026 [^4]: Google Bug Hunters, Changes to the Chrome VRP, 2026-10-13: https://bughunters.google.com/blog/changes-to-the-chrome-vrp-restructuring-rewards