Google OSS VRP 중단이 드러낸 AI 버그 보고서의 숨은 비용

Google은 무효한 AI 보고서가 검토 프로세스를 압도하자 10월 1일부터 오픈소스 버그 바운티를 통한 신규 제품 취약점 제보 접수를 중단했다. Google OSS VRP 중단이 프로그램의 모든 부분을 종료하는 것은 아니다. 그러나 Google이 재설계를 완료할 때까지 주요 제보 경로 하나를 닫는 조치다.

당면한 문제는 인공지능이 소프트웨어 결함을 찾을 수 없다는 데 있지 않다. AI 시스템은 이미 대규모로 면밀한 검토를 거친 코드베이스에서 유효한 결함을 찾아내고 있다. 문제는 그럴듯한 보고서를 생성하는 비용이 이제 보안 영향을 입증하는 비용보다 훨씬 낮아졌다는 점이다.

이 불균형은 취약점 트리아지를 희소한 자원으로 만들었다. Google은 실제 발견 사례를 환각에 기반한 공격 경로, 도달 불가능한 코드, 중복 제보, 일반적인 프로그래밍 오류와 구분해야 한다. GitHub, Linux 유지관리자, 소규모 오픈소스 프로젝트도 같은 압박에 직면하고 있다.

Google은 마감 이전에 제출된 보고서는 계속 검토할 것이라고 밝혔다. 공급망 보고서는 계속 접수되며, 일부 Google Cloud 저장소의 결함은 Cloud Vulnerability Reward Program을 이용할 수 있다. 회사는 2027년 1분기까지 추가 업데이트를 제공할 것으로 예상한다.

이번 중단은 시사하는 바가 큰 충돌을 드러낸다. AI는 방어적 보안 연구를 확장할 것을 약속하지만, 검증되지 않은 자동화는 진짜 취약점을 수정하는 데 필요한 인간의 주의를 소모할 수 있다. AI 보조 버그 헌팅의 미래는 이제 원시적인 발견 물량보다 증거의 품질에 더 크게 좌우된다.

Google OSS VRP 중단은 제한적이지만 즉각적이다

Google은 외부 보안 연구자와의 폭넓은 관계를 포기한 것이 아니라, 한 가지 제보 범주를 동결했다.

영향을 받는 프로그램은 일반적으로 OSS VRP라고 불리는 Open Source Software Vulnerability Reward Program이다. Google은 적격 오픈소스 프로젝트에 영향을 미치는 취약점을 책임감 있게 공개한 연구자에게 보상하기 위해 2022년 이 프로그램을 시작했다.

이 프로그램은 Google 소유의 공개 저장소에 있는 소프트웨어와 다른 곳에서 호스팅되는 일부 프로젝트를 다룬다. 범위에는 제품 취약점과 공급망 침해가 모두 포함되어 왔다. 이 범주는 서로 다른 위험을 다루며, 이제 서로 다른 제보 경로를 따른다.

제품 취약점은 프로젝트의 코드, 로직 또는 설계 내부의 결함을 뜻한다. 설득력 있는 보고서는 공격자가 해당 결함에 도달할 수 있고, 의미 있는 보안상 결과를 낳을 수 있음을 보여야 한다. 단지 안전하지 않아 보이는 함수를 식별하는 것만으로는 익스플로잇 가능성이 입증되지 않는다.

공급망 보고서는 소프트웨어가 빌드, 패키징, 서명 또는 배포되는 방식에 대한 위협을 다룬다. 손상된 릴리스 파이프라인은 기반 소스가 정상으로 보이더라도 악성 코드를 확산시킬 수 있다. Google은 이 제보 범주를 계속 열어두고 있다.

중단 조치는 2026년 10월 1일 이후 제출된 신규 제품 취약점 보고서에 적용된다. 이전 제출 건은 기존 절차에 따라 검토 대상 자격을 유지한다. Google은 해당되는 경우 연구자들을 다른 취약점 보상 프로그램으로 안내했다.

Google Cloud 저장소와 관련된 일부 보고서는 여전히 Cloud VRP를 통해 자격을 얻을 수 있다. 이 예외는 소스 저장소가 단순히 Google 소유인지가 아니라, 문제가 Google Cloud 제품에 영향을 미치는지에 달려 있다.

Google은 X의 Bug Hunters 계정을 통해 변경 사항을 발표했다. 최초의 상세한 공개 보도에 따르면, 회사는 이번 결정이 무효한 AI 기반 제보의 급증과 관련 있다고 설명했다.

이번 중단은 갑작스러운 정책 전환이 아니라 수개월간의 규정 강화 뒤에 나왔다. Google은 4월 규정 업데이트에서 OSS VRP에 유입되는 저품질 및 무효 보고서가 급증했다고 설명했다.

Google은 반복적으로 나타나는 두 가지 패턴을 지목했다. 일부 제보에는 주장된 취약점이 어떻게 트리거될 수 있는지에 대한 환각성 설명이 담겼다. 다른 제보는 실제 코딩 실수를 찾아냈지만, 도달 가능한 코드나 실질적인 보안 영향을 입증하지 못했다.

이 구분은 소프트웨어 결함과 보안 취약점이 서로 바꿔 쓸 수 있는 개념이 아니기 때문에 중요하다. 도달할 수 없는 테스트 유틸리티에서 발생하는 크래시는 프로덕션 서비스의 원격 코드 실행과 다른 결과를 낳는다.

Google은 이미 우선순위가 낮은 프로젝트 계층에서 특정 제품 취약점과 기타 보안 문제에 대해 보상이나 크레딧을 제공하지 않기 시작했다. 또한 실행 가능한 발견 사항, 검증된 재현 단계, 영향 입증을 강조했다.

따라서 10월 조치는 노이즈를 줄이기 위한 기존 노력을 확장한 것이다. 보고서가 계속 유입되는 가운데 자격 기준을 조정하는 대신, Google은 광범위한 재설계 기간에 영향을 받는 접수 채널을 닫았다.

회사는 거부된 보고서의 정확한 수, 백로그 규모, 또는 승인 비율을 공개하지 않았다. 수천 건의 제보에 관한 주장은 완전한 프로그램 통계가 아니라 보도된 수치에 해당한다.

이 데이터의 부재는 외부 분석에 한계를 둔다. 그러나 규정 변경, 공개 경고, 최종 동결로 이어진 흐름은 점진적인 필터링만으로는 업무량 문제를 해결하지 못했음을 보여준다.

무효한 AI 버그 보고서가 보안 트리아지를 무너뜨리는 이유

AI는 제보가 자동으로 확장되는 반면 검증에는 여전히 희소한 인간의 판단이 필요하기 때문에 보고의 경제성을 바꾼다.

전통적인 취약점 연구에는 여러 비용이 큰 단계가 필요하다. 연구자는 대상을 이해하고, 약점을 식별하며, 재현 가능한 공격을 구축하고, 영향을 평가하고, 결과를 명확하게 전달해야 한다.

대규모 언어 모델은 이 작업의 일부를 가속할 수 있다. 소스 코드를 검사하고, 위험한 데이터 흐름을 제안하며, 테스트 케이스를 작성하고, 거친 메모를 정제된 문장으로 바꿀 수 있다. 자동화 에이전트는 많은 저장소에서 이러한 단계를 반복할 수 있다.

같은 도구는 자신감 있어 보이지만 잘못된 설명도 만들어낼 수 있다. 모델은 공격자가 신뢰된 상태로 유지되는 입력을 제어한다고 가정할 수 있다. 권한 검사를 놓치거나, 배포 구성을 오해하거나, 도달 가능한 실행 경로를 꾸며낼 수 있다.

이러한 실패는 제출 이후 비용이 커진다. 보안 엔지니어는 어조만으로 신뢰할 만해 보이는 보고서를 거부할 수 없다. 엔지니어는 인용된 코드를 검사하고, 조건을 재현하고, 데이터를 추적하며, 주장된 영향이 실제로 존재하는지 테스트해야 한다.

따라서 허위 보고서는 만드는 데 몇 분이면 충분하지만, 기각하는 데는 몇 시간이 걸릴 수 있다. 악의적 의도가 없더라도 유사한 보고서 수천 건은 이 불균형을 운영상의 서비스 거부로 바꾼다.

보고서의 표현 방식은 문제를 더 악화시킬 수 있다. 언어 모델은 긴 취약점 서술, 심각도 라벨, 공격 다이어그램, 완화 조언을 쉽게 만들어낸다. 하지만 그 어떤 추가 요소도 작동하는 재현 사례를 대체하지 못한다.

정제된 문장은 실제로 트리아지 비용을 높일 수 있다. 검토자는 생성된 맥락이 여러 페이지에 걸쳐 있는 상황에서 사실적 주장을 찾아야 한다. 또한 어떤 진술이 테스트에서 나왔고 어떤 진술이 모델 추론에서 나왔는지도 판단해야 한다.

Google의 이전 규정은 탐지와 검증의 차이에 초점을 맞췄다. 정적 분석기의 경고는 의심스러운 코드를 식별할 수 있다. 그러나 그 코드가 익스플로잇 가능한 보안 경계 위반을 초래한다는 것을 자동으로 증명하지는 않는다.

도달 가능성은 필수적인 검증 기준 중 하나다. 검토자는 현실적인 조건에서 신뢰할 수 없는 입력이 위험한 연산으로 이동할 수 있다는 증거를 필요로 한다. 보고서는 정제 처리, 권한, 구성 및 기존 방어책도 고려해야 한다.

영향도 또 다른 검증 기준이다. 버퍼 오버플로는 심각하게 들리지만, 그 위치와 주변 통제 장치에 따라 공격자가 달성할 수 있는 결과가 달라진다. 일부 결함은 데이터나 제어권을 노출하지 않고 격리된 프로세스만 종료시킨다.

신규성도 중요하다. 자동화 시스템은 이미 알려진 문제를 재발견하거나, 이전에 거부된 이론을 반복하거나, 같은 근본 원인에 대한 여러 설명을 만들어낼 수 있다. 중복 보고서 하나하나가 여전히 접수 및 검토 역량을 소모한다.

이 업무량은 전문 인력에게 집중된다. 경험 많은 유지관리자와 보안 엔지니어는 모델이 자주 놓치는 아키텍처 가정을 이해한다. 이들을 반복적인 검증 업무에 투입하면 패치, 감사, 설계 검토, 사고 대응이 지연된다.

기회비용은 Google을 넘어선다. 오픈소스 프로젝트는 코드가 널리 사용되는 서비스를 뒷받침하더라도 유지관리자 그룹이 작은 경우가 많다. 자동화된 보고서 캠페인은 이들의 전체 보안 역량을 초과할 수 있다.

팀은 결정, 재현 사례, 이전 발견 사항을 검색 가능한 엔지니어링 지식 베이스에 보관해 맥락을 유지할 수 있다. 이 관행은 반복 조사를 줄이지만, 전문가 검증의 필요성을 없앨 수는 없다.

Google의 버그 바운티 중단은 이러한 노동 제약을 가시화한다. 보안 프로그램은 제보에 의미 있는 연구자 노력이 담긴다는 전제 아래 설계되었다. AI는 제출자가 그 노력의 상당 부분을 수신 팀으로 이전할 수 있게 한다.

AI 버그 보고서가 만드는 것은 품질 문제이지 AI 금지가 아니다

핵심 충돌은 인간 연구자와 인공지능 사이의 대립이 아니라, 검증된 연구와 검증되지 않은 자동화 사이의 대립이다.

Google은 연구자들이 AI 사용을 완전히 피해야 한다고 주장하지 않았다. 회사의 명시된 입장은 연구 수행 중 사람이 AI 출력을 검증해야 한다는 것이다. 이 요건은 AI를 책임을 지는 제보자가 아니라 도구로 취급한다.

유용한 AI 보조 제보에는 여전히 직접적인 증거가 포함될 수 있다. 연구자는 영향을 받는 버전, 정확한 명령어, 최소화된 테스트 케이스, 로그, 스크린샷, 관찰된 결과를 제공할 수 있다. 또한 위반된 보안 경계를 설명할 수 있다.

결정적인 질문은 사람이 해당 주장을 확인했는지 여부다. 모델이 생성한 가설은 테스트를 통해 관련 코드가 도달 가능하며 결과가 기밀성, 무결성 또는 가용성에 영향을 준다는 점이 입증될 때 가치가 생긴다.

이 기준은 정당한 자동화를 보호한다. 퍼저는 예상치 못한 입력을 보내고 실패를 기록하는 방식으로 수년간 보안 발견을 만들어왔다. 그 가치는 설득력 있는 설명이 아니라 구체적이고 재현 가능한 출력에서 나온다.

AI 에이전트는 이 모델을 확장할 수 있다. 소스 코드에 대해 추론하고, 하니스를 만들고, 크래시를 조사하며, 패치를 제안할 수 있다. 더 넓은 탐색 공간은 기존 도구가 놓치는 결함을 드러낼 수 있다.

하지만 추론 시스템은 또 다른 실패 방식을 도입한다. 그럴듯한 언어로 누락된 증거를 메울 수 있다. 기존 스캐너는 일반적으로 탐지한 패턴을 보고하지만, 언어 모델은 전체 공격 서사를 꾸며낼 수 있다.

이 차이는 공개 프로그램이 보고서를 유창성만으로 평가할 수 없는 이유를 설명한다. 검토자는 관찰 가능한 동작과 연결된 산출물을 필요로 한다. 이론적 결과에 대한 주장은 입증된 결과보다 신뢰 수준이 낮아야 한다.

AI를 일괄적으로 거부하는 방식에 대한 가장 강력한 반증은 성공적인 AI 보안 연구에서 나온다. AI 시스템은 인간 검토자가 놓친 결함을 포함해 주요 오픈소스 프로젝트에서 실제 취약점을 발견했다.

이러한 결과는 AI 보조 보고서를 전부 금지하는 것이 근시안적인 이유를 보여준다. 방어팀은 특히 대규모 의존성 그래프와 성숙한 코드베이스 전반에서 더 넓은 커버리지를 원한다. 이들이 원하지 않는 것은 무제한의 검증되지 않은 추측이다.

Google 자체도 방어적 보안 연구에 AI를 사용한다. 회사의 광범위한 보안 활동에는 AI 보조 취약점 발견과 오픈소스 퍼징이 포함된다. 회사의 이의는 제보 경계에서의 검증 품질에 관한 것이다.

그 경계는 책임성에 관한 질문을 낳는다. 자율 에이전트가 보고서를 제출했을 때, 후속 질문에는 누가 답하는가? 누군가는 가정을 명확히 하고, 재현 절차를 수정하며, 관찰된 동작과 예측된 동작을 구분해야 한다.

책임을 지는 연구자가 없는 보고서는 그 업무를 유지보수자에게 넘긴다. 수신자는 제출자가 시작한 조사를 완료할 책임을 떠안게 된다.

AI 사용을 명확히 공개하면 도움이 될 수 있지만, 공개만으로 품질이 보장되지는 않는다. 사람이 작성한 보고서도 틀릴 수 있다. AI가 생성한 보고서도 정확하고 간결하며 철저히 검증됐을 수 있다.

따라서 프로그램에는 문체 감지기보다 증거 기반의 관문이 필요하다. 특히 연구자가 템플릿을 사용하거나 제2언어로 작성할 때 AI 텍스트 분류기는 기술 문서를 잘못 분류할 수 있다.

더 나은 접수 시스템은 보고서의 실질을 검증한다. 최소 재현 사례, 환경 세부 정보, 영향을 받는 커밋, 도달 가능성의 증거, 그리고 공격자 역량에 대한 직접적인 설명을 요구할 수 있다.

Google OSS VRP의 중단은 회사가 이러한 관문을 설계할 시간을 준다. 다만 평판은 없지만 유효한 발견을 한 유능한 신규 연구자까지 더 엄격한 시스템이 배제할 위험이 있다.

이러한 상충관계는 사라질 수 없다. 누구나 참여할 수 있기 때문에 개방형 프로그램은 예상치 못한 발견을 끌어들인다. 접근을 제한하면 평균 품질은 높아지지만, 알려지지 않은 연구자가 적절한 팀에 도달할 가능성은 줄어든다.

GitHub와 오픈소스 유지보수자도 같은 관문을 강화하고 있다

Google의 결정은 개방형 접수에서 평판, 증거, 더 좁은 제출 채널로 옮겨 가는 업계 전반의 흐름에 속한다.

GitHub도 2026년에 저품질 및 AI 생성 보고서의 적체를 겪었다. 이에 버그 바운티 프로그램을 재편하고 공개 연구자와 초대 연구자를 위한 별도 경로를 만들었다.

공개 프로그램에는 연구자의 기존 플랫폼 기록을 적격성 기준으로 사용하는 HackerOne 신호 요건이 추가됐다. 초대 프로그램은 이미 신뢰를 쌓은 연구자에게 별도의 경로를 제공한다.

GitHub는 진지한 외부 연구를 보존하면서 저노력 제출량을 줄이는 것이 목표라고 밝혔다. 재편 발표는 2026년 7월 27일부터 제출된 보고서에 새 구조를 적용했다.

이전 가이드라인은 플랫폼이 유용한 증거로 간주하는 요소를 설명했다. 강력한 보고서에는 간결한 요약, 뒷받침 자료를 포함한 재현 단계, 달성 가능한 공격자 영향에 대한 명확한 설명이 필요했다.

GitHub는 이론적 서술과 AI가 생성한 군더더기가 트리아지를 늦춘다고도 경고했다. 문제는 단순히 부정확한 콘텐츠가 아니었다. 과도한 설명은 실제 발견을 묻어버리고 검토를 지연시킬 수 있다.

Google과 GitHub는 서로 다른 즉각적 대응을 택했다. GitHub는 더 강력한 평판 및 품질 관문을 갖춘 공개 경로를 유지했다. Google은 다른 취약점 프로그램은 열어 둔 채 하나의 OSS VRP 범주를 중단했다.

두 접근법 모두 검토자의 주의를 보호한다. 하지만 플랫폼 평판을 아직 쌓지 못한 신규 연구자에게는 마찰을 만든다. 뛰어난 첫 보고서는 긴 바운티 이력이 없는 사람에게서도 나올 수 있다.

오픈소스 유지보수자는 이 문제의 더욱 날카로운 형태에 직면한다. 많은 프로젝트에는 전담 보안 인력, 유급 트리아지 팀 또는 공식 제출 인프라가 없다. 유지보수자는 개인 시간을 내어 보고서를 검토할 수 있다.

업계 가이드라인은 점차 양측 모두에게 책임을 부여하고 있다. Open Source Security Foundation은 연구자에게 발견 사항을 검증하고, 프로젝트 정책을 이해하며, AI가 작업에 어떻게 기여했는지 명확히 공개하라고 조언한다.

이 단체의 유지보수자 가이드는 AI가 정당한 방어적 분석을 지원할 수 있다는 점도 인정한다. 권장되는 대응은 안전한 통합과 사람의 검토에 초점을 둔다.

더 넓은 패턴은 스팸 통제와 닮아 있다. 전송 비용이 거의 무료가 되면 수신자는 필터, 평판 신호, 속도 제한 또는 제출 비용을 도입해야 한다. 그렇지 않으면 저품질 물량이 가치 있는 소통을 압도한다.

버그 바운티 프로그램은 일반적인 스팸 필터를 그대로 복제할 수 없다. 보안 보고서에는 새로운 기술적 세부 사항이 담기며, 대개 알려지지 않은 연구자가 보낸다. 이례적인 콘텐츠를 지나치게 공격적으로 거부하면 가장 중요한 발견을 숨길 수 있다.

프로그램은 여러 통제 수단을 결합할 가능성이 크다. 구조화된 양식은 구체적인 답변을 강제할 수 있다. 자동화된 검사는 필수 산출물이 존재하는지 시험할 수 있다. 평판은 절대적인 적격성 대신 제출 한도를 결정할 수 있다.

자율 에이전트에는 속도 제한이 특히 중요해질 수 있다. 사람은 여러 기계 생성 후보를 검토한 뒤 가장 강력한 것만 제출할 수 있다. 무인 시스템은 유지보수자가 피드백을 제공하기 전에 프로그램을 대량 제출로 뒤덮을 수 있다.

예치금이나 환불 가능한 제출 보증금은 더 강한 비용을 만들지만, 접근성 우려를 낳는다. 저소득 지역의 연구자는 불균형적으로 큰 장벽에 직면할 수 있다. 법적·행정적 복잡성도 늘어난다.

비공개 또는 초대 전용 프로그램은 공개 물량을 피하지만 광범위한 참여를 잃는다. 이들은 알려진 연구자에게 신뢰를 집중시키므로, 특정 구성 요소에 대한 전문 지식을 지닌 외부인을 놓칠 수 있다.

따라서 Google의 재설계는 한 회사를 넘어서는 함의를 가진다. 다른 프로그램 운영자는 이것이 새로운 인재에게 문을 닫지 않으면서 신호를 회복하는지 지켜볼 것이다.

더 엄격한 필터는 실제 취약점도 가릴 수 있다

AI 노이즈를 줄이는 일은 필요하지만, 모든 필터는 유효하지만 낯선 보고서가 적절한 엔지니어에게 도달하지 못할 가능성을 만든다.

Google은 중단 사유를 설명했지만 완전한 성과 데이터는 공개하지 않았다. 외부인은 AI 도입 전후의 오탐률을 비교하거나 적체의 실제 심각도를 측정할 수 없다.

이 수치가 없으면 여러 해석이 가능하다. AI 생성 제출이 대기열을 지배할 수도 있고, 반복적으로 보고하는 소규모 집단이 부담 대부분을 만들 수도 있다. 원인이 다르면 통제 수단도 달라져야 한다.

기반 모델의 품질도 중요하다. 현재의 환각 비율을 기준으로 설계된 정책은 빠르게 낡을 수 있다. 더 나은 에이전트는 더 강력한 재현 사례를 만들 수 있지만, 더 많은 보고서 물량도 생성할 수 있다.

프로그램 설계는 확신과 증거를 구분해야 한다. 익스플로잇 가능성에 높은 확률을 부여하는 에이전트가 이를 입증한 것은 아니다. 반대로 불완전한 보고서라도 후속 조사가 필요한 심각한 결함을 설명할 수 있다.

신규 연구자는 공개 경험이 부족하기 때문에 불완전한 보고서를 자주 제출한다. 근본 관찰이 진실하더라도 그들의 글은 저품질 자동 생성 결과물과 비슷해 보일 수 있다.

언어와 접근성도 유사한 위험을 만든다. 세련된 영어를 요구하면 깊은 기술 지식을 가진 연구자가 불리해질 수 있다. 양식은 문체를 신뢰성의 대리 지표로 바꾸지 않으면서 구체적인 증거를 요구해야 한다.

평판 관문은 기존 접근성을 더욱 강화하기도 한다. 기존 연구자는 신호를 쌓을 기회를 더 많이 받는 반면, 신규 연구자는 진입에 어려움을 겪는다. 폐쇄적 순환은 효율성을 높일 수 있지만 다양성을 약화시킨다.

수신 측 자동화도 또 다른 불확실성을 제시한다. Google은 모델을 이용해 보고서를 요약, 중복 제거 또는 우선순위화할 수 있다. 거짓 음성은 거짓 양성과 다른 결과를 낳기 때문에 이러한 시스템은 감사를 받아야 한다.

거짓 양성은 검토자의 시간을 낭비한다. 거짓 음성은 취약점을 발견하지 못한 채 남길 수 있다. 따라서 접수 시스템은 최종 거부보다 라우팅과 증거 검사를 더 적극적으로 자동화해야 한다.

이의 제기는 하나의 안전장치가 된다. 거부된 연구자는 어떤 요소가 실패했는지, 추가 증거로 보고서를 다시 열 수 있는지 이해할 수 있어야 한다. 일반적인 거부 메시지는 반복 제출과 공개적인 불만을 부추긴다.

투명한 사례도 행동을 개선할 수 있다. 프로그램은 도달할 수 없는 코드, 뒷받침되지 않는 영향 주장, 중복의 근본 원인, 수용 가능한 재현 사례를 보여 주는 익명화된 사례를 공개할 수 있다.

Google은 이미 자사의 취약점 프로그램 전반에 걸쳐 보고 가이드를 제공한다. 품질 프레임워크는 대상 정보, 재현 가능성, 영향 및 소통을 강조한다.

재설계는 이러한 기준을 기계적으로 강제되는 전제 조건으로 만들지 결정해야 한다. 또한 공식 필드가 빠졌더라도 사람의 재량을 받을 만한 보고서가 무엇인지 판단해야 한다.

원치 않는 모든 제출을 AI 슬롭으로 규정하는 데에도 또 다른 위험이 있다. 이 라벨은 위협 모델을 둘러싼 진정한 이견을 가릴 수 있다. 연구자와 공급업체는 익스플로잇 가능성을 서로 다르게 평가하곤 한다.

회사는 공격자에게 사용자 상호작용이 필요하다는 이유로 이슈를 거부할 수 있다. 연구자는 그 상호작용이 여전히 현실적이라고 주장할 수 있다. 이러한 분쟁은 생성형 AI보다 앞서 존재했으며, 저작자 탐지로 해결할 수 없다.

같은 주의는 일반적인 코드 결함에도 적용된다. 일부 버그는 즉각적인 영향이 없지만 다른 제품 변경 이후 위험해질 수 있다. 프로그램에는 경계가 필요하지만, 그러한 경계를 심각도에 관한 보편적 판단으로 오해해서는 안 된다.

따라서 이 중단은 트리아지 개입이지, 영향을 받은 저장소가 더 안전해졌다는 증거가 아니다. 하나의 보고 경로가 닫혀 있는 동안에도 취약점은 계속 존재한다.

연구자는 다른 적절한 채널을 찾거나 관련 프로젝트에 직접 연락해야 한다. 분산된 공개 경로는 지연, 우발적 공개 및 중복 작업을 늘릴 수 있다.

Google은 제외된 보고서를 명확히 라우팅해 이 위험을 줄일 수 있다. 공개 프로그램 디렉터리는 이미 Google, Cloud, Chrome, Android, AI, 악용 및 오픈소스 범위를 구분한다.

유효한 연구자가 올바른 목적지를 예측할 수 있을 때만 재설계는 성공한다. 심각한 보고서가 중첩된 프로그램 규칙 사이에서 사라진다면, 대기열이 작아져도 의미가 거의 없다.

Google이 제품 보고서를 다시 열기 전에 주목할 점

다음 시험대는 Google이 개방형 제출함을 낯선 연구자를 침묵시키지 않으면서 증거를 검증하는 시스템으로 대체하는지 여부다.

첫 번째 신호는 2027년 1분기까지 약속된 업데이트다. Google은 제품 취약점 제출이 다시 열리는지, 다른 곳으로 옮겨지는지 또는 제한된 접근 절차를 통해 돌아오는지 명확히 해야 한다.

구조화된 증거 요건을 갖춘 재개는 이 중단이 일시적인 트리아지였다는 견해를 뒷받침할 것이다. 기한 없는 폐쇄는 Google이 기존 공개 모델을 더 이상 지속 가능하다고 보지 않는다는 뜻이 될 것이다.

두 번째 신호는 접수 관문의 설계다. 필수 재현 사례, 영향받는 버전, 테스트한 커밋, 실행 추적 및 간결한 영향 설명은 문서화된 실패 유형을 직접적으로 해결할 것이다.

평판만을 기준으로 한 제한은 다른 선택을 의미한다. 이런 제한은 물량을 빠르게 줄일 수 있지만, 각 보고서 안의 증거보다 연구자 이력에 더 큰 비중을 둔다.

자율 에이전트에 대한 Google의 대응은 특히 중요할 것이다. 회사는 모든 제출이 재현됐다는 사실을 이름이 명시된 사람이 보증하도록 요구할 수 있다. 기계 보조 보고에 속도 제한을 부과할 수도 있다.

의미 있는 정책은 AI 지원과 무인 대량 제출을 구분해야 한다. 연구자들은 일상적으로 자동화, 디버거, 퍼저, 스캐너 및 언어 모델을 사용한다. 결정적인 문제는 누가 주장을 검증하고 책임지는가다.

세 번째 신호는 적체가 확인된 발견을 줄이지 않고 개선되는지 여부다. Google은 그 비교에 충분한 데이터를 공개하지 않았지만, 향후 투명성은 다른 프로그램이 재설계에서 배울 수 있도록 도울 것이다.

유용한 지표에는 제출량, 검증 시간, 중복률, 수용된 발견, 보고자 이의 제기, 그리고 작동하는 재현 사례를 포함한 보고서의 비율이 포함될 것이다. 집계 수치는 민감한 세부 사항을 보호할 수 있다.

연구자들은 Google의 다른 VRP도 주시해야 한다. 유효하지 않은 AI 버그 보고서가 Cloud, Chrome 또는 일반 Google 채널로 이동한다면, 이번 중단 조치는 문제를 해결한 것이 아니라 업무 부담을 옮긴 셈이 된다.

회사의 더 광범위한 버그 바운티 시스템은 계속 운영된다. Google의 프로그램 디렉터리는 여전히 자격을 갖춘 보안 이슈를 여러 전문 프로그램으로 안내하고 있다.

Google 외부의 유지관리자들은 최종 정책을 기다릴 필요가 없다. 허용되는 증거를 정의하고, 위협 모델을 공개하며, 자동화된 제출을 제한하고, 관찰 결과와 추정된 영향을 구분하는 템플릿을 만들 수 있다.

연구자들 역시 적응할 수 있다. 제출 전에 동작을 재현하고, 테스트 사례를 최소화하며, 영향을 받는 리비전을 확인하고, 공격자에게 필요한 접근 권한을 설명해야 한다.

발견 사항을 뒷받침하지 않는 생성형 배경 설명은 제거해야 한다. 불확실한 전제를 중심으로 구성한 매끄러운 에세이보다, 직접적인 증거를 담은 짧은 보고서가 검증하기 쉽다.

AI 지원 보안 연구는 정당한 이점이 상당하기 때문에 계속 확대될 것이다. 모델은 더 많은 코드를 탐색하고, 표적화된 테스트를 생성하며, 조사자가 익숙하지 않은 구성 요소 간의 연관성을 파악하도록 도울 수 있다.

하지만 이제 발견 건수는 더 이상 진전을 측정하는 최선의 기준이 아니다. 보고서는 유지관리자가 조치할 수 있을 만큼 신뢰할 수 있는 증거를 제공할 때에만 유용해진다.

Google OSS VRP의 중단은 이 구분을 더 이상 무시할 수 없게 된 순간을 보여준다. 다음 프로그램 설계는 검증된 통찰에 보상하고, 접근성을 보존하며, 사람의 주의가 실제 위험에 집중되도록 해야 한다.

다음 AI 지원 발견 사항을 제출하기 전에, 모델이 의심스러운 코드를 찾았는지보다 더 어려운 질문을 던져야 한다. 제공된 증거만으로 다른 엔지니어가 보안 영향을 재현할 수 있는가?