구글은 왜 오픈소스 버그바운티 프로그램의 일부를 중단했나

구글이 오픈소스 취약점 보고의 주요 범주에 대한 접수를 일시 중단했다.

2026년 10월 1일 Google Bug Hunters는 Google Open Source Software Vulnerability Reward Program(OSS VRP)을 통한 제품 취약점(Product Vulnerability) 제보를 더 이상 받지 않는다고 발표했다.

다만 OSS VRP의 공급망(Supply Chain) 관련 취약점 제보와 이미 접수된 기존 보고서는 이번 조치의 영향을 받지 않는다.

구글은 연구자들에게 취약점의 실제 영향을 다른 VRP 프로그램을 통해 제보하거나 Patch Rewards Program을 이용할 것을 권고했다. 아울러 OSS VRP의 해당 영역을 재설계하고 있으며 2027년 1분기 중 관련 업데이트를 제공하겠다고 밝혔다.

이유는 명확했다.

자동화된 취약점 보고서가 크게 늘어났고, 그중 대부분이 유효하지 않았기 때문이다.

이는 단순히 하나의 버그바운티 프로그램에서 발생한 행정적인 변화로만 볼 수 없다.

보안 연구 생태계 자체가 변화하고 있다는 신호다.

AI는 취약점을 찾아내고 보고서를 작성하고 제출하는 비용을 크게 낮췄다. 그러나 해당 취약점이 실제로 존재하는지, 공격에 이용할 수 있는지, 실질적인 보안 영향을 갖는지를 검증하는 비용까지 낮춰주지는 못했다.

이러한 불균형이 취약점 공개 생태계의 경제 구조까지 바꾸기 시작했다.

과거 버그바운티 프로그램의 기본 전제는 단순했다.

“더 많은 눈이 소프트웨어를 더 안전하게 만든다.”

많은 연구자가 코드를 들여다보고 제품을 테스트하며 취약점을 보고하면 기업은 문제를 더 빨리 발견하고 수정할 수 있다.

특히 오픈소스 소프트웨어는 코드가 공개돼 있고 광범위하게 사용되기 때문에 이러한 모델에 적합해 보였다.

구글의 OSS VRP 역시 구글이 공개한 오픈소스 소프트웨어의 보안 향상에 기여하는 연구자들에게 보상을 제공하기 위해 만들어졌다.

이 프로그램은 구글이 소유한 GitHub 조직의 공개 저장소뿐 아니라 일부 다른 플랫폼의 저장소도 대상으로 한다. GitHub Actions, 접근 제어, GitHub 애플리케이션 설정 등 저장소 구성도 포함된다.

하지만 AI는 이러한 전제를 바꿔놓고 있다.

이제 문제는 단순히 “충분히 많은 사람이 취약점을 찾고 있는가”가 아니다.

쏟아지는 자동화된 노이즈 속에서 얼마나 많은 ‘진짜 취약점’을 가려낼 수 있는가가 더 중요한 문제가 됐다.

구글은 이미 2026년 3월 OSS VRP 업데이트에서 보안 환경이 빠르게 변화하고 있다고 경고한 바 있다.

당시 구글은 AI가 생성한 취약점 보고서가 폭발적으로 증가하고 있으며, 실제로는 잘못된 정보나 취약점이 어떻게 발생하는지에 대한 ‘환각(hallucination)’ 설명이 담긴 보고서가 점점 더 많이 발견되고 있다고 밝혔다.

또한 코드상 오류 가능성을 지적하기는 하지만 프로젝트의 보안 모델상 실제 영향이 거의 없거나 해당 코드 경로에 현실적으로 접근할 수 없어 보안 문제가 되지 않는 보고서도 대량으로 제출되고 있다고 설명했다.

바로 이 지점이 문제의 핵심이다.

AI는 그럴듯한 취약점 보고서를 대량으로 만들어낼 수 있다.

그러나 그럴듯함(plausible)과 유효함(valid)은 전혀 다른 문제다.

보고서에는 실제 존재할 법한 취약점 유형이 등장할 수 있다.

전문적인 기술 용어도 포함될 수 있다.

이론적인 공격 경로도 설명할 수 있다.

비전문가가 보면 상당히 설득력 있어 보일 수도 있다.

그러나 보고서가 실제 악용 가능성(exploitability), 코드 접근 가능성(reachability), 보안 영향(security impact)을 입증하지 못한다면 위험을 줄이는 것이 아니라 오히려 새로운 업무를 만들어낸다.

현재 버그바운티 프로그램의 취약점 검토팀이 바로 이런 문제에 직면하고 있다.

사람이 보고서를 직접 읽고, 문제를 재현하고, 영향을 받는 버전을 확인하고, 공격 시나리오를 분석해야 한다.

해당 코드 경로에 실제 접근할 수 있는지를 검증하고, 보안 영향을 판단하고, 보상 대상인지까지 결정해야 한다.

AI는 보고서를 만드는 비용을 급격하게 낮출 수 있다.

하지만 보고서를 제대로 검증하고 분류하는 비용은 여전히 사람에게 크게 의존한다.

제보량은 늘어나는데 유효한 보고서의 비율이 증가하지 않는다면 프로그램의 신호 대 잡음비(signal-to-noise ratio)는 무너질 수밖에 없다.

구글의 이번 중단 조치가 중요한 이유다.

구글이 오픈소스 보안 활동 자체를 중단한다고 밝힌 것은 아니다.

오히려 공급망 공격과 관련된 취약점은 여전히 OSS VRP의 핵심 영역이다.

현재 구글의 규정은 소스 코드나 빌드 무결성을 훼손해 공급망 침해로 이어질 수 있는 취약점 제보를 “무엇보다 우선적으로(first and foremost)” 환영한다고 명시하고 있다.

대표적으로는 다음과 같은 문제다.

메인 브랜치의 코드를 변경할 수 있는 취약점, 빌드 또는 배포 인프라를 장악할 수 있는 문제, 패키지 관리자 인증정보를 탈취할 수 있는 취약점, 코드 서명 키(signing key)를 탈취할 수 있는 문제 등이다.

다시 말해 구글은 성을 포기한 것이 아니라 성문을 좁히고 있는 것이다.

구글은 소스 코드와 빌드 결과물, 배포 인프라, 사용자에게 전달되는 패키지처럼 시스템 전반에 가장 심각한 피해를 초래할 수 있는 영역을 우선하고 있다.

반면 제품 취약점은 성격이 다르다.

제품 취약점은 구글의 오픈소스를 이용해 만들어진 소프트웨어의 기밀성(confidentiality)이나 무결성(integrity)에 영향을 줄 수 있는 설계 또는 구현상의 문제를 의미한다.

구글이 예시로 제시한 항목에는 메모리 손상(memory corruption), sanitizer 오류, 경로 탐색(path traversal), 안전하지 않은 기본 설정이나 문서상의 코드 예제 등이 포함된다.

이러한 문제 역시 실제로 존재할 수 있으며 중요할 수 있다.

하지만 동시에 저품질 보고서를 대량 생산하기도 쉬운 영역이다.

AI 모델은 코드를 스캔한 뒤 버퍼 오버플로 가능성이 있는 패턴을 지적할 수 있다.

경로 탐색 취약점 가능성을 추정할 수도 있다.

안전하지 않은 코드 예제를 지적하는 보고서를 생성할 수도 있다.

그러나 실제 실행 가능한 개념증명(Proof of Concept·PoC), 접근 가능한 코드 경로, 명확한 보안 영향이 없다면 이러한 보고서는 자동화된 의심에 불과할 수도 있다.

구글이 이번 중단 조치 이전부터 취약점 인정 기준을 강화해온 이유도 여기에 있다.

OT0와 OT1 프로젝트의 경우 메모리 손상 취약점을 인정받기 위해 기존 퍼징 타깃(fuzz target)을 이용한 정확한 OSS-Fuzz 재현 절차나 이미 병합된 패치 등을 요구했다.

등급이 낮은 OT2와 OT3 프로젝트에서는 제품 취약점 자체가 더 이상 금전적인 보상 대상이 아니었다.

10월의 이번 조치는 여기서 한 걸음 더 나아갔다.

2026년 10월 1일부터 구글은 OSS VRP를 통한 제품 취약점 제보를 아예 받지 않고 있다.

다만 그 이전에 제출된 제품 취약점에는 새로운 정책이 적용되지 않는다.

Google Cloud 제품에 영향을 미치는 일부 Google Cloud 저장소의 경우 연구자는 여전히 Cloud VRP를 통해 취약점을 제보할 수 있다.

또 Google Cloud나 AI 제품과 밀접하게 연관된 구글 오픈소스 프로젝트의 경우 Google Cloud VRP 또는 AI VRP를 이용해 적절한 엔지니어에게 보고서가 전달될 수 있도록 하라고 구글은 권고하고 있다.

이러한 구분은 중요하다.

구글은 모든 제품 취약점이 중요하지 않다고 말하는 것이 아니다.

현재의 방식으로는 이 제보 채널을 지속할 수 없다고 말하고 있는 것이다.

결국 프로그램 자체를 다시 설계해야 한다.

더 근본적인 문제는 AI를 활용한 버그 헌팅이 취약점 공개의 경제 구조를 변화시키고 있다는 데 있다.

생성형 AI가 등장하기 전까지 그럴듯한 취약점 보고서를 작성하는 데는 일정 수준 이상의 수작업이 필요했다.

연구자는 코드를 살펴보고 프로젝트를 빌드하고 테스트를 실행하고 개념증명을 만들고 보안 영향을 이해한 뒤 일관성 있는 보고서를 작성해야 했다.

이러한 노력 자체가 하나의 자연스러운 필터로 기능했다.

이제는 그 필터가 약해졌다.

AI는 보고서를 빠르게 작성할 수 있다.

자동화 도구 역시 수많은 잠재적 취약점 후보를 만들어낼 수 있다.

연구자뿐 아니라 스팸성 제보자조차 이전보다 훨씬 적은 노력으로 많은 보고서를 제출할 수 있다.

보고서를 하나 더 만들어내는 한계비용(marginal cost)은 급격히 낮아졌다.

하지만 보고서 하나를 제대로 검증하는 한계비용은 같은 속도로 떨어지지 않았다.

이 차이가 오픈소스 유지관리자에게 새로운 부담을 만들어내고 있다.

오픈소스 프로젝트는 이미 상당한 유지관리 부담을 안고 있다.

유지관리자는 Pull Request를 검토하고, 버그를 수정하고, 이슈에 대응하고, 새로운 버전을 배포하고, 의존성을 관리하고, 보안 제보에도 대응해야 한다.

여기에 유효하지 않거나 AI가 환각으로 만들어낸 취약점 보고서가 대량으로 쌓인다면 유지관리자는 실제 보안 문제를 수정하는 대신 잘못된 주장을 반박하는 데 시간을 쓰게 된다.

이는 버그바운티 프로그램이 원래 장려해야 할 우수한 연구자에게 오히려 피해를 줄 수도 있다.

검토팀의 업무가 과중해지면 유효한 보고서 역시 처리 시간이 길어질 수 있다.

좋은 연구자가 제출한 보고서의 응답 속도도 느려질 수 있다.

유지관리자는 모든 보고서를 기본적으로 의심하는 태도를 갖게 될 수도 있다.

프로그램은 범위를 축소하거나, 더 강력한 증거를 요구하거나, 연구자의 평판을 바탕으로 참여를 제한할 수도 있다.

역설적인 결과다.

AI는 더 많은 버그를 찾을 수 있도록 도와줄 것으로 기대됐다.

그러나 너무 많은 저품질 노이즈를 만들어낼 경우 오히려 모든 연구자의 버그바운티 프로그램 접근성을 떨어뜨릴 수 있다.

따라서 구글 OSS VRP의 이번 중단은 단순히 구글만의 문제가 아니다.

전체 보안 생태계를 향한 경고이기도 하다.

버그바운티 프로그램은 신뢰(trust)와 검증 역량(triage capacity) 위에서 작동한다.

연구자는 자신이 제출한 유효한 보고서가 공정하게 평가되고 적절한 보상을 받을 것이라고 믿는다.

기업은 연구자가 실행 가능하고 윤리적이며 충분한 근거를 갖춘 취약점을 제보할 것이라고 믿는다.

하지만 AI가 생성한 보고서가 검증되지 않은 주장으로 시스템을 뒤덮기 시작하면 이러한 상호 신뢰가 약해질 수밖에 없다.

앞으로는 ‘AI를 활용한 보안 연구’와 ‘AI가 생성한 스팸’ 사이의 경계가 더욱 중요해질 수밖에 없다.

취약점 연구에서 AI를 이용하는 것 자체에는 문제가 없다.

AI는 코드를 읽고, 문서를 요약하고, 테스트 케이스를 만들고, 엣지 케이스(edge case)를 분석하고, 취약점을 재현하는 과정에도 도움을 줄 수 있다.

신중하게 활용한다면 연구자의 효율성을 크게 높일 수 있다.

그러나 AI가 만들어낸 결과는 반드시 검증돼야 한다.

실제 취약점 보고서라면 문제가 어디에서 발생하는지, 어떻게 재현할 수 있는지, 어떤 버전이 영향을 받는지, 어떠한 영향을 미치는지, 공격자가 이를 어떤 방식으로 악용할 수 있는지를 제시해야 한다.

구글의 보고 규정 역시 실행 가능한 개념증명, 재현 절차, 영향을 받는 소프트웨어 버전, 영향 설명, 공격 시나리오 등 가능한 한 구체적인 내용을 포함한 고품질 보고서를 강조하고 있다.

하지만 AI가 생성한 취약점 보고서는 바로 이 기준을 충족하지 못하는 경우가 많다.

기술적으로 그럴듯하게 들리지만 증거가 없을 수 있다.

영향을 설명하지만 실제로 이를 입증하지 못할 수 있다.

취약점 유형을 지적하지만 해당 코드에 실제 접근할 수 있는지를 보여주지 못할 수도 있다.

이론적 약점과 실제 공격 가능한 취약점을 혼동할 수도 있다.

그리고 이러한 보고서가 대량으로 생성되면 전체 취약점 검토 시스템을 운영하기가 더욱 어려워진다.

이에 따라 새로운 보안 문제가 등장하고 있다.

취약점 발견의 문제가 아니라 ‘취약점 보고서 품질’의 문제다.

과거 보안 프로그램은 취약점이 충분히 보고되지 않는 것을 우려했다.

이제는 유효하지 않은 취약점이 지나치게 많이 보고되는 문제까지 고민해야 한다.

해결책은 결국 보다 구조화된 검증 체계를 만드는 방향으로 나아갈 가능성이 크다.

버그바운티 프로그램은 특정 유형의 보고서를 접수하기 전에 더욱 강력한 증거를 요구할 수 있다.

재현 가능한 테스트 케이스, 정확한 퍼징 절차, 이미 반영된 패치, 공격 시연, 보다 명확한 영향 기준 등을 요구할 수 있다.

연구자의 평판이나 과거 활동 기록을 활용하거나 제출 횟수를 제한하거나 사전 검증 절차를 도입할 수도 있다.

추정 수준의 취약점과 검증된 취약점을 별도의 큐(queue)로 분리할 수도 있다.

취약점이 영향을 미치는 제품에 따라 Cloud VRP나 AI VRP처럼 보다 전문화된 프로그램으로 보고서를 전달하는 방식도 확대될 수 있다.

구글의 현재 규정 역시 이미 이러한 방향을 보여주고 있다.

OSS VRP는 이제 공급망 침해, 프로젝트 등급, 재현 가능성, 보안 영향, 보고서 품질을 강하게 강조하고 있다.

보상 금액은 프로젝트 등급과 취약점 범주에 따라 달라지며 최종 보상액은 보상 심사위원회(reward panel)의 재량에 의해 결정된다.

공급망 침해 취약점은 주요 프로젝트 등급에서 여전히 보상 대상이지만 현재 보상표에서는 제품 취약점에 대한 별도 보상 항목이 존재하지 않는다.

이러한 상황에서 Patch Rewards Program의 중요성도 커지고 있다.

연구자는 단순히 잠재적인 제품 취약점을 보고하는 데서 그치지 않고 구글의 오픈소스 프로젝트에 직접 보안 개선 사항을 기여할 수도 있다.

구글도 연구자들에게 OSS 프로젝트의 보안 개선을 위한 Patch Rewards 프로그램을 적극적으로 살펴볼 것을 권장하고 있다.

이는 취약점 제보 방식이

“무엇이 잘못됐을지도 모른다고 말해달라”에서 “검증된 수정 방법이나 실질적인 보안 개선을 보여달라”로 이동하고 있음을 보여준다.

AI가 대량으로 보고서를 생성하는 환경에서는 이러한 변화가 합리적이다.

누구나 보고서를 만들 수 있다면 증거의 가치가 커진다.

주장을 만드는 비용이 낮아질수록 패치의 신뢰성은 높아진다.

추측이 넘쳐날수록 재현 가능성이 신뢰의 화폐가 된다.

오픈소스 유지관리자에게 이러한 변화는 고통스럽지만 불가피한 과정일 수 있다.

자동화 도구는 실제 취약점을 발견하는 데 도움을 줄 수 있지만 동시에 사람의 ‘주의력’을 대상으로 일종의 서비스 거부(Denial-of-Service) 공격과 유사한 효과를 만들어낼 수도 있다.

유효하지 않은 보고서의 홍수는 단순히 시간을 낭비하는 문제가 아니다.

진짜 취약점의 수정이 늦어질 수 있고, 유지관리자를 소진시키며, 세심한 검토 자체를 포기하게 만들 수 있다.

보안에서 사람의 주의력은 희소한 자원이다.

AI는 사람이 검증할 수 있는 것보다 더 많은 취약점 후보를 만들어낼 수 있다.

따라서 미래의 버그바운티 프로그램은 누가 가장 많은 보고서를 만들어내느냐보다 누가 실제 영향을 입증할 수 있느냐에 의해 좌우될 가능성이 크다.

이것이 구글 OSS VRP 중단 조치가 던지는 메시지다.

적은 노력으로 취약점 보고서를 대량 생성하던 시대는 끝나가고 있다.

증거 중심의 취약점 연구 시대가 시작되고 있다.

보안 연구자에게 전달되는 메시지는 분명하다.

AI가 단순히 “취약할 것 같다”고 제안한 내용을 그대로 제출하지 말라.

직접 검증한 내용을 제출하라.

가능성이 있는 버그라고 설명하는 데 그치지 말라.

실제로 접근 가능한 공격 경로를 보여줘라.

기술적인 표현에 의존하지 말라.

재현 절차와 영향, 증거를 제시하라.

플랫폼 기업에도 메시지는 분명하다.

AI가 취약점 제보의 비용 구조를 바꿨다면 제보를 접수하는 시스템 역시 변화해야 한다.

프로그램에는 더 나은 필터가 필요하다.

보다 명확한 범위가 필요하다.

더 강력한 증거 기준과 효율적인 보고서 라우팅 체계도 필요하다.

그렇지 않다면 버그바운티 검토 큐는 기계가 만들어낸 불확실성으로 가득 차게 될 것이다.

구글은 2027년 1분기에 연구자들에게 새로운 정책을 업데이트하겠다고 밝혔다.

향후 구글이 내놓을 정책은 다른 취약점 보상 프로그램에도 하나의 모델이 될 가능성이 있다.

증거 요건은 더 강화될까.

연구자의 평판을 기반으로 한 제출 제한이 도입될까.

AI를 활용한 보고서를 별도로 처리하는 큐가 만들어질까.

패치와 퍼징 통합에 더 높은 가치를 부여하게 될까.

제품 취약점의 범위가 더욱 좁아질까.

아직 구체적인 내용은 알 수 없다.

그러나 방향은 분명하다.

AI는 취약점 보고서를 만드는 것을 훨씬 쉽게 만들었다.

이제 보안 프로그램은 검증되지 않은 취약점 보고서를 제출하는 것을 더 어렵게 만들어야 한다.

이는 오픈소스 보안에서 후퇴하는 것이 아니다.

오히려 오픈소스 보안 생태계를 지키기 위한 시도에 가깝다.

자동화된 주장들이 이를 검증해야 하는 사람들의 처리 능력을 압도하기 시작하면 진짜 취약점마저 그 속에 묻힐 수 있기 때문이다.

결국 버그바운티의 미래를 결정하는 것은 AI가 얼마나 많은 보고서를 생성할 수 있느냐가 아니다.

인간과 AI가 함께 얼마나 많은 ‘검증된 보안 영향’을 입증할 수 있느냐가 될 것이다.