Google OSS VRP 중단이 보여주는 AI 버그 보고의 검증 문제

Google은 무효한 AI 보고서가 검토 절차를 압도한 것으로 알려진 뒤 10월 1일 오픈소스 취약점 프로그램의 한 카테고리를 중단했다.

Google OSS VRP 중단으로 회사가 해당 프로그램 부문을 재설계하는 동안 새로운 ‘Product Vulnerability’ 제출은 받지 않는다. Google은 2027년 1분기 중 업데이트를 제공할 것으로 예상한다.

이 결정이 Google의 모든 취약점 프로그램을 종료하는 것은 아니다. 또한 연구자가 코드 조사에 인공지능을 사용하는 것을 금지하지도 않는다.

대신 자동화된 발견과 인간의 검증 사이에서 커지는 갈등을 드러낸다. AI는 유지보수자가 재현하고, 평가하고, 수정할 수 있는 속도보다 훨씬 빠르게 가능한 발견 사항을 생성할 수 있다.

Google의 조치는 오픈소스 보안 전반에서 수개월간 커져 온 압박 뒤에 나왔다. Linux 유지보수자와 다른 프로젝트들도 중복되거나 추측성인, 혹은 테스트가 부실한 보고서의 유사한 물결에 직면해 왔다.

이 광범위한 양상은 제출 양식 하나가 중단된 사실보다 더 중요하다. 보안 프로그램은 전통적으로 내부 팀이 놓친 문제를 찾은 연구자에게 보상한다. AI는 잠재적 후보를 만드는 비용을 이례적으로 낮춤으로써 이 모델을 바꾼다.

이제 희소한 자원은 초기 의심이 아니다. 결함이 도달 가능하고, 악용 가능하며, 실제 위협 모델과 관련 있음을 입증하는 데 필요한 전문가의 주의력이다.

Google OSS VRP 중단으로 실제로 달라지는 점

Google은 보고 카테고리 하나를 일시 중단했을 뿐, 오픈소스 취약점 연구를 포기하거나 전체 보상금 운영을 닫은 것은 아니다.

OSS VRP로 알려진 Open Source Software Vulnerability Reward Program은 Google 소유 오픈소스 저장소에서 발생하는 적격 보안 이슈를 다룬다. Google은 2022년에 이 프로그램을 도입했다.

제품 취약점 보고서는 프로젝트의 코드, 로직 또는 설계 내 결함을 식별한다. 유효한 보고서는 의심스러운 코드를 가리키는 데 그쳐서는 안 된다.

연구자는 일반적으로 영향을 받는 버전, 도달 가능한 실행 경로, 재현 절차, 그리고 의미 있는 보안 영향을 제시해야 한다. 이러한 요건은 악용 가능한 취약점과 일반적인 프로그래밍 실수를 구분한다.

중단 세부 사항에 따르면, 중단은 Google이 10월 1일 발표하면서 효력이 발생했다. 그 날짜 이전에 제출된 제품 취약점 보고서는 계속 검토 대상이 된다.

공급망 보고서도 계속 접수된다. 이 보고서는 소프트웨어 의존성, 소스 코드, 빌드 또는 릴리스가 사용자에게 도달하는 방식에 영향을 미치는 침해를 다룬다.

Google Cloud 제품에 영향을 미치는 일부 취약점은 별도의 Cloud VRP를 통해 여전히 적격일 수 있다. 적격 여부는 저장소와 해당 저장소가 보장 대상 클라우드 제품과 맺는 연관성에 따라 달라진다.

연구자는 Google의 다른 보상 프로그램에도 참여할 수 있다. 여기에는 Chrome, Android, Google 기기, 클라우드 서비스 및 전용 AI 보안 이슈를 다루는 프로그램이 포함된다.

이 범위 구분은 중요하다. 이번 조치를 완전한 폐쇄라고 부르면 사건을 과장하고 Google의 보다 표적화된 대응을 가리게 된다.

회사는 사실상 대량 유입 경로 하나를 닫는 동시에 더 좁은 채널은 열어 두고 있다. 향후 방향을 논의하기 전에 이 경로를 개편할 계획이다.

정확한 대체안은 아직 알려지지 않았다. Google은 신원, 재현, 제출 빈도 또는 증거 요건을 강화할지 공개적으로 구체화하지 않았다.

Google은 중단 전에도 이미 프로그램을 강화했다. OSS VRP 규정은 연구자에게 AI 보조 발견 사항을 검증하고 실제 보안 영향을 입증하도록 요구했다.

이 규정은 여러 반복적 문제를 설명했다. 일부 AI 생성 보고서에는 잘못된 발동 조건이나 지어낸 기술적 세부 사항이 포함돼 있었다.

다른 보고서는 실제 코딩 오류를 식별했지만 보안상 결과를 확립하지 못했다. 예를 들어 버퍼 오버플로가 존재하더라도 도달할 수 없는 코드에만 있거나 효과적인 보안 경계 뒤에 있을 수 있다.

Google은 특정 하위 등급 제품 취약점과 다른 보안 이슈에 대한 금전적 보상 및 공개 크레딧도 종료했다. 2026년 4월의 이 변경은 영향이 낮은 제출에 대한 인센티브를 없애려는 시도였다.

이후의 중단은 그러한 더 좁은 통제가 검토 부담을 충분히 줄이지 못했음을 시사한다. Google은 부실한 보고서를 억제하는 단계에서 해당 카테고리를 일시적으로 거부하는 단계로 옮겼다.

따라서 Google OSS VRP 중단은 운영상 결정에 해당한다. 프로그램 검토자들은 더 이상 제출되는 모든 가능성을 감당할 수 있는 출발점으로 취급할 수 없었다.

AI 버그 보고는 주장 제기의 비용을 바꿨다

AI는 취약점을 주장하는 비용을 낮추지만, 이를 입증하는 비용은 낮추지 않는다.

전통적인 취약점 연구에서는 연구자가 그럴듯한 보고서를 작성하기 전에 상당한 수작업이 필요했다. 연구자는 코드를 살피고, 실행 경로를 이해하며, 테스트를 구성해야 했다.

현대의 언어 모델과 자율 코드 에이전트는 훨씬 더 빠르게 저장소를 스캔하고 가설을 생성할 수 있다. 또한 신중한 인간 분석처럼 보이는 세련된 보고서를 작성할 수 있다.

그런 외형은 위험한 비대칭을 만든다. 설득력 있는 문서는 생성하는 데 몇 초밖에 걸리지 않을 수 있지만, 그 주장을 반박하는 데는 전문가의 수시간이 소요될 수 있다.

보고서는 의심스러운 메모리 연산을 식별하고 원격 코드 실행을 예측할 수 있다. 이어 모델은 그 예측을 중심으로 상세한 공격 서사를 만들 수 있다.

그러나 영향을 받은 함수는 공격자가 제어하는 입력을 전혀 처리하지 않을 수 있다. 컴파일러가 해당 경로를 제거했을 수도 있고, 기존 검증 절차가 제안된 트리거를 차단할 수도 있다.

프로젝트의 위협 모델이 가정된 공격자 권한을 배제할 수도 있다. 각각의 경우 보고서는 심각하게 들리지만 취약점을 입증하지 못한다.

유지보수자는 자동화된 보고서를 언뜻 보고 모두 안전하게 거부할 수 없다. 형편없이 작성된 제출물에도 실제 결함이 있을 수 있는 반면, 세련된 제출물은 완전히 추측성일 수 있다.

검토자는 코드를 점검하고, 환경을 재현하고, 주장된 입력을 테스트하며, 기존 방어책을 평가해야 한다. 누락된 증거를 위해 보고자에게 연락해야 할 수도 있다.

이 업무량은 무효한 보고서를 포함해 모든 보고서와 함께 증가한다. 따라서 자동화된 제출은 검증 비용을 보고자에서 유지보수자로 이전한다.

이 효과는 전통적인 보안 연구보다 이메일 스팸에 가깝다. 메시지 하나를 더 보내는 비용은 거의 들지 않지만, 수신 조직은 잠재적으로 중요한 각각의 주장을 여전히 필터링해야 한다.

금전적 보상은 이러한 불균형을 심화할 수 있다. 수락된 결과 하나가 수천 건의 제출을 생성하는 비용을 충당한다면, 양을 늘리는 것은 부실한 참여자에게 합리적인 전략이 된다.

그러한 행태는 신중하게 작업하는 연구자에게 피해를 준다. 그들의 발견 사항은 같은 대기열에 들어가 같은 검토자를 두고 경쟁하게 된다.

유지보수자가 확인된 취약점을 수정하는 데 쓸 시간이 줄어들면 사용자에게도 피해가 간다. 트리아지는 수정이 시작되기도 전의 병목이 된다.

문제는 단지 모델이 환각을 일으킨다는 데 있지 않다. 인간 연구자도 실수하고, 영향을 과장하며, 중복 보고서를 제출한다.

AI는 이러한 실패의 규모, 속도, 표현 방식을 바꾼다. 한 사람이 직접 검증할 수 있는 것보다 더 많은 그럴듯한 주장을 만들어낼 수 있게 한다.

이 구분은 AI가 생성한 문구를 금지해도 거의 해결되지 않는 이유를 설명한다. 연구자는 검증되지 않은 모델 출력을 다시 작성해 동일한 근거 없는 주장을 제출할 수 있다.

대신 프로그램에는 증거 기반의 관문이 필요하다. 핵심 질문은 모델이 발견에 기여했는지가 아니라, 보고자가 결과를 테스트했는지다.

Google의 중단은 기존 규정으로는 이 구분을 효율적으로 강제할 수 없었다는 신호다. 문서화된 요건은 산업화된 보고서 물량에 적용하는 것보다 게시하기가 더 쉬웠다.

Google의 AI 보안 전략은 이제 자체적인 절충안에 직면했다

Google은 AI 보조 보안 발견을 장려하지만, 보상 프로그램은 같은 자동화 물결이 만들어내는 모든 발견을 수용할 수 없다.

Google OSS VRP 중단이 회사가 AI를 보안에 쓸모없다고 여긴다는 뜻은 아니다. Google은 자동화된 취약점 발견과 수정에 계속 투자하고 있다.

보안 팀은 OSS-Fuzz, Big Sleep, CodeMender 등의 도구를 사용한다. 이 시스템들은 자동화된 분석을 통제된 테스트 및 전문가 검토와 결합한다.

Google은 이른바 AI 시대에 맞춰 Android와 Chrome 보상 프로그램도 개편했다. 회사는 자동화가 기존 연구가 놓치는 취약점을 발견할 것으로 기대한다.

그렇기에 이번 중단은 의미 있는 방향 전환이다. Google은 AI 보안 연구에서 물러나는 것이 아니라, AI의 낮은 제출 비용에 영향을 받는 외부 채널을 제한하고 있다.

핵심 구분은 인간 연구와 기계 연구의 대립이 아니다. 내부적으로 검증된 자동화와 검증 수준이 고르지 않은 외부 제출 주장 사이의 구분이다.

Google은 자사 시스템을 둘러싼 환경을 통제한다. 엔지니어는 대상을 정의하고, 테스트를 실행하며, 크래시를 수집하고, 생성된 패치가 동작을 보존하는지 측정할 수 있다.

개방형 보상 프로그램에는 그러한 통제가 없다. 참여자는 서로 다른 도구, 프롬프트, 모델, 코드 버전, 보안 영향의 정의를 사용한다.

검토자는 이를 만들어 낸 모든 단계를 보지 못한 채 최종 주장만 받는다. 발견 사항의 중요성을 판단하기 전에 누락된 가정을 재구성해야 한다.

이 차이는 출처 추적을 실질적인 보안 이슈로 바꾼다. 팀은 어떤 리비전이 테스트됐는지, 어떤 입력이 결과를 유발했는지, 인간이 이를 재현했는지를 알아야 한다.

Google의 더 넓은 보상 체계는 여전히 상당한 규모다. 회사는 2025년 동안 자사 프로그램이 700명 이상의 연구자에게 1,700만 달러 이상을 지급했다고 밝혔다.

연간 VRP 검토는 이 총액이 사상 최고라고 설명했다. 금액은 2024년 대비 40% 이상 증가했다.

이 수치는 Google이 외부 연구를 여전히 중시한다는 점을 보여준다. 또한 신뢰할 수 있는 제출 채널을 유지하는 일이 왜 중요한지도 보여준다.

버그 바운티 프로그램은 상호 신뢰에 의존한다. 연구자는 유효한 발견이 공정한 관심을 받을 것이라 믿어야 하며, 기업은 보고자가 주장을 테스트했다고 신뢰해야 한다.

필터링되지 않은 자동화는 양쪽 모두를 약화시킨다. 검토 지연은 역량 있는 연구자를 좌절시키고, 반복되는 무효 보고서는 검토자가 낯선 기여자를 더 의심하게 만든다.

Google의 대응은 트리아지 역량을 보호하지만 접근성도 좁힌다. 독립 연구자는 현재 중단된 OSS VRP 카테고리를 통해 일반 제품 취약점을 제출할 수 없다.

이 제한은 잡음과 함께 가치 있는 발견도 억제할 수 있다. 유효한 이슈를 가진 신규 연구자는 뚜렷한 대체 프로그램이 없을 수 있다.

따라서 과제는 개방성과 검증 사이의 절충안이다. 폭넓은 접근은 발견 기회를 늘리는 반면, 엄격한 관문은 제한된 검토자 시간을 보호한다.

재설계된 프로그램은 두 목표를 모두 보존해야 한다. 진입 요건이 지나치게 부담스러워지면 Google은 참여를 기존 연구자와 전문 기업에 집중시킬 위험이 있다.

요건이 지나치게 느슨하게 유지되면 제출 대기열은 같은 과부하 상태로 돌아갈 수 있다. 2027년 1분기 업데이트는 Google이 그 선을 어디에 그을지 보여줄 것이다.

AI 보고서 홍수는 업계 전반의 문제다

Google의 결정은 보안 커뮤니티가 자동화된 발견에 맞춰 공개 규정을 다시 쓰는 더 큰 변화의 일부다.

HackerOne은 2026년 2월 더욱 성능이 뛰어난 AI 도구가 등장한 뒤 업계 보고서 제출량이 100% 이상 증가했다고 밝혔다.

보고서 제출량 분석에 따르면 일부 제출물에는 유용한 발견이 담겼다. 반면 중복 보고서, 검증할 수 없는 주장, 실행 가능한 수준의 깊이가 없는 보고서도 있었다.

플랫폼은 책임 있는 AI 지원을 금지하는 방식으로 대응하지 않았다. 대신 연구자가 발견 사항을 검증하고 실제 영향을 입증해야 할 의무를 강화했다.

HackerOne의 규정은 재현 가능한 개념 증명, 정확한 심각도 평가, 기존 방어 체계의 고려를 요구한다. 검증되지 않은 보고서를 대량으로 제출하면 제재를 받을 수 있다.

이 접근 방식은 도구가 아니라 운영자에게 책임을 둔다. 연구자는 생성된 모든 엔드포인트, 공격 단계, 영향 주장에 계속 책임을 진다.

Linux 커널 커뮤니티도 이와 유사하게 증거에 초점을 맞춘 접근법을 취했다. 보안 보고 규정은 이제 AI 지원 코드 검토를 직접 다룬다.

문서는 AI 보고서가 지나치게 길어지고 핵심 사실을 가리는 경우가 많다고 말한다. 보고자는 간결한 설명, 영향을 받는 리비전, 트리거 조건, 테스트된 재현 수단을 제공해야 한다.

Linux는 또한 도구가 커널의 위협 모델을 이해하지 못한 채 이론적 영향을 지어낼 수 있다고 경고한다. 대신 보고자에게 검증 가능한 결과를 명시하도록 요구한다.

이 프로젝트는 널리 재현 가능한 자동화 탐지 결과를 전통적으로 비공개로 다뤄지는 발견과 다르게 취급한다. 여러 연구자가 유사한 도구를 실행하기 때문에 같은 문제를 발견하는 경우가 많다.

이는 희소하고 독립적으로 발견된 취약점을 전제로 설계된 공개 채널 안에서 중복 작업을 만든다. 자동화는 이러한 채널의 전제를 바꾼다.

Curl 유지관리자 Daniel Stenberg는 2025년에 이 문제의 또 다른 양상을 설명했다. 그가 말한 “death by a thousand slops”는 부실한 제출물을 검토하는 데 드는 누적 비용에 초점을 맞췄다.

하나의 부실한 보고서는 감당 가능해 보일 수 있다. 그러나 생성된 주장 수백 건에 걸쳐 그 비용이 반복되면 자원봉사자가 유지하는 프로젝트는 지칠 수 있다.

이 사례들은 하나의 공통된 메커니즘을 공유한다. AI는 취약점 가설의 공급을, 자격을 갖춘 트리아지 인력의 공급보다 더 빠르게 늘린다.

영향은 조직마다 다르다. Google은 보수를 받는 보안 엔지니어를 배정할 수 있지만, 소규모 프로젝트는 시간에 제약이 있는 자원봉사자에게 의존하는 경우가 많다.

오픈소스 유지관리자는 특히 어려운 인센티브 구조에 놓여 있다. 공개 코드는 자동화 스캐너가 쉽게 수집할 수 있지만, 유지관리자에게 그에 상응하는 자원이 제공되지는 않는다.

현상금은 또 다른 불균형을 더할 수 있다. 기업은 채택된 발견에 보상할 수 있지만, 커뮤니티 유지관리자는 보상 없이 초기 논의나 업스트림 수정 작업을 맡는다.

그렇다고 자동화된 연구가 본질적으로 해롭다는 뜻은 아니다. AI는 잘 알려지지 않은 구성 요소를 살피고, 낯선 코드를 해석하며, 연구자가 테스트를 만드는 일을 도울 수 있다.

검증 이후에 사용하면 보고서 품질도 높일 수 있다. 모델은 재현 절차를 정리하거나 복잡한 제어 흐름을 더 명확하게 설명할 수 있다.

그러나 이러한 역량이 검증을 대체할 때는 파괴적이 된다. 그럴듯한 서사를 생성하는 일은 악용 가능한 조건을 입증하는 일과 같지 않다.

따라서 새롭게 형성되는 업계 합의는 조건부 수용이다. 인간 운영자가 모든 중요한 주장을 재현하고 방어할 수 있을 때 AI 지원은 여전히 환영받는다.

Google의 일시적 폐쇄는 그 원칙보다 더 제한적이다. 그러나 책임이 어디에 있어야 하는지에 관한 판단은 같다.

보고서를 제출하는 사람은 수신자를 보호할 만큼의 검증 비용을 감수해야 한다. 그렇지 않으면 이 프로그램은 추측성 기계 출력물을 위한 외주 테스트 대기열이 된다.

더 강력한 관문은 도움이 될 수 있지만, 새로운 위험도 만든다

재설계된 프로그램은 정당한 독립 연구자를 배제하지 않으면서 모든 제출물에 검증 비용을 반영해야 한다.

Google은 제품 취약점 제출을 대체할 최종 방안을 공개하지 않았다. 몇 가지 통제 조치는 이전 규정에서 확인된 문제에 부합할 수 있다.

첫 번째는 필수 테스트 재현 수단이다. 재현 수단은 주장된 동작을 일관되게 유발하는 작은 프로그램, 입력 또는 절차를 제공한다.

Google은 보고자에게 정확한 저장소 리비전과 환경을 명시하도록 요구할 수 있다. 이 정보는 오래되었거나 호환되지 않는 코드를 테스트하느라 낭비되는 시간을 줄일 수 있다.

보고서에는 명시적인 도달 가능성 논증도 요구할 수 있다. 보고자는 공격자가 제어하는 데이터가 취약한 연산에 어떻게 도달하는지 보여줘야 한다.

구조화된 위협 모델 필드는 연구자에게 필요한 권한, 신뢰 경계, 기존 완화 조치를 식별하도록 강제할 수 있다. 근거 없는 심각도 주장은 더 쉽게 탐지될 것이다.

속도 제한도 또 다른 선택지다. Google은 한 계정이 일정 기간 동안 제출할 수 있는 미해결 보고서 수를 제한할 수 있다.

이 방식은 신중한 연구자의 접근을 유지하면서 무차별 제출을 억제할 수 있다. 더 높은 한도는 승인된 작업 이력을 바탕으로 부여할 수 있다.

예치금이나 평판 요건은 더 강력한 필터링을 제공할 수 있지만, 공정성 측면의 위험도 더 크다. 신규 연구자는 프로그램에 진입하기 어려울 수 있다.

자동화된 사전 심사도 유력한 구성 요소다. Google은 정적 분석, 샌드박스 실행, 모델 기반 검토를 이용해 중복 보고서와 누락된 증거를 표시할 수 있다.

그러나 자동화 심사가 최종 권한이 되어서는 안 된다. 이례적이지만 유효한 연구를 거부하거나 익숙한 취약점 패턴을 선호할 수 있기 때문이다.

한 모델이 다른 모델의 보고서를 검토하는 경우에도 같은 잘못된 가정을 재현할 수 있다. 독립적인 실행 증거는 텍스트상의 일치보다 여전히 더 가치 있다.

개인정보 보호와 기밀성은 추가적인 복잡성을 만든다. 연구자들은 모델에 분석을 요청하는 과정에서 패치되지 않은 세부 정보를 제3자 AI 서비스에 노출할 수 있다.

개정된 프로그램은 기밀 발견과 관련한 외부 모델 사용을 공개하도록 요구할 수 있다. 또한 어떤 민감한 자료를 호스팅 시스템에 입력할 수 있는지 제한할 수도 있다.

Google은 오픈소스 유지관리자가 트리아지에 어떻게 참여하는지도 명확히 해야 한다. 보고서 하나가 Google 저장소에 영향을 주면서 더 폭넓은 기여자 커뮤니티에 작업을 부과할 수 있다.

회사는 대기열 문제를 검증 의무를 업스트림으로 떠넘기는 방식으로 해결해서는 안 된다. 그렇게 하면 부담을 줄이는 대신 이전할 뿐이다.

중단 기간 동안 투명성은 중요하다. Google은 승인, 중복, 무효, AI 지원 보고서의 세부적인 분류를 공개적으로 제공하지 않았다.

Tom’s Hardware는 엔지니어와 유지관리자가 수천 건의 부실한 제출물에 직면했다고 보도했다. 그러나 Google의 공개 공지는 정확한 제출량이나 승인 비율을 제시하지 않았다.

이 차이는 외부인이 내릴 수 있는 결론을 제한한다. 현재 이용 가능한 증거는 심각한 품질 문제를 뒷받침하지만, 완전한 정량적 그림을 제공하지는 않는다.

Google은 재설계된 기준점을 설명할 수 있을 만큼의 집계 데이터를 공개해야 한다. 유용한 지표로는 중앙값 검토 시간과 작동하는 재현 수단이 없는 보고서의 비율이 있다.

오탐으로 인한 거부율도 중요하다. 자동화 필터가 강력한 발견을 잘못 분류해 사라지게 한다면, 대기열이 빨라져도 성공이라고 할 수 없다.

프로그램은 발견 지원과 자율 제출을 구분해야 한다. 인간이 검토한 AI 발견은 가치 있을 수 있지만, 감독되지 않는 보고서 파이프라인은 관리되지 않는 위험을 만든다.

Google의 가장 강력한 설계는 산문보다 증명을 더 저렴하게 평가할 수 있게 만드는 것이다. 기계 판독형 테스트, 제약된 템플릿, 재현 가능한 환경이 이 목표를 뒷받침할 수 있다.

회사는 비전형적인 발견을 위한 에스컬레이션 경로도 유지해야 한다. 일부 중요한 취약점은 단순한 테스트 사례로 확인하기 어렵거나 복잡한 체인을 수반한다.

어떤 단일 관문도 이 요건들의 균형을 맞출 수 없다. 가장 그럴듯한 해법은 증거 품질, 연구자 이력, 입증된 보안 영향을 기반으로 한 계층형 접근이다.

Google의 2027년 1분기 업데이트 전 주목할 점

다음 단계는 Google이 단순히 더 적은 연구자를 받아들이는 대신 더 나은 증거 기준으로 제출을 재개할 수 있는지를 보여줄 것이다.

첫 번째 신호는 대체 프로그램의 범위다. Google은 제품 취약점 제출을 완전히 재개하는지, 아니면 더 좁은 채널을 통해 다시 받는지 설명해야 한다.

완전 재개는 새로운 필터가 검토 프로세스에 대한 신뢰를 회복했다는 뜻일 수 있다. 제한된 초대 시스템은 트리아지 역량이 여전히 제약돼 있음을 시사한다.

두 번째 신호는 보고자에게 요구되는 증거다. 테스트된 재현 수단, 영향을 받는 커밋, 구체적인 공격 경로는 Google이 이미 확인한 약점을 겨냥한다.

이 요건은 접근성을 유지한다면 프로그램을 강화할 것이다. 불투명한 검토 기준을 기존 연구자만 충족할 수 있다면 프로그램은 약화될 것이다.

세 번째 신호는 다른 보안 프로그램의 대응 방식이다. HackerOne, Linux, 주요 벤더는 모두 AI를 고려한 제출 규정을 실험하고 있다.

이들이 재현 가능성과 인간의 책임으로 수렴한다면, 업계는 공유된 기준선을 발전시킬 수 있다. 이는 여러 프로그램에서 활동하는 연구자의 혼란을 줄일 수 있다.

반대로 프로그램들이 서로 호환되지 않는 제한을 채택한다면 공개는 더 어려워질 것이다. 연구자는 대상마다 서로 다른 증거 패키지, AI 정책, 기밀 유지 관행을 마련해야 할 수 있다.

개발자는 도구 자체도 지켜봐야 한다. 더 나은 에이전트는 작동하는 테스트를 만들 수 있지만, 무효한 증거를 더 큰 확신을 갖고 생성할 수도 있다.

핵심 기준은 에이전트가 얼마나 많은 경고를 찾는지가 아니다. 독립적으로 재현 가능하고 보안상 중요한 발견 중 얼마나 많은 것이 전문가 검토를 통과하는지가 중요하다.

유지관리자는 원시 제출 건수가 아니라 승인된 취약점 하나당 투입되는 시간을 추적해야 한다. 이 지표는 자동화가 보안을 개선하는지, 아니면 단지 대기열만 늘리는지를 포착한다.

연구팀은 AI 지원 작업의 모든 단계를 문서화해 준비할 수 있다. 테스트한 커밋, 구성, 로그, 입력값, 재현에 실패한 시도를 보존해야 한다.

팀에는 이전 발견에 대한 검색 가능한 기록도 필요하다. 구조화된 엔지니어링 지식 베이스는 중복 사례가 유지관리자에게 도달하기 전에 식별하는 데 도움이 될 수 있다.

연구자는 생성된 문구에 의존하지 않고 결함을 설명할 수 있어야 한다. 왜 해당 코드 경로에 도달할 수 있는지, 어떤 기존 통제가 실패하는지 알아야 한다.

그 설명이 없다면 발견은 아직 가설일 뿐이다. 취약점 보상 프로그램에 제출할 준비가 된 것은 아니다.

따라서 Google OSS VRP 중단은 AI 보안 연구에 대한 판결이 아니라 워크플로 설계에 대한 경고다. 발견은 빨라졌지만 검증이 사라진 것은 아니다.

Google의 2027년 1분기 업데이트는 주요 벤더가 이 현실을 중심으로 개방형 프로그램을 재구축할 수 있는지 시험할 것이다. 최선의 결과는 제출량을 극대화하는 것이 아니다.

검토자 주의 시간당 검증된 보안 가치를 극대화하는 것이다. 이 기준은 진지한 연구자에게 분명한 목표를 제시하고 유지관리자를 추측성 물량으로부터 보호한다.

어디에서든 AI 지원 발견을 제출하기 전에 세 가지를 물어야 한다. 다른 사람이 이를 재현할 수 있는가, 실제 보안 경계를 넘는가, 그리고 모든 주요 주장을 테스트했는가?

어느 하나라도 아니라고 답한다면 계속 조사해야 한다. 생성 비용이 가장 낮은 보고서가 유지관리자에게 반박 비용이 가장 큰 보고서가 될 수 있다.