구글, AI 제출물 '급증'에 오픈소스 버그 바운티 동결…2027년 1분기 업데이트
구글이 오픈소스 소프트웨어 취약점 보상 프로그램인 OSS VRP에서 제품 취약점 제출을 중단했다. 효력은 내용을 알린 날인 2026년 10월 1일부터다. 공지는 엑스(X)의 @GoogleVRP 계정과 프로그램 규정 웹사이트에 함께 올랐다. 오픈소스 버그 바운티 제도 전체가 사라진 결정은 아니다. 구글이 공개한 소프트웨어에서 제품 결함을 찾아 책임 있게 알리고 보상을 받던 경로만 일단 닫혔다.
구글이 밝힌 이유는 자동화된 제보가 상당히 늘었고, 그중 대부분이 유효하지 않다는 점이다. 접수를 멈춰 둔 동안 이 부분을 다시 구성하고 손보겠다고 했다. 다음 안내는 2027년 1분기에 내놓겠다는 약속이고, 분기 안의 날짜는 지정되지 않았다. 테크크런치의 앤서니 하 기사는 태평양 시각 2026년 10월 4일 오후 1시 31분, 한국 시각 10월 5일 오전 5시 31분에 게시됐는데, 그때는 10월 1일 자 중단이 이미 적용된 뒤였다. 기사 시점에 남은 공식 입장은 중단과 2027년 1분기 업데이트, 그리고 해당 부분을 다시 짜겠다는 계획이다.
OSS VRP는 구글의 오픈소스 소프트웨어와 공개 저장소에서 취약점을 찾아 책임 있게 알리는 연구자에게 보상을 주는 제도다. 이번에 멈춘 제품 취약점 제출은 코드 결함, 논리 오류, 설계 버그를 대상으로 한다. 코드가 잘못된 결함, 흐름이 어긋난 논리, 설계에 빈틈이 있는 문제가 이 항목으로 심사됐다. 공개 저장소를 읽고 문제를 책임 있게 알리던 일이 보상과 연결되던 공식 창구가 제품 취약점 제보였다. 그 창구가 닫히면 발견 자체는 이어질 수 있어도, 그 발견을 이 프로그램의 제품 항목으로 바꿔 보상을 청하는 절차는 멈춘다.
중단 범위 밖에 남는 제보가 있다. OSS VRP의 공급망 보고는 그대로 받는다. 중단 전에 이미 제출되었거나 처리가 끝나지 않은 보고도 영향을 받지 않는다. 막히는 것은 2026년 10월 1일 이후 새로 제출하는 제품 취약점이다. 연구자는 초안으로 쥔 보고서와 이미 들어간 보고서를 같은 상태로 두면 안 된다. 들어간 건은 기존 절차에 남고, 아직 넣지 않은 제품 결함은 다른 경로를 찾아야 한다.
구글이 대안으로 안내한 곳은 다른 구글 취약점 보상 프로그램과 패치 리워드 프로그램이다. 일부 구글 클라우드 저장소의 제품 취약점 가운데 구글 클라우드 제품에 영향을 주는 것은 구글 클라우드 취약점 보상 프로그램으로 계속 넣을 수 있다. 오픈소스로 공개됐다는 이유만으로 접수처가 하나로 모이지는 않는다. 저장소가 클라우드 제품과 어떻게 닿아 있는지에 따라 열려 있는 보상 프로그램이 달라진다. 제보 전에 규정에서 저장소와 영향 범위를 나누는 일이 연구자 절차에 포함된다.
부담의 내용은 테크크런치가 인용한 톰스하드웨어 보도가 채운다. 구글 엔지니어와 오픈소스 유지보수자들은 유효하지 않거나 환각이 섞인 보고에 밀렸다고 한다. 악용할 수 없는 버그와 존재하지 않는 버그를 걸러 내는 검증에 시간이 쓰였고, 그 시간은 실제 취약점 수정으로 가지 못했다. 제보가 늘었다는 사실과 고쳐야 할 결함이 늘었다는 사실은 여기서 갈라진다. 바운티의 병목이 발견 단계에서 판정 단계로 옮겨 간 모습이다.
톰스하드웨어는 대형 언어 모델과 자동화된 인공지능 버그 헌팅 스크립트가 제보의 비용과 노력을 낮췄다고 전했다. 한 건을 만들어 제출하는 품이 줄면 같은 검토 인력이 감당할 물량은 쉽게 넘친다. 구글이 중단 이유로 든 자동 제보의 증가와, 그중 대부분이 유효하지 않다는 판단은 이 변화와 맞물린다. 도구가 후보를 많이 만들어 내는 것과, 그 후보가 유효한 취약점인지는 별개의 문제다. 환각이 섞인 결과가 그대로 들어오면 유지보수자의 시간은 수정이 아니라 기각에 쓰인다.
리눅스에서도 비슷한 압력이 전해졌다. 톰스하드웨어는 리눅스가 오래된 네트워크 드라이버 지원을 종료한 일을, 인공지능이 만든 거짓 버그 보고가 밀려든 사례로 함께 짚었다. 거짓 보고가 쌓이면 유지보수 시간은 코드를 고치기보다 보고의 진위를 가리는 데 먼저 들어간다. 구글은 제품 취약점 접수를 잠시 멈추는 대응을 택했고, 리눅스는 오래된 드라이버의 지원을 끝내는 대응을 택했다. 형태는 달라도 무효 보고가 프로젝트의 작업 순서를 다시 쓴다는 점에서는 같다.
테크크런치는 지난해인 2025년, 사이버보안 전문가들이 인공지능 슬롭이 버그 바운티 프로그램에 심각한 위험을 제기한다고 경고했다고 보도한 바 있다. 이번 중단은 그 경고가 구글의 오픈소스 보상 제도에서 접수 중지로 나타난 사례로 읽을 수 있다. 2025년의 지적과 2026년 10월 1일의 조치를 나란히 놓으면, 저품질 자동 제보가 개별 보고서의 품질 문제를 넘어 창구 운영을 멈추는 데까지 갈 수 있음을 보여 준다.
버그 바운티는 바깥의 발견과 안의 수정을 연결하는 제도다. 발견 쪽 비용이 대형 언어 모델과 자동 헌팅 스크립트로 낮아지면, 안쪽의 검증 부담은 같은 비율로 줄어들지 않을 수 있다. 구글은 그 간극에 대해 제품 취약점 제출을 잠시 받지 않고 해당 부분을 다시 짜는 방식으로 대응했다. 공급망 제보를 열어 둔 조치는, 공개된 범위만 보면 오픈소스 보상 전체를 멈춘 결정이 아님을 보여 준다. 물량이 문제 된 제출 유형을 분리하고 다른 경로는 유지한 형태다.
보안 연구자에게 바로 닿는 변화는 경로다. 2026년 10월 1일 이후에는 구글 오픈소스의 코드 결함, 논리 오류, 설계 버그를 OSS VRP 제품 취약점 항목으로 새로 제출할 수 없다. 그 전에 들어가 처리가 남아 있는 제보는 중단 대상이 아니므로, 이미 넣은 건을 철회하라는 뜻은 아니다. 아직 제출하지 않은 발견은 다른 구글 취약점 보상 프로그램, 패치 리워드 프로그램, 요건이 맞는 클라우드 저장소라면 구글 클라우드 취약점 보상 프로그램을 각각 봐야 한다. 결함이 구글의 공개 저장소에 있다는 점만으로 예전 창구가 열려 있는 것은 아니다.
유지보수자와 바운티를 운영하는 회사에는 검증 시간이 비용으로 드러난다. 구글 현장에 대한 톰스하드웨어의 전언은, 엔지니어와 오픈소스 유지보수자가 무효 보고와 환각 버그를 판별하는 동안 실제 수정이 밀렸다는 것이다. 제출 노력이 낮아진 뒤에도 사람이 읽는 목록이 길어지면 유효한 결함의 수정은 늦어진다. 회사가 이 사례에서 취할 질문은 제보 건수가 얼마나 늘었는지보다, 사람이 여는 목록 안에 고쳐야 할 문제가 얼마나 남는지다. 그 균형이 무너진 채 창구를 그대로 두면 유지보수 일정은 검증으로 잠긴다.
2027년 1분기에 약속된 업데이트에서 볼 항목은 제품 취약점 접수가 다시 열리는지, 열린다면 자동 제보를 어떤 형식으로 받을지, 공급망 보고가 지금의 별도 경로로 남는지를 포함한다. 중단 전에 들어와 끝나지 않은 제보가 그 사이 어떻게 매듭지어지는지도 연구자의 일정이다. 구글은 그동안 이 부분을 다시 구성하고 다듬겠다고 했다. 새 형식이 환각과 무효 제보를 얼마나 줄이는지는 재개 뒤 검증에 드는 시간으로 가려진다. 그때까지 연구자는 열려 있는 프로그램으로 경로를 나누고, 유지보수자는 검증에 들어가던 시간이 취약점 수정으로 돌아오는지를 보면 된다.
댓글
댓글 쓰기