Google 버그바운티 중단, AI 보안의 병목은 검증

무엇이 중단됐고, 무엇은 남아 있나

Google의 오픈소스 취약점 보상 프로그램이 AI 자동 제출의 품질 문제에 부딪혔다. 10월 4일 TechCrunch 보도는 회사가 자동 제출이 크게 늘었고 대다수가 유효하지 않다고 설명하며 접수를 일시 중단했다고 전했다. 시행일은 2026년 10월 1일이며, 다음 안내는 2027년 1분기로 예고됐다. 이는 그때 반드시 재개한다는 약속과는 다르다.

적용 범위가 중요하다. Tom’s Hardware의 상세 보도에 따르면 대상은 OSS VRP의 제품 취약점 제출이다. 기존 제출 건과 공급망 보고까지 일괄 폐쇄한 것은 아니며, Google Cloud 제품에 영향을 주는 일부 저장소는 Cloud VRP 경로가 남아 있다. Google의 모든 버그바운티가 끝났다고 읽으면 오보다.

공식 OSS VRP 규칙 페이지는 참여자가 최종 조건을 확인할 곳이다. 이번 확인에서는 동적 페이지의 세부 본문을 직접 추출하지 못했으므로, 중단 범위와 예외는 위 보도에 근거해 설명한다. 실제 제보 전에는 최신 공식 안내를 다시 확인해야 한다.

탐지 비용보다 검증 비용이 커지는 구조

LLM은 코드에서 수상한 패턴을 찾고 그럴듯한 공격 시나리오를 서술할 수 있다. 그러나 패턴이 존재한다는 것과 공격자가 실제로 그 경로에 도달할 수 있다는 것은 다르다. 인증 조건, 빌드 옵션, 입력 제약을 무시하면 평범한 코드가 심각한 취약점처럼 보인다. 긴 설명이 실행 가능한 증거를 대신하지 못하는 이유다.

생산자는 보고서를 빠르게 늘릴 수 있지만, 유지보수자는 하나씩 읽고 환경을 구성하고 반증해야 한다. 이 비대칭은 스팸 필터만의 문제가 아니다. 사람의 검증 대기열이 길어지면 진짜 취약점도 늦게 처리된다. 다만 공개 보도만으로 Google의 정확한 무효율이나 추가 인건비를 계산할 수는 없다. 정량 수치를 임의로 붙여 피해 규모를 부풀려서는 안 된다.

CWE 취약점 분류 체계는 결함 유형을 일관되게 설명하는 데 도움이 되지만, 분류 번호 자체가 재현 성공을 뜻하지는 않는다. 중요한 것은 대상 버전과 실행 경로, 관측된 결과를 연결하는 일이다. 이 구분은 상시 에이전트 보안 검증의 과제와도 맞닿아 있다.

경쟁 기준을 보고서 수에서 유효 제보율로

아래 표는 Google이 발표한 새 규정이 아니라, 이번 사례를 바탕으로 한 보안팀의 평가 제안이다.

AI 보안 기업의 차별화도 여기서 갈린다. 더 많은 저장소를 훑는 것만으로는 고객의 업무가 줄지 않는다. 후보를 폐기한 이유, 검증 환경의 제한, 실패한 가정을 함께 남기는 도구가 유지보수자의 판단 시간을 줄일 수 있다. 반대로 실행 결과 없이 확신만 높이는 도구는 고객에게 검증 부채를 넘긴다.

한국 개발팀이 적용할 운영 방식

외부 제보를 받는 팀은 자동 생성 여부만으로 모든 보고를 차단하기보다, 허용된 범위 안의 최소 재현 근거를 요구하는 편이 합리적이다. 민감정보가 포함되지 않은 로그, 대상 커밋, 기대 동작과 실제 동작을 분리해 받으면 사람과 AI가 작성한 보고를 같은 기준으로 검토할 수 있다. 검증은 소유하거나 명시적으로 허가받은 환경에서 수행해야 한다.

내부 AI 코드 리뷰에도 같은 원칙이 적용된다. 개발자의 수정 시간을 아끼려면 모델이 지적한 문제를 곧바로 티켓으로 만드는 대신, 기존 테스트와 권한 모델을 먼저 대조해야 한다. Supabase 노출 사례의 권한 검증은 화면이 작동한다는 사실과 접근통제가 맞다는 사실을 분리해야 함을 보여준다.

실무에서는 유효 제보율, 건당 최초 판단 시간, 중복 비율, 실제 수정 연결률을 함께 보자. 목표는 무조건 접수량을 줄이는 것이 아니라 중요한 위험을 더 빨리 처리하는 것이다. AI 코딩 시대 CI 병목 분석처럼 생성 속도가 빨라질수록 후단 검증의 처리량을 설계해야 한다.

FAQ

Google의 모든 버그바운티가 멈췄나?

아니다. 보도상 이번 조치는 OSS VRP 제품 취약점 제출에 한정된다. 공급망 보고와 다른 프로그램의 조건은 구분해야 한다.

2027년 1분기에 반드시 다시 열리나?

확인된 것은 업데이트 예고다. 재개 시점이나 새로운 보상 조건까지 확정된 것으로 볼 수 없다.

AI가 찾은 취약점은 믿을 수 없다는 뜻인가?

아니다. 생성 방식보다 실제 재현 여부와 영향 범위가 중요하다. 이번 조치는 자동 제출의 품질과 운영 부담에 관한 사례다.

보안 도구 구매 시 가장 먼저 볼 지표는?

자사 환경에서 검증된 유효 제보율과 검토 시간을 함께 보자. 후보 수가 많아도 판단에 더 오래 걸리면 생산성 이득이 사라질 수 있다.

작은 오픈소스 프로젝트는 무엇부터 바꿀까?

대상 버전, 재현 절차, 기대 결과, 실제 결과를 포함한 제출 양식을 마련하고 중복 보고를 같은 원인으로 묶는 것부터 시작할 수 있다.