Google도 AI 보안 제보를 멈췄다: 버그 바운티가 살아남는 새 triage 법

2026.10.05dev

Google이 OSS VRP의 제품 취약점 접수를 2026년 10월 1일부터 멈춘 이유는 AI가 보안 연구를 망쳐서가 아니라, 증거 없는 자동 제출의 검토 비용을 사람이 떠안게 됐기 때문이다. 제품 취약점과 공급망 취약점을 나누고, 작은 팀이 AI 보조 제보를 받을 때 필요한 재현·증거·라우팅 기준을 정리한다.

Google이 오픈소스 버그 바운티를 “닫았다”는 식으로 보면 반만 맞다. 정확한 변화는 더 실무적이다. Google은 2026년 10월 1일부터 OSS VRP(Open Source Software Vulnerability Reward Program)의 제품 취약점(product vulnerability) 신규 제출을 받지 않기로 했고, 공급망 compromise 보고와 이미 접수된 보고는 계속 분리해 둔다.Google 공식 이유는 AI가 보안 연구를 전부 망쳤기 때문이 아니라, 자동 제출물이 늘면서 “대부분 유효하지 않은 보고서”를 사람이 읽고 재현해야 하는 비용이 커졌기 때문이다.TechCrunch

이 글의 독자 질문은 하나다. 작은 개발팀이나 오픈소스 운영자가 AI 보조 보안 제보를 받아야 한다면, 무엇을 막고 무엇을 남겨야 할까? 결론부터 말하면 “AI 사용 금지”가 아니라 “재현 가능한 증거가 없는 제출을 큐에 넣지 않는 구조”가 필요하다. 기준 시점은 2026년 10월 5일 아침이며, Google 공식 규칙 페이지와 TechCrunch 보도, promppy 실시간 신호를 대조했다.promppy 신호

AI로 자동 생성된 취약점 보고서가 붉은 대기열에 쌓이고, 검증된 공급망 보고서는 별도 차선으로 흐르는 보안 triage 편집 그래픽
AI가 만든 보고서가 늘면 비용은 사라지지 않고 검토자에게 이동한다.

한 줄로 정리하면: AI 보안 제보의 병목은 생성이 아니라 triage다

AI 도구는 취약점 후보를 빨리 찾아낼 수 있다. 그 자체가 문제는 아니다. 문제는 “그럴듯한 보고서”를 거의 공짜로 만들 수 있게 되면서, 실제 취약점인지 확인하는 비용이 접수자에게 이동했다는 점이다. Google의 규칙 페이지는 10월 1일 이후 OSS VRP에서 제품 취약점 제출을 더 이상 받지 않는다고 적고, 일부 Google Cloud 관련 저장소는 Cloud VRP로 갈 수 있으며, Q1 2027에 업데이트를 주겠다고 설명한다.Google 공식

TechCrunch는 Google이 X와 프로그램 웹사이트에서 “automated submissions”의 급증, 그리고 “vast majority”가 유효하지 않다는 이유를 들었다고 보도했다.TechCrunch 여기서 조심할 점은 두 가지다. 첫째, Google이 모든 오픈소스 보안 제보를 닫은 것은 아니다. 둘째, Q1 2027은 “재개일”이 아니라 업데이트 예정 시점이다. 이 차이를 놓치면 글은 자극적이지만 실무자에게 틀린 지도를 준다.

제품 취약점과 공급망 취약점은 같은 줄에 세우면 안 된다

Google 공식 규칙은 공급망 compromise를 먼저 따로 정의한다. 예를 들어 main branch에 코드를 바꿀 수 있거나, GitHub Actions·GCP build 환경·패키지 발행 자격 증명 문제로 사용자가 받는 아티팩트가 바뀌는 경우다.Google 공식 반면 제품 취약점은 정상적으로 배포된 Google OSS 안의 설계·구현 문제가 사용자 데이터의 기밀성이나 무결성에 영향을 주는 경우다. 여기서는 공식 문서가 직접 예시로 든 범위 이상을 확장하지 않고, 작은 팀의 운영 기준도 “실제 영향과 재현 증거가 있는가”로만 좁혀 본다.

정상 패키지 안의 결함과 배포 파이프라인에서 바뀐 아티팩트를 나란히 비교한 추상 다이어그램
제품 결함과 공급망 장악은 같은 보안 이슈처럼 보여도 접수 차선이 다르다.

이 구분은 작은 팀에도 그대로 유용하다. 누군가 “이 함수에 버그가 있다”고 말하는 것과 “릴리스 파이프라인을 바꿔 악성 패키지를 배포할 수 있다”고 말하는 것은 같은 보안 메일함에 들어오더라도 위험 모델이 다르다. 전자는 재현 환경과 영향 범위를 먼저 봐야 하고, 후자는 접근권한·빌드 아티팩트·서명·패키지 배포 경로를 즉시 분리해 봐야 한다.

그래서 접수 폼 첫 질문은 “취약점 설명”이 아니라 “공격자가 무엇을 바꿀 수 있나”가 되어야 한다. 실행 파일을 바꾸나, 사용자 데이터를 읽나, 빌드 설정을 바꾸나, 아니면 단순히 코드 냄새를 발견했나. 이 질문 하나로 AI가 만든 장문의 설명을 읽기 전에도 대부분의 큐가 갈린다.

좋은 보고서는 말투가 아니라 네 가지 증거로 판정한다

Google의 보고 안내는 고급 말투보다 구체적 증거를 요구한다. 최근 빌드 기준, 재현 절차, 가능하면 crash dump나 buildable proof of concept, 영향 설명과 공격 시나리오를 포함하라고 적는다.Google 공식 이 요구사항은 AI 제출 시대에 더 중요해졌다. 모델은 심각해 보이는 CVSS 문장과 공격 시나리오를 만들 수 있지만, 같은 버전에서 반복 재현되는 단계까지 대신 보장해 주지는 않는다.

관리자가 취약점 보고서를 저장소 버전, 재현 절차, 실행 증거, 실제 보안 영향 네 단계 필터로 확인하는 일러스트
좋은 보고서는 그럴듯한 설명이 아니라 재현 가능한 네 가지 증거로 읽힌다.

실무적으로는 다음 네 칸이 비어 있으면 접수하지 않는 편이 낫다.

필수 증거 왜 필요한가 없는 경우 처리
저장소·버전·커밋 같은 코드인지 확인해야 재현이 가능하다 “대상 불명”으로 반려
최소 재현 절차 사람이 같은 결과를 만들 수 있어야 한다 재현 보완 요청
실행 가능한 PoC 또는 패치 취약점 후보와 실제 영향 사이를 좁힌다 낮은 우선순위 또는 종료
공격자가 얻는 것 단순 버그와 보안 취약점을 나눈다 제품 버그/보안 이슈 분리

여기서 중요한 건 AI 사용 여부를 묻는 것보다 “검토자가 10분 안에 같은 현상을 만들 수 있는가”다. AI를 써도 네 칸을 채우면 읽을 가치가 있다. 반대로 사람이 썼어도 네 칸이 비어 있으면 큐를 망친다.

작은 팀의 접수 규칙: 보상 구조가 slop을 부른다

AI가 보고서를 많이 만든다고 해서 모두 나쁜 연구는 아니다. 문제는 보상 구조다. “일단 많이 보내고 유효한 것은 상대가 골라주겠지”가 이득이 되는 순간, triage 비용은 프로그램 운영자에게 전가된다. TechCrunch가 인용한 Google의 설명도 자동 제출물의 상당수가 유효하지 않다는 점에 초점을 둔다.TechCrunch

작은 보안 운영팀이 재현, 증거 첨부, 영향 기준, 빠른 종결 규칙을 대시보드로 관리하는 장면
AI 보조 제보 시대에는 더 많이 읽는 팀보다 빨리 분류하고 빨리 닫는 팀이 버틴다.

작은 팀이라면 다음처럼 정책을 공개하는 편이 낫다.

  1. AI 사용 자체는 허용하되, AI가 작성했다는 사실보다 재현 증거를 본다. 금지 선언은 집행하기 어렵고, 좋은 연구까지 밀어낼 수 있다.
  2. 증거 없는 장문 보고서는 자동 종료한다. “가능할 수 있다”, “보안상 위험해 보인다”만으로는 큐에 넣지 않는다.
  3. 공급망·권한·비밀 노출은 별도 긴급 차선으로 뺀다. 제품 버그와 같은 SLA로 보면 진짜 사고를 늦게 본다.
  4. 중복 보고서는 원인 단위로 묶는다. 모델이 같은 코드를 여러 표현으로 다시 쓴 보고서를 각각 검토하면 진다.
  5. 보상은 제출량이 아니라 검증 가능성에 준다. “읽을 만한 보고서”가 아니라 “재현 가능한 영향”에만 보상해야 한다.

이 다섯 가지는 보안팀이 없는 개인 프로젝트에도 적용된다. GitHub Security Advisory, 이메일, issue template 어디를 쓰든 첫 화면에 “버전, 단계, 증거, 영향” 네 칸을 먼저 요구하면 된다.

오늘 Google 사례에서 빼야 할 오해 세 가지

첫째, “AI 보안 연구는 쓸모없다”가 아니다. Google 규칙 페이지는 Cloud VRP, Patch Rewards Program 등 다른 경로를 계속 안내한다.Google 공식 AI가 찾은 후보라도 올바른 프로그램과 증거를 갖추면 여전히 의미가 있다.

둘째, “버그 바운티는 이제 끝났다”도 아니다. RepoSquare가 정리했듯 이번 변화의 핵심은 제품 취약점 차선을 멈추고, 공급망 차선과 기존 접수분을 남겨 둔 것이다.RepoSquare 실제로 Google 보상 표에는 공급망 compromise 범위가 남아 있다. 이 사실은 보안 제보의 미래가 “닫힘”이 아니라 “분류 강화”에 가깝다는 신호다.

셋째, “AI 탐지를 붙이면 해결된다”도 아니다. AI 작성 여부를 탐지하는 일은 어렵고, 틀리면 정당한 연구자를 쫓아낼 수 있다. 더 안전한 기준은 작성 도구가 아니라 검증 가능한 산출물이다. 커밋, 명령, 입력 파일, crash, 패치, 영향 설명처럼 사람과 기계가 함께 확인할 수 있는 증거가 남아야 한다.

평판 게이트, 샌드박스 재현, 중복 탐지, 사람 검토가 하나의 퍼널로 연결된 미래형 보안 접수 구조
문제는 AI 사용 자체가 아니라, 증거 없는 제출을 보상하는 큐 구조다.

월요일에 바로 고칠 수 있는 보안 제보 폼

복잡한 플랫폼을 만들 필요는 없다. 다음 다섯 질문을 issue template이나 보안 메일 자동응답에 넣어도 효과가 크다.

  • 영향을 받는 저장소, 버전, 커밋은 무엇인가?
  • 깨끗한 환경에서 재현하는 최소 명령은 무엇인가?
  • 성공했을 때 관측되는 증거는 무엇인가? 로그, crash, diff, 요청/응답 중 하나를 붙인다.
  • 공격자가 실제로 얻는 권한이나 데이터는 무엇인가?
  • 제품 취약점인가, 공급망·빌드·배포 경로 문제인가?

답이 비어 있으면 사람에게 넘기지 않는다. “추가 정보가 필요합니다”가 아니라 “이 형식으로 다시 보내 주세요”라고 닫는다. 친절한 토론으로 시작하면 큐가 토론장이 된다. 반대로 형식이 선명하면 좋은 연구자도 시간을 아낀다.

FAQ

Google OSS VRP가 완전히 중단된 건가?

아니다. 공식 페이지 기준으로 2026년 10월 1일부터 신규 제품 취약점 제출을 받지 않는 것이 핵심이다. 공급망 보고와 기존 접수분은 영향을 받지 않는다고 적혀 있다.Google 공식

Q1 2027이면 다시 열리는 건가?

그렇게 단정하면 안 된다. Google은 Q1 2027에 업데이트를 주겠다고 했지, 그 날짜에 재개한다고 말하지 않았다. 글이나 보고서에서는 “업데이트 예정”과 “재개 예정”을 구분해야 한다.

우리 팀도 AI로 쓴 보안 제보를 금지해야 하나?

대부분의 팀에는 금지보다 증거 기준이 낫다. AI 사용 여부를 완벽히 탐지하기 어렵고, 실제로 유효한 연구도 AI 도움을 받을 수 있기 때문이다. 버전, 재현 절차, 실행 증거, 영향 설명을 요구하는 방식이 더 집행 가능하다.

공급망 취약점은 왜 따로 봐야 하나?

공급망 취약점은 사용자가 받는 소스·빌드·패키지 자체가 바뀔 수 있는 문제다. 제품 코드의 버그보다 blast radius가 훨씬 클 수 있고, 대응도 권한·CI/CD·서명·배포 경로를 중심으로 해야 한다. 같은 보안 메일함에 들어오더라도 triage 차선은 분리해야 한다.

← 글 목록