AI 보고서가 검토자를 압도하자 Google 오픈 소스 버그 바운티 일시 중단

Google은 자동화된 보고서가 급증한 뒤 대다수가 무효라고 밝히며 오픈 소스 버그 바운티를 일시 중단했다. 중단은 2026년 10월 1일 시작됐으며, Open Source Software Vulnerability Reward Program에 대한 신규 제품 취약점 제출에 적용된다.

이번 결정은 AI 지원 보안 연구의 뚜렷한 모순을 드러낸다. 이제 모델은 전례 없는 속도로 더 많은 코드를 검사하고 설득력 있는 보고서를 만들어낼 수 있다. 그러나 각각의 제출물은 여전히 사람이 주장된 결함이 실제로 존재하는지, 중요한지, 재현 가능한지를 판단해야 한다.

Google만의 문제는 아니다. Curl은 2025년 확인된 취약점 비율이 5% 아래로 떨어진 뒤 금전적 바운티를 종료했다. Linux 유지관리자들 역시 중복된 AI 발견 사례가 물결처럼 밀려들자 공개 관행을 변경했다. 이 사례들은 취약점 발견이 취약점 검토보다 더 빠르게 확장됐음을 함께 보여준다.

Google 오픈 소스 버그 바운티, 제품 보고서 접수 중단

자동화된 제출물이 유용한 보안 발견보다 더 많은 검토 업무를 만들면서 Google은 주요 접수 경로 하나를 일시적으로 닫았다.

Open Source Software Vulnerability Reward Program의 약자인 Google OSS VRP는 적격 오픈 소스 프로젝트의 보안 결함을 책임감 있게 공개하는 연구자에게 보상한다. Google은 공개 저장소 내에서 유지관리하는 소프트웨어와 일부 외부 프로젝트를 포괄하기 위해 2022년 이 프로그램을 시작했다.

해당 제품 취약점 채널은 10월 1일부터 신규 보고서 접수를 중단했다. Google은 2027년 1분기 중 추가 업데이트를 제공할 것으로 예상한다고 밝혔다.

Google은 공지에서 “이번 중단은 자동화된 제출이 크게 증가했기 때문이며, 그중 대다수는 유효하지 않다”고 말했다. 이 표현은 자동화와 검증된 취약점 연구를 구분한다는 점에서 중요하다.

이번 중단으로 마감 시점 이전에 제출된 보고서가 사라지는 것은 아니다. 더 넓은 프로그램과 관련된 모든 경로가 닫히는 것도 아니다. 업데이트된 프로그램 규정에 따르면 공급망 취약점 제출은 여전히 대상이다.

Google Cloud 저장소와 관련된 일부 취약점은 여전히 Cloud VRP를 통해 보상 대상이 될 수 있다. Google은 오픈 소스 접수 절차를 검토하는 동안 연구자들에게 다른 보상 프로그램도 안내했다.

이처럼 범위가 좁다는 점에서 “종료”보다 “동결”이 더 정확하다. Google은 OSS 프로그램 내 신규 제품 취약점 제출을 중단했을 뿐, 회사 전반의 외부 보안 연구를 포기한 것은 아니다.

회사는 영향을 받은 채널의 제출 건수, 무효 보고서 비율, 전체 트리아지 적체량을 공개하지 않았다. 따라서 검토자들이 특정 수의 부실 보고서를 받았다는 주장은 검증되지 않은 상태다.

Google이 공개한 내용은 결정적인 신호다. 자동화된 보고서는 기존 절차를 지속할 수 없게 만들 만큼 많아졌고, 신뢰도도 낮아졌다.

그 절차는 잘 다듬어진 문서를 받는 것 이상의 일을 요구한다. 검토자는 코드 경로를 살피고, 조건을 재현하며, 악용 가능성을 판단하고, 중복을 찾고, 담당 프로젝트 팀을 식별해야 한다.

그럴듯한 보고서도 틀렸을 때 상당한 시간을 소모할 수 있다. 대규모 언어 모델은 근본 취약점을 입증하지 않은 채 상세한 설명, 코드 조각, 확신에 찬 심각도 주장을 만들어낼 수 있어 이 문제를 더욱 어렵게 만든다.

Google은 이미 2026년 초 “대규모 급증”한 AI 생성 보고서를 관찰한 뒤 규정을 강화했다. 10월의 중단은 필터링 요건만으로는 수용 가능한 신호 대 잡음 비율을 회복하지 못했음을 시사한다.

이에 따라 Google의 오픈 소스 버그 바운티는 더 광범위한 보안 문제의 시험 사례가 됐다. 이제 주장을 생성하는 비용은 낮지만, 그 주장을 반박하는 비용은 여전히 높다.

AI 버그 보고서가 만드는 비대칭적 비용

AI는 유지관리자가 검증할 수 있는 속도보다 기계가 더 빨리 보고서를 생성할 수 있게 함으로써 공개의 경제성을 바꾼다.

전통적인 버그 탐색은 연구자에게 의미 있는 비용을 부과한다. 사람은 코드베이스를 이해하고, 예상치 못한 동작을 분리하며, 보안 영향을 만드는지 테스트하고, 재현 가능한 사례를 문서화해야 한다.

생성형 AI는 이 작업량의 일부를 줄인다. 에이전트는 저장소를 스캔하고, 함수를 추적하고, 패턴을 비교하며, 개념 증명 코드를 작성하고, 예비 발견을 전문적으로 보이는 보고서로 바꿀 수 있다.

이러한 능력은 정당한 연구자에게 도움이 될 수 있다. 동시에 경험이 부족한 사용자가 자신도 이해하지 못하고 후속 질문에도 방어할 수 없는 주장을 제출하게 만들 수도 있다.

비대칭성은 제출 이후에 나타난다. 보고서를 하나 더 만드는 데는 추가 노력이 거의 들지 않을 수 있지만, 이를 트리아지하는 데는 여전히 희소한 엔지니어링 역량이 소모된다.

Open Source Security Foundation의 최고기술책임자 Christopher Robinson은 3월 보안 보고서에서 이 부담을 설명했다. 그의 추정에 따르면 인기 프로젝트는 한때 평균적인 주에 보고서 두세 건을 받았다. 이후 일부는 한 번에 수백 건을 받았다.

Robinson은 개별 보고서 하나가 계획되지 않은 유지관리자 작업을 2시간에서 8시간까지 요구할 수 있다고 말했다. 최종 결론이 취약점이 존재하지 않는다는 것일 때도 이 비용은 발생한다.

문제는 오탐만이 아니다. 자동화 시스템은 중복된 발견을 보내거나, 문서화된 동작을 잘못 해석하거나, 위협 모델을 무시하거나, 영향이 낮은 결함을 과장할 수 있다.

환각으로 만들어진 취약점은 보고서가 내부적으로 일관되게 들릴 수 있기 때문에 특히 비용이 크다. 검토자는 인용된 함수, 제어 경로 또는 익스플로잇 조건이 지어낸 것임을 발견하기 전까지 상세한 기술적 논증을 따라갈 수 있다.

AI 보안 기업 RunSybil의 공동 창업자 Vlad Ionescu는 이전 AI 슬롭 조사에서 이러한 경험을 설명했다. 그는 보고서가 검토자들이 조사해 모델이 세부 사항을 날조했음을 발견하기 전까지는 기술적으로 타당해 보일 수 있다고 말했다.

이는 검증 병목을 만든다. AI는 가능한 발견의 공급을 늘리지만, 신뢰할 수 있는 검토자의 수를 자동으로 늘리지는 않는다.

버그 바운티는 불확실한 주장을 제출할 금전적 유인도 만든다. 연구자는 추측성 보고서를 많이 보낼 수 있지만, 유지관리자는 검증 비용의 대부분을 부담한다.

평판 시스템과 속도 제한은 남용을 줄일 수 있지만, 자체적인 절충도 수반한다. 엄격한 관문은 플랫폼 이력은 없지만 정당한 발견을 보유한 신규 연구자를 배제할 수 있다.

신원 확인 요건은 법적, 직업적 또는 지리적 위험에 직면한 사람들의 책임 있는 공개를 위축시킬 수 있다. 제출 수수료는 훨씬 더 큰 장벽을 만들 것이다.

자동화된 심사에도 또 다른 문제가 있다. 기계 생성처럼 들린다는 이유로 보고서를 거부하는 필터는 AI 지원을 받아 발견되거나 문서화된 진짜 취약점을 버릴 수 있다.

핵심 구분은 AI가 보고서에 관여했는지가 아니다. 제출자가 동작을 검증했는지, 그리고 재현 가능한 증거로 주장을 뒷받침할 수 있는지다.

에이전트가 설득력 있는 문서를 대규모로 만들 수 있을 때 이 기준을 강제하기는 더 어려워진다. 이제 텍스트 품질은 연구 품질의 신뢰할 만한 신호가 아니다.

실질적인 대응은 더 강력한 증거 요건을 포함할 가능성이 높다. 프로그램은 사람의 검토를 배정하기 전에 최소 재현 사례, 영향받는 버전의 세부 정보, 익스플로잇 추적, 테스트 케이스 또는 작동하는 패치를 요구할 수 있다.

이 요건은 검증 비용의 일부를 다시 제출자에게 돌린다. 또한 코드를 이해하고 질문에 계속 답할 수 있는 연구자에게 유리하다.

Google의 AI 버그 보고서 문제는 AI 보안의 성공이기도 하다

저품질 제출을 만드는 동일한 기술이 인간 연구자가 놓친 실제 취약점도 찾아내고 있다.

모든 AI 지원 보고서를 잡동사니로 취급하는 것은 증거를 잘못 해석하는 일이다. 고도화된 모델은 통제된 환경에서 의미 있는 코드 분석 능력을 보여줬다.

Anthropic은 내부 테스트에서 Claude Opus 4.6이 오픈 소스 프로젝트 전반에서 이전에 알려지지 않았던 취약점 500건 이상을 발견했다고 밝혔다. 회사에 따르면 사람 또는 외부 보안 연구자들이 공개 전에 각 발견을 검증했다.

Mozilla는 2주 동안 그 작업에서 112건의 보고서를 받았다. 그중 다수가 비보안 버그로 분류된 가운데, 14건의 고위험 결함을 포함해 22건의 보안 권고를 발행했다.

이 결과는 대량 자동 제출과 다른 절차를 보여준다. Anthropic은 기계의 발견을 인간 검증, 조율된 공개, 유지관리자와의 집중적인 소통과 결합했다.

한 사례에서 모델은 의심되는 결함이 실제임을 입증하기 위해 개념 증명을 만들었다고 전해진다. 이 단계는 추측성 패턴을 검토자가 테스트할 수 있는 증거로 바꾼다.

Firefox 발견 사례 역시 AI 연구를 전면 금지하는 일이 역효과를 낼 수 있는 이유를 보여준다. 모델은 성숙하고 광범위하게 테스트된 코드도 살펴보며 중대한 결함을 찾아낼 수 있다.

따라서 갈등은 인간 대 AI가 아니다. 검증된 연구와 책임 없는 보고서 생성의 대립이다.

고품질 AI 지원 워크플로에는 인간 책임자가 남아 있다. 그 사람은 결과물을 확인하고, 오탐을 제거하며, 영향을 이해하고, 유지관리자와의 소통에 책임을 진다.

저품질 워크플로는 공개 종점을 또 하나의 자동화된 목적지로 취급한다. 에이전트는 패턴을 식별하고, 심각도 서술을 작성한 뒤, 독립적인 재현 없이 제출한다.

두 워크플로 모두 매끄러운 문장을 만들어낼 수 있다. 그러나 수신자의 업무량을 줄이는 것은 하나뿐이다.

이 구분은 Google의 중단이 AI 버그 탐색의 실패를 증명하지 않는 이유를 설명한다. 이는 해당 제출 구조가 현재의 가치 있는 발견, 중복, 환각이 섞인 흐름을 흡수하지 못했음을 보여준다.

AI 지원 보안은 궁극적으로 이 구조의 양쪽 모두를 개선할 수 있다. 프로그램은 모델을 활용해 중복을 묶고, 주장과 알려진 이슈를 비교하며, 익스플로잇 경로를 테스트하고, 누락된 증거를 식별할 수 있다.

HackerOne과 다른 플랫폼들은 AI 기반 트리아지 지원을 도입하기 시작했다. 이러한 도구는 보고서의 우선순위를 정할 수 있지만, 성능은 잘못된 거부와 놓친 취약점의 비율을 기준으로 측정돼야 한다.

자동화된 검토자도 환각할 수 있다. 프로그램이 연구자와 유지관리자 사이에 모델을 배치한다면, 필터가 자신 있게 분류할 수 없는 발견을 위한 에스컬레이션 경로가 필요하다.

가장 강력한 모델은 계층형일 가능성이 높다. 기계가 비용이 낮은 검사를 수행하고, 숙련된 트리아저가 남은 보고서를 검토하며, 프로젝트 유지관리자는 신뢰할 수 있는 발견만 처리한다.

이 접근 방식은 소프트웨어 기여를 위한 지속적 통합과 닮아 있다. 테스트는 유지관리자가 상세 검토에 시간을 쓰기 전에 명백한 실패를 걸러낸다.

보안 주장은 일반적인 코드 변경보다 테스트하기가 더 어렵다. 악용 가능성은 자동 검사가 오해할 수 있는 맥락, 구성, 신뢰 경계, 공격자 역량에 따라 달라진다.

그럼에도 기계로 확인 가능한 증거를 요구하면 기본 수준을 개선할 수 있다. 실패하는 테스트, 실행 추적 또는 재현 가능한 충돌이 포함된 보고서는 검토자가 평가할 구체적인 대상을 제공한다.

조직에는 이 작업을 위한 지속 가능한 기록도 필요합니다. 검색 가능한 엔지니어링 지식 베이스는 팀이 새로운 발견을 이전 보고서, 결정, 수정 사항과 비교하는 데 도움이 될 수 있습니다.

목표는 정당한 발견 활동을 늦추는 것이 아닙니다. 제한된 인적 검토 예산을 무제한 생성이 소진하지 못하게 하는 것입니다.

Curl과 Linux가 보여주는 업계 전반의 문제

Google의 일시 중단은 AI가 기존 신뢰 체계를 압도한 뒤 오픈 소스 프로젝트들이 공개 채널을 좁혀 온 흐름을 따른다.

Curl은 가장 분명한 선례를 제공합니다. 널리 사용되는 데이터 전송 프로젝트는 2019년부터 운영해 온 금전적 버그 바운티를 2026년 1월 31일 종료했습니다.

유지관리자 Daniel Stenberg는 이 프로그램을 통해 확인된 취약점이 87건이었다고 말했습니다. 그러나 2025년 동안 제출물의 품질 추세는 급격히 악화됐습니다.

Curl은 과거 제출물의 15% 이상을 취약점으로 확인했습니다. 이 비율은 2025년에 5% 아래로 떨어졌으며, 이는 보고서 20건 중 유효한 사례가 1건도 되지 않았다는 뜻입니다.

Stenberg는 세 가지 연결된 추세를 원인으로 지목했습니다. AI 슬롭, 다른 제출물의 품질 저하, 그리고 프로젝트 개선보다 보상에 집중하는 보고자들입니다.

그는 curl의 결정을 발표하며 “끝없이 이어지는 슬롭 제출물을 관리하는 일은 심각한 정신적 부담을 준다”고 썼습니다.

Curl은 보안 제보 접수를 중단하지 않았습니다. 금전 보상은 없앴지만 HackerOne을 권장 채널로 유지했고, 연구자들에게 비공개 GitHub 보고서나 이메일을 이용하도록 안내했습니다.

이 대응은 기술 자체보다 인센티브를 겨냥했습니다. Stenberg는 보상이 정당한 발견을 끌어들이는 한편, 추측성 제출도 지나치게 쉽게 만들었다고 주장했습니다.

그는 이러한 상충 관계도 인정했습니다. 보상을 없애면 잡음은 줄일 수 있지만, 어려운 조사에 상당한 시간을 쓰는 숙련된 독립 연구자들의 동기도 약화될 수 있습니다.

Linux 커널 커뮤니티는 중복 발견과 관련된 유사한 문제에 직면했습니다. 여러 연구자가 동일한 코드에 유사한 AI 도구를 실행하고, 같은 문제를 비공개 채널로 제출했습니다.

비공개 제보는 연구자들이 다른 사람이 이미 해당 발견을 보고하거나 논의했다는 사실을 알 수 없게 했습니다. 유지관리자들은 중복 보고서를 반복적으로 다른 곳으로 안내하거나, 이미 공개된 수정 사항을 가리켰습니다.

Linus Torvalds는 비공개 보안 메일링 리스트가 “거의 전적으로 관리 불가능하다”고 표현했습니다. 그는 비밀 유지가 진정으로 필요한 경우가 아니라면 AI가 탐지한 발견은 일반적으로 공개 프로젝트 채널을 통해 처리돼야 한다고 주장했습니다.

Linux 문서는 제출자에게 요구되는 기준도 높였습니다. 연구자는 간결한 증거를 제공하고, 관련 유지관리자에게 연락하며, 가능하다면 패치를 기여해야 합니다.

이 정책은 인간의 책임성을 유지합니다. AI는 발견을 도울 수 있지만, 사람은 보고서를 이해하고 그 결과에 책임을 져야 합니다.

Google, curl, Linux는 프로그램 구조가 서로 다르기 때문에 각각 다른 개입 방식을 선택했습니다. Google은 한 제출 카테고리를 일시 중단했습니다. Curl은 보상을 없앴습니다. Linux는 많은 보고서를 다른 채널로 유도하고 공개 처리를 강조했습니다.

이들이 공유하는 결론은 개별 정책의 세부 사항보다 더 중요합니다. 자동화 에이전트가 거의 무제한의 주장을 만들어 낼 수 있는 상황에서는, 의미 있는 제출 비용이 없는 공개 접수 방식이 작동하지 않습니다.

가장 큰 위험에 놓인 것은 소규모 프로젝트입니다. Google은 엔지니어를 배정하고 인프라를 재설계할 수 있지만, 자원봉사 유지관리자에게는 전담 분류 팀이 없을 수 있습니다.

오픈 소스 소프트웨어는 상용 제품, 클라우드 서비스, 개발 도구, 핵심 시스템에 흔히 포함됩니다. 그러나 보안 보고서를 검토할 책임은 소수의 무급 기여자에게 돌아갈 수 있습니다.

AI는 이러한 불일치를 증폭합니다. 외부인이 가능한 모든 발견을 검증하고, 패치하며, 조정하는 데 필요한 노동을 제공하지 않은 채 중요한 코드를 지속적으로 스캔할 수 있게 하기 때문입니다.

제출자에게 선의가 있더라도 그 결과는 서비스 거부 문제와 비슷합니다. 각 보고서는 유지관리자의 주의를 요구하며, 누적된 규모는 실제 취약점을 밀어낼 수 있습니다.

더 엄격한 관문은 실제 취약점도 가릴 수 있다

프로그램은 낮은 품질의 제출량을 줄이면서도, 기존 연구자만 접근할 수 있는 보안 체계를 만들지 않아야 한다.

Google의 일시 중단은 단기적으로 검토자를 보호하지만, 정당한 발견을 위한 보고 경로도 없앱니다. 10월 1일 이후 발견된 유효한 제품 취약점은 다른 대상 프로그램이나 제보 채널을 찾아야 할 수 있습니다.

연구자들이 기업의 조직 경계를 항상 이해하는 것은 아니므로 이 마찰은 중요합니다. 오픈 소스 저장소의 결함은 클라우드 제품, 종속성 또는 다운스트림 애플리케이션에 영향을 줄 수 있습니다.

복잡한 라우팅 규칙은 제보 지연이나 잘못된 전달의 위험을 높입니다. 연구자가 허용되는 비공개 채널을 식별하지 못할 때 공개 게시를 부추길 수도 있습니다.

평판 기반 접근 방식도 또 다른 위험을 만듭니다. 경험 많은 연구자는 신뢰하기 쉽지만, 새로운 참여자들도 역사적으로 바운티 프로그램에 중요한 발견을 기여해 왔습니다.

기존 신원을 우대하는 체계는 이미 존재하는 접근 격차를 재현할 수 있습니다. 이는 독립 연구자, 학생, 주요 보안 커뮤니티 밖의 사람들에게 불리하게 작용할 수 있습니다.

엄격한 개념 증명 요건 역시 위험해질 수 있습니다. 악용 가능성을 입증하려면 실제 데이터를 다루거나, 안전 장치를 우회하거나, 프로그램 규칙을 위반하는 테스트를 수행해야 할 수 있습니다.

따라서 프로그램에는 강력하면서도 안전한 증거 기준이 필요합니다. 최소 재현 사례, 통제된 테스트 또는 상세한 코드 경로는 해로운 악용을 요구하지 않고도 신뢰성을 확립할 수 있습니다.

AI 생성 문서를 안정적으로 탐지하는 방법도 없습니다. 연구자들은 기본 작업이 정당한 경우에도 번역, 편집, 코드 설명, 서식 지정에 모델을 흔히 사용합니다.

문체를 근거로 보고서를 거부하면 신중한 제보자를 처벌하고 AI 사용을 숨길 유인을 만들게 됩니다. 또한 보고된 결함이 실제인지도 확인할 수 없습니다.

Google의 공개 성명은 몇 가지 질문에 답하지 않았습니다. 회사는 어떤 선별 조치가 실패했는지, 급증한 제출물에서 얼마나 많은 정당한 발견이 포착됐는지, 어떤 재설계를 검토 중인지 공개하지 않았습니다.

또한 이번 일시 중단이 더 많은 자동화, 더 높은 증거 기준, 제한된 접근 또는 다른 보상 모델로 끝날지도 불분명합니다.

수치의 부재는 외부 평가를 제한합니다. “압도적 다수”라는 표현은 심각성을 전달하지만, 유효성이 기존 기준보다 약간 낮아졌는지 아니면 거의 완전히 붕괴했는지는 보여주지 않습니다.

독자들은 Google의 경험을 보편적인 사례로 받아들이는 것도 피해야 합니다. Mozilla는 업계 전반의 우려가 커졌음에도, 이전 기간 동안 무효 보고서 거부율이 안정적으로 유지됐다고 말한 바 있습니다.

프로그램 설계, 프로젝트의 가시성, 보상 인센티브, 제출 규칙은 모두 보고서의 양과 품질에 영향을 미칩니다. 한 프로젝트에 효과적인 정책이 다른 프로젝트에서는 실패할 수 있습니다.

AI 시스템 자체도 빠르게 변화하고 있습니다. 더 나은 모델은 더 설득력 있는 오탐을 만들 수 있지만, 더 강력한 증명을 생성하고 환각을 줄일 수도 있습니다.

이러한 양방향 변화는 고정된 규칙을 취약하게 만듭니다. 프로그램은 어떤 도구가 보고서를 만들었는지 추측하는 대신 증거를 평가하는 측정 가능한 품질 관리가 필요합니다.

보안 책임자에게 핵심 지표는 단순한 보고서 수가 되어서는 안 됩니다. 유용한 지표로는 확인된 취약점 비율, 중복률, 분류 중앙 소요 시간, 수정 소요 시간, 검토자 업무량 등이 있습니다.

프로그램은 더 많은 보고서를 받으면서도 효율성이 낮아질 수 있습니다. 반대로 더 엄격한 접수는 규모를 줄이는 동시에 유지관리자에게 도달하는 심각한 발견의 비중을 높일 수 있습니다.

따라서 Google OSS VRP의 일시 중단은 이를 대체하는 방식으로 평가해야 합니다. 과부하된 대기열을 닫는 것은 이해할 수 있지만, 지속 가능한 보안 성과를 내려면 유효한 보고서를 위한 신뢰할 수 있는 경로가 필요합니다.

Google 오픈 소스 버그 바운티의 다음 단계

세 가지 신호가 Google의 일시 중단이 더 나은 제보 체계가 될지, 아니면 공개 참여에서 지속적으로 후퇴하는 조치가 될지를 보여줄 것이다.

첫 번째 신호는 Google이 약속한 2027년 1분기 업데이트입니다. 가장 중요한 세부 사항은 자격 요건, 증거 기준, 자동화된 선별, 이의 제기 절차에 관한 내용일 것입니다.

명확한 재현 요건을 갖춘 재개는 Google이 이번 일시 중단을 접수 체계 재설계에 활용했다는 근거를 강화할 것입니다. 무기한 연장은 공개 제출이 여전히 경제적으로 어렵다는 점을 시사할 수 있습니다.

Google이 보고자에게 실행 가능한 테스트, 영향을 받은 커밋, 익스플로잇 추적 정보 또는 제안된 수정을 제공하도록 요구하는지 지켜봐야 합니다. 이러한 규칙은 AI 지원을 금지하지 않으면서 연구자에게 책임을 더 많이 부여할 것입니다.

두 번째 신호는 재개 이후 확인된 보고서 비율입니다. Google은 현재 기준선을 공개하지 않았으므로, 향후 유효성 및 중복률의 투명성은 새 체계를 평가하는 데 도움이 될 것입니다.

공개 접근성이 안정된 상태에서 확인 비율이 높아진다면 더 엄격한 필터링을 뒷받침할 수 있습니다. 참여가 급감한다면 관문이 스팸뿐 아니라 정당한 연구자도 배제하고 있음을 의미할 수 있습니다.

분류 시간도 중요합니다. 검토자가 신뢰할 수 있는 보고서를 더 빠르게 평가할 수 있다면, Google은 재설계가 단지 눈에 보이는 규모를 줄인 것이 아니라 숨은 노동을 줄였다는 증거를 갖게 됩니다.

세 번째 신호는 다른 프로젝트와 플랫폼의 대응 방식입니다. Curl은 보상을 없앴고, Linux는 자동화된 발견을 다른 채널로 유도했으며, Google은 한 제출 카테고리를 일시 중단했습니다.

더 많은 프로그램이 검증된 재현 사례, 패치 요건 또는 평판 기준을 채택한다면, 이러한 관행은 AI 지원 제보의 기본 방식이 될 수 있습니다.

플랫폼은 공동 방어 체계도 구축할 수 있습니다. 프로그램 간 중복 탐지, 표준화된 기계 판독 가능 증거, 책임 있는 에이전트 신원은 반복 작업을 줄일 수 있습니다.

가장 건설적인 결과는 발견 규모와 제출 규모를 분리하는 것입니다. 연구자들은 에이전트를 광범위하게 운용할 수 있지만, 검증되고 중복이 제거된 발견만 인적 검토 대기열에 들어가게 됩니다.

이 모델은 모든 인계 단계에서 책임을 요구합니다. 도구 개발자는 검증을 고려해 설계해야 하고, 연구자는 발견을 테스트해야 하며, 플랫폼은 신중하게 필터링해야 하고, 유지관리자에게는 명확한 에스컬레이션 경로가 필요합니다.

AI 보안 도구를 사용하는 개발자는 이미 그러한 규칙이 존재하는 것처럼 행동해야 합니다. 모든 주장을 재현하고, 영향을 받는 코드를 이해하며, 공개 이슈 이력을 확인하고, 현실적인 영향을 문서화해야 합니다.

또한 제출 이후에도 대응 가능해야 합니다. 기본적인 기술 질문에 답할 수 없는 보고자는 조사 비용 전체를 프로젝트에 전가합니다.

기업에는 이 교훈이 버그 바운티를 넘어 적용됩니다. AI가 콘텐츠 생성을 저렴하게 만들고 평가는 여전히 비싼 상황에서는 모든 공개 접수 시스템이 과부하될 수 있습니다.

지원 대기열, 채용 지원서, 보조금 프로그램, 풀 리퀘스트, 규정 준수 보고서는 같은 근본적 불균형에 직면합니다. 희소한 자원은 더 이상 글쓰기가 아닙니다. 신뢰할 수 있는 검토입니다.

Google의 오픈 소스 버그 바운티 일시 중단은 이 불균형을 높은 위험이 걸린 환경에서 드러냅니다. 잘못된 보안 보고서는 시간을 낭비시키는 반면, 놓친 실제 취약점은 수백만 다운스트림 사용자에게 노출을 초래할 수 있습니다.

과제는 AI와 인간 연구자 중 하나를 선택하는 것이 아닙니다. 자동화가 근거 없는 주장을 늘리는 대신 검증된 보안 작업을 늘리는 제보 체계를 설계하는 일입니다.

Google은 다음 업데이트까지 그러한 체계가 어떤 모습인지 보여줘야 합니다. 더 강력한 증거 관문과 의미 있는 접근성을 갖추고 재개할까요, 아니면 보고서 규모가 커질수록 공개 참여는 계속 축소될까요?