AI는 버그바운티를 어떻게 바꾸고 있을까? (from DEF CON 34)
AI는 버그바운티를 어떻게 바꾸고 있을까?
DEF CON 「Navigating AI-Assisted Submissions」 패널 후기
You can read it in English too:
Seokchan Yoon
안녕하세요. 윤석찬입니다.
이번 DEF CON 34의 Bug Bounty Village에서 「Navigating AI-Assisted Submissions」라는 토크 세션을 듣고 왔습니다. AI 도입 이후 각 플랫폼의 triage 팀이 겪는 문제를 직접 들어보고 싶어 찾아간 세션이었습니다.
패널에는 버그바운티 업계에서 경쟁하고 있는 다섯 플랫폼의 담당자가 참석했습니다.
- HackerOne — Tony Lee
- Synack — Eddie Rios
- Bugcrowd — Michael Skelton
- Intigriti — Alexander Wren
- YesWeHack — Selim Jaafar
제가 패널을 들으며 가장 먼저 느낀 것은, 다섯 회사 모두 AI를 문제의 원인으로 단정하지 않았다는 점입니다. AI 덕분에 예전보다 더 심각한 취약점이 빠르게 발견되고 있다는 사실은 오히려 긍정적으로 보고 있었습니다. 문제는 그다음이었습니다. 발견된 취약점을 검증하고 수정하는 과정은 여전히 사람의 속도로 움직이는데, AI가 발견 속도만 크게 높여버렸습니다. 이후 논의도 이 간극 때문에 생긴 번아웃과 리포트 품질, 보상 문제를 중심으로 이어졌습니다.
패널에서 현재 상황을 가장 잘 설명한 문장은 아래와 같았습니다.
AI is not a problem. It's just a new reality for us as an industry.
AI는 잠시 유행하다 사라질 문제가 아니라, 앞으로 버그바운티 업계가 계속 적응해야 하는 새로운 환경이라는 의미였습니다.
1/ AI slop으로 늘어난 제출량과 triage 팀의 번아웃
사회자는 먼저 지난 1년 동안 triage 현장이 어떻게 달라졌는지 물었습니다. 가장 먼저 나온 답은 제출량도 AI slop도 아닌 번아웃이었다고 합니다. triage 팀은 계속 쌓이는 리포트를 따라가는 것만으로도 육체적·정신적으로 지친 상태라고 했습니다.
패널이 공개한 내부 수치는 다음과 같습니다.
- 전체 제출량은 전년 대비 약 2배 증가했습니다.
- 전체 리포트에서 유효한 리포트가 차지하는 비율은 크게 달라지지 않았습니다.
- 실제로 확인된 Critical 취약점은 최근 몇 달 동안 전년 대비 약 3배 증가했습니다.
여기서 중요한 점은 유효 리포트의 비율이 아니라 개수입니다. 유효한 리포트와 무효한 리포트의 비율이 같더라도 전체 제출량이 2배가 되면, triage 팀이 확인해야 할 리포트도 그대로 2배가 됩니다. AI가 저품질 리포트만 늘린 것이 아니라 실제 취약점까지 함께 늘렸기 때문에 업무량이 줄어들 수가 없습니다.
공개 자료에서도 비슷한 흐름을 확인할 수 있습니다. HackerOne은 2026년 5월 공개한 자료에서 12개월 동안 제출량이 76% 증가했고, 2026년 3월에 정점을 찍었다고 밝혔습니다. 제출량이 급증한 동안에도 유효 리포트의 비율은 비교적 일정하게 유지됐다고 설명했습니다. Elastic 역시 예년에 연간 600~850건 정도였던 제출이 2026년 상반기에만 1,390건을 넘었다고 밝혔습니다. Bugcrowd도 triage 큐가 불과 3주 만에 334% 증가했다고 언급했습니다.
대형 플랫폼의 평균만 보면 유효 리포트의 비율이 유지되고 있지만, 작은 오픈소스 프로젝트는 상황이 달랐습니다. curl의 경우에는 2025년 초까지 약 6건 중 1건이던 유효 리포트가 연말에는 20~30건 중 1건으로 줄었고, 이로 인해 2026년 1월 31일을 끝으로 버그바운티 프로그램을 중단했다고 언급했습니다. 같은 제출량 증가라도 전담 인력이 있는 대형 플랫폼과 소규모 오픈소스 프로젝트가 받는 부담은 크게 달랐습니다.
패널들은 이 문제의 책임이 연구자에게만 있는 것은 아니라고 했습니다. 연구자는 제출 전에 취약점을 검증하고, 플랫폼은 유효한 리포트가 고객에게 제대로 전달되도록 도와야 합니다. 프로그램도 원하는 취약점과 받지 않을 취약점을 구체적으로 알려야 합니다. AI 이후의 환경에 맞춰 연구자와 플랫폼, 프로그램이 함께 바뀌어야 한다는 의견이었습니다.
2/ AI slop의 또 다른 형태, 불필요하게 긴 리포트
다음 주제는 AI slop의 기준이었습니다. 사회자는 몇 년 전이라면 가치 있게 받아들였을 Low나 Medium 취약점이 지금도 같은 가치가 있는지 물었습니다. AI가 비슷한 취약점을 대량으로 찾아내기 시작하면서 일부 프로그램은 Low와 Medium 리포트를 아예 받지 않고 있습니다.
한 패널은 slop이라는 표현 자체가 적절하지 않다고 보았습니다. slop은 쓰레기라는 뜻이지만, 현재 들어오는 리포트가 모두 틀린 것은 아니기 때문입니다. 취약점은 유효한데 LLM이 불필요한 설명을 길게 덧붙여 핵심을 찾기 어려운 경우도 많습니다. 이런 결과물은 쓰레기라기보다 불필요하게 부풀려진 리포트에 가깝다는 설명이었습니다.
다른 패널은 slop의 기준이 프로그램마다 다르다고 덧붙였습니다. 어떤 프로그램은 Medium 취약점도 모두 확인하고 싶어 하지만, 다른 프로그램은 같은 유형을 일괄적으로 닫습니다. 따라서 플랫폼이 하나의 기준을 정하기보다 각 프로그램이 원하는 취약점과 비즈니스 우선순위를 명확하게 알려야 합니다. Scope와 Out of Scope만 적는 데서 끝내지 않고, 원하는 버그 클래스와 현재 집중하고 있는 영역을 연구자에게 공유해야 불필요한 제출을 줄일 수 있다는 의견이었습니다.
Low와 Medium을 계속 보상할 것인지에 대해서는 결국 예산 문제라는 답이 나왔습니다. 버그바운티도 다른 보안 솔루션과 비용 대비 효과를 놓고 경쟁합니다. AI로 쉽게 찾을 수 있는 취약점은 발견 비용이 낮아진 만큼 보상 규모도 줄어들 수밖에 없다는 설명이었습니다.
실제로 Google은 2026년 OSS VRP 하위 티어의 금전 보상과 크레딧을 없애고, AI가 찾기 어려운 취약점 유형을 우선하는 방향으로 정책을 변경했습니다. 나중에 한 패널이 AI를 공장에서 대량 생산한 빵에 비유했는데, Google의 정책도 이와 같은 변화를 보여줍니다.
AI slop의 세 가지 유형
패널의 설명을 종합하면 현재 플랫폼에 들어오는 AI slop은 크게 세 종류입니다.
첫 번째는 환각 리포트입니다. 실제로는 존재하지 않는 취약점이지만 설명만 읽으면 Critical처럼 보입니다. 이 경우 연구자가 취약점이 작동한다는 증거를 제시하는 대신, triage 팀이 취약점이 아니라는 사실을 직접 확인해야 합니다. 잘못된 판단 한 번이 큰 문제로 이어질 수 있는 프로그램일수록 검증에 더 많은 시간이 필요합니다.
두 번째는 지나치게 긴 리포트입니다. 취약점 자체는 유효하지만 설명이 너무 길어 실제 영향과 재현 방법을 찾기 어렵습니다. 개발자와 보안팀, 제품 담당자를 모두 만족시키려는 것처럼 작성된 수십 문단 사이에 정작 중요한 내용이 묻혀 있습니다.
세 번째는 자동 제출 리포트입니다. 해킹 경험이 거의 없는 사람이 “에이전트를 돌리면 돈을 벌 수 있다”는 말을 듣고 자동화 도구를 실제 프로그램에 바로 연결하는 경우입니다. 패널은 한 사람이 50~60개의 계정을 만들고, 그중 한 계정에서는 robots.txt만 제출한 사례도 있었다고 설명했습니다.
Bugcrowd는 연속해서 무효 리포트를 제출하거나 submission farming을 하는 계정에 제재를 가하는 정책을 발표했습니다. HackerOne도 2026년 8월 14일부터 버그바운티 프로그램 전반에 신원 확인을 의무화하겠다고 발표했습니다. AI slop 문제가 커뮤니티의 논쟁을 넘어 실제 플랫폼 정책까지 바꾸고 있습니다.
3/ AI가 지워버린 리포트의 개성
개인적으로 가장 인상 깊었던 내용 중 하나는 AI가 리포트의 문체를 바꾸고 있다는 이야기였습니다.
한 패널은 1년 전과 지금의 리포트를 비교했습니다. 예전에는 연구자가 “이 취약점으로 어떤 공격을 할 수 있는가”를 중심으로 리포트를 작성했습니다. 지금은 많은 연구자가 결과를 Claude나 ChatGPT에 넣어 리포트를 만듭니다. 그 결과 작성자는 서로 다른데 문장과 구성이 모두 비슷해졌고, 정작 프로그램 오너가 궁금해하는 실제 공격 시나리오는 빠지는 경우가 많아졌습니다.
과거에는 리포트마다 연구자의 개성과 사고 과정이 어느 정도 드러났습니다. 지금은 여러 연구자의 리포트를 읽어도 모두 같은 AI가 쓴 글처럼 느껴진다고 했습니다. 결국 triage 팀이 상대하는 연구자가 전부 같은 AI처럼 보여서는 안 된다는 의미였습니다.
장문 리포트가 반드시 좋은 리포트는 아니지만, 예전에는 긴 글을 쓰려면 그만큼 사람의 시간과 노력이 필요했습니다. 지금은 LLM에 자세히 써달라고 요청하면 수십 문단이 바로 만들어집니다. AI를 쓰지 말라는 뜻은 아니었습니다. 대신 리포트에 들어갈 내용은 연구자가 직접 통제해야 한다고 조언했습니다.
패널들이 공통으로 제시한 기준은 아래와 같습니다.
- 리포트 첫 부분에 실제 영향도를 적습니다.
- 재현에 필요한 단계와 증거만 남깁니다.
- 취약점의 일반적인 정의처럼 triage 팀이 이미 아는 설명은 줄입니다.
- AI가 입력한 심각도를 연구자가 다시 확인합니다.
- 제출하기 전에 리포트를 처음부터 끝까지 직접 읽습니다.
AI에게 심각도까지 맡기면서 생긴 문제도 있었습니다. RCE를 찾아 셸까지 얻은 연구자가 왜 우선순위가 낮냐고 항의했는데, 정작 리포트 생성 도구가 심각도를 Informational로 선택해 둔 사례였습니다. 반대로 실제 영향이 크지 않은 취약점을 Critical로 분류하는 경우도 늘었습니다. High나 Critical 리포트는 빠른 검토 대상이 되지만, 검증 과정에서 등급이 내려가면 다시 일반 큐로 돌아갑니다. 심각도를 과장해도 연구자에게 돌아오는 이점은 거의 없습니다.
플랫폼이 표준 리포트 양식이나 AI에 입력할 수 있는 작성 지침을 배포하자는 제안도 나왔습니다. 한 패널은 취약점 유형별로 필요한 최소 증거를 알려주는 도구를 이미 개발하고 있으며, GitHub에 공개해 업계 표준으로 발전시키고 싶다고 답했습니다. 플랫폼마다 별도의 리포트 생성 AI를 만드는 것보다 최소한의 품질 기준부터 함께 정하자는 방향이었습니다.
AI가 가져온 장점도 분명했습니다. 영어가 모국어가 아닌 연구자도 번역과 문장 교정을 AI에게 맡길 수 있게 되면서 언어 장벽이 크게 낮아졌습니다. 심각한 취약점을 찾고도 영어 리포트를 작성하느라 들이던 시간도 줄었습니다. 패널들이 문제로 본 것은 AI 사용 자체가 아니라 연구자의 판단까지 AI에게 맡기는 경우였습니다.
4/ 연구자와 플랫폼의 역할 분담
사회자는 한 프로그램을 오랫동안 연구해 온 이른바 '앵커 해커'의 입장에서 질문을 던졌습니다. 이런 연구자도 취약점을 찾을 때마다 고객의 환경을 처음 보는 사람에게 설명하듯 전체 맥락을 다시 적어야 합니다. 고객을 더 잘 아는 플랫폼이 이 부담을 덜어줄 수 있지 않겠느냐는 질문이었습니다.
플랫폼들의 답변은 명확했습니다. 연구자는 대상을 분석하고 취약점을 찾은 뒤, 이를 재현해 실제 문제임을 입증하면 된다는 의견이었습니다. 필요한 경우에는 안전한 범위 안에서 공격 가능성까지 보여줄 수 있습니다. 그 결과를 고객이 이해할 수 있는 언어로 정리하고, 연구자와 프로그램 담당자가 같은 맥락에서 대화하도록 돕는 일은 플랫폼의 역할이라고 했습니다.
물론 AI가 만든 초안을 검토하지 않고 제출해도 된다는 의미는 아니었습니다. 한 패널은 리포트를 읽다가 집중력이 흐려지거나 끝까지 읽기 싫어지면 좋은 리포트가 아니라고 했습니다. 작성자인 연구자도 끝까지 읽지 않은 글을 triage 팀에 보낼 수는 없다는 단순한 기준이었습니다.
AI slop은 최초 제출 이후에도 이어졌습니다. 고객이 심각도를 낮춘 뒤 연구자가 AI로 IDOR에 대한 수백 문단의 이의 제기를 만들어 보내는 경우도 있었습니다. 패널은 AI와 논쟁하고 싶은 것이 아니라 연구자와 직접 대화해 서로 납득할 수 있는 결론을 찾고 싶다고 했습니다.
이때 옆의 패널이 “플랫폼 AI와 연구자 AI가 서로 싸우게 두면 되지 않느냐”고 농담했습니다. 이어서 비슷한 모델이 작성과 검토를 모두 맡으면 “내 친구가 썼으니 괜찮다”고 평가하는 것과 다르지 않을 수 있다는 반론이 나왔습니다. 농담처럼 시작했지만 AI가 생성한 결과를 다시 AI만으로 평가할 때 생길 수 있는 편향을 잘 보여준 대화였습니다.
패널이 연구자에게 요구한 것은 거창한 글쓰기 능력이 아니었습니다. 하룻밤에 100건을 제출했다면 사람이 각 리포트를 제대로 확인하기는 어렵습니다. 이럴 때는 제출 속도를 늦추고, 고객이나 triage 담당자의 입장에서 리포트를 다시 읽어야 한다고 했습니다. AI에게 취약점을 찾아달라고 요청하는 데서 그치지 않고, 별도의 에이전트에 반증을 맡겨 스스로 찾은 취약점을 다시 검증하는 방법도 제안했습니다. (저 같은 경우 LLM 기반 취약점 발굴 파이프라인에서 검증을 위한 에이전트를 두고, 이 에이전트를 통과하지 못하는 버그라면 Security issue라고 판단하지 않습니다)
리포트를 쓸 때는 영향도를 첫 부분에 두고, 실제 영향이나 재현에 도움이 되지 않는 문장은 지우라고 했습니다. AI로 Low와 Medium을 대량 제출하기보다 프로그램을 깊게 분석해 High와 Critical을 찾는 편이 낫다는 조언도 나왔습니다. AI가 자신의 문체를 따르게 하려면 기존에 직접 작성한 리포트를 예시로 제공할 수 있습니다. 최종적으로는 리포트를 읽을 사람이 보안팀인지, 개발자인지, 비기술 직군인지에 따라 설명의 범위를 정해야 합니다.
패널들은 이런 조언에도 유효기간이 있다고 덧붙였습니다. 3개월 전에 같은 질문을 받았다면 다른 답을 했을 것이고, 지금은 3일마다 상황이 바뀌는 것처럼 느껴진다고 했습니다. 플랫폼도 완성된 해답을 가지고 있는 것이 아니라 커뮤니티와 함께 방법을 찾는 중이라고 합니다.
5/ AI로 새롭게 열린 버그 클래스
전반부가 AI slop과 triage의 어려움을 다뤘다면, 후반부의 분위기는 조금 달랐습니다. 패널들은 AI를 이용해 새로 할 수 있게 된 일에 관해 이야기했습니다.
첫 번째는 사람이 일일이 처리할 수 없었던 영역의 취약점 연구입니다. 과거에는 새 프로그램의 모든 엔드포인트에서 인가 취약점을 하나씩 확인하려면 오랜 시간이 필요했습니다. 그래서 인가 취약점이 1년에 걸쳐 조금씩 보고되었다면, 이제는 프로그램이 열린 첫 주에 수백 건이 발견될 수 있다고 했습니다. 같은 범위를 분석하는 데 걸리는 시간이 1년에서 1주로 줄어든 셈입니다.
두 번째는 방대한 제품 문서와 실제 구현의 차이입니다. Atlassian처럼 문서가 많은 서비스는 여러 기업이 그 내용을 믿고 시스템을 구축합니다. 하지만 문서에 적힌 내용이 실제 동작과 모두 일치하는지 사람이 전부 확인하기는 어렵습니다. 이제 에이전트가 문서와 구현을 대규모로 비교할 수 있게 되면서, 그 차이 자체가 새로운 취약점으로 이어질 수 있다는 의견이었습니다.
AI로 코드를 작성하는 사람이 늘어난 점도 연구자에게는 새로운 기회입니다. 최근 서비스에는 비결정적인 출력을 내는 LLM이 작성한 코드, 급하게 연결한 외부 서비스가 자주 관찰됩니다. 개발자에게는 불안 요소이지만, AppSec과 버그바운티 연구자에게는 새로운 공격 표면이 계속 생긴다는 의미입니다. 앞으로는 찾는 취약점의 종류와 찾는 방법이 모두 달라질 것이라는 전망이었습니다.
공장에서 만든 빵과 장인이 직접 구운 빵
한 패널은 AI를 빵을 대량 생산하는 공장에, 연구자를 빵을 직접 굽는 장인에 비유했습니다.
공장에서 만든 빵은 많은 사람에게 저렴하게 공급할 수 있습니다. AI도 이와 비슷하게 쉽게 찾을 수 있는 취약점을 빠르게 대량으로 찾아낼 것입니다. 그렇다고 장인이 직접 굽는 빵의 가치까지 사라지는 것은 아닙니다. 공장에서 만들기 어려운 빵을 찾는 사람은 여전히 남아 있습니다.
AI가 100만 개의 빵을 굽도록 두고, AI가 찾지 못한 단 하나를 찾아야 합니다. 바로 그 하나가 걸작입니다.
해커의 관점에서 보면 AI가 어디를 확인해야 할지 몰라 놓친 접근 제어 취약점이 장인이 직접 구운 빵에 해당합니다. 서로 떨어진 단서를 연결해야만 보이는 취약점이나, 프로그램을 오랫동안 이해한 사람만 발견할 수 있는 비즈니스 로직 취약점도 마찬가지입니다.
이어서 이 비유와 잘 맞는 사례도 소개되었습니다. 한 프랑스 해커 그룹은 같은 프로그램을 4~5년 동안 연구해 왔습니다. 이 팀은 여기에 AI를 도입한 뒤 2주 만에 Critical 취약점 5개를 찾았습니다. 이 취약점들은 지난 5년 동안 해당 팀과 다른 연구자들이 계속 놓쳤던 것들이었습니다.
이 사례는 AI가 연구자의 전문성을 대신했다기보다, 쌓아 온 전문성을 더 잘 활용하게 해준 경우에 가깝습니다. 프로그램을 5년 동안 분석하며 얻은 지식과 AI의 탐색 능력이 합쳐지면서 이전에 놓쳤던 취약점을 찾을 수 있었습니다. 같은 도구를 사용하더라도 프로그램에 대한 이해가 없다면 같은 결과를 내기 어려웠을 것입니다.
패널들은 올해 들어 한 사람이 짧은 시간 안에 훨씬 깊은 연구를 할 수 있게 되었다고 했습니다. 예전에는 몇 주에 한 번 볼까 말까 했던 수준의 취약점이 더 자주 들어오고, 복잡한 취약점이 발견되는 속도도 빨라졌습니다. 연구자에게는 반가운 변화이지만, 이를 검증하고 수정해야 하는 방어팀에는 큰 부담입니다.
하드웨어처럼 AI가 아직 직접 다루기 어려운 영역도 언급되었습니다. AI는 장비를 분해하거나 납땜할 수 없기 때문에 웹에서 모바일, 펌웨어, 하드웨어로 연구 범위를 넓히면 아직 연구자가 많지 않은 분야를 찾을 수 있다는 조언이었습니다. AI가 반복 작업을 대신해 준 만큼 새로운 분야를 공부할 시간을 확보할 수 있다는 의미로 들렸습니다.
6/ Q&A에서 나온 세 가지 현실적인 질문
경쟁 플랫폼 사이의 협력
첫 질문은 HackerOne, Bugcrowd, Intigriti처럼 경쟁 관계인 플랫폼들이 AI slop 문제를 놓고 실제로 협력하는지에 관한 내용이었습니다.
패널들은 회사 전체로 보면 당연히 경쟁하지만, 운영팀과 커뮤니티팀은 서로 꽤 많은 정보를 공유한다고 답했습니다. ('경쟁은 영업팀이 하게 두면 됩니다'라는 농담도 나왔네요 ㅋㅋ) 같은 행사에서 만나 문제 사례와 대응 방식을 공유하고, 한 플랫폼이 좋은 방법을 찾으면 다른 플랫폼도 이를 참고한다고 했습니다.
운영팀과 커뮤니티팀은 영업 조직과 달리 매출 목표에서 비교적 자유롭고, 커뮤니티의 문제를 해결한다는 목표도 같습니다. 서로 경쟁하는 다섯 회사가 한 무대에서 비슷한 문제를 솔직하게 이야기할 수 있었던 이유였던 것 같습니다.
AI 의존과 연구자의 실력
두 번째 질문은 AI를 계속 사용하면 연구자의 실력이 떨어지지 않겠느냐는 우려였습니다.
패널들은 AI 시대에 인간이 맡아야 할 역할이 오히려 더 명확해졌다고 답했습니다. AI는 공격을 수행할 수 있지만 어디까지가 합리적이고 허용된 범위인지 판단하지 못합니다. 실제로 올해 사람이라면 건드리지 않았을 대상을 에이전트가 침해한 사례가 있었고, 도구를 실행한 연구자는 AI가 어떤 행동까지 했는지 모르고 있었다고 했습니다.
플랫폼이 당사자에게 연락해 보면 대부분 고의로 행동 강령을 어긴 것은 아니었다고 합니다. 자신의 도구가 만든 요청과 노이즈의 범위를 알지 못했고, 문제를 설명하면 사과한 뒤 워크플로를 수정했습니다. 새로운 AI 모델이든 기존의 취약점 스캐너든 최종적으로 도구를 통제해야 하는 사람은 사용자입니다.
한 패널은 2026년 3월을 AI의 해킹 능력이 눈에 띄게 향상되고 제출량도 치솟은 변곡점으로 보았습니다. HackerOne도 공개 자료에서 제출량이 같은 달 정점을 찍었다고 밝혔습니다. Bugcrowd는 3월 10일 slop 대응 정책을 발표했고, HackerOne은 3월 27일 Internet Bug Bounty의 신규 접수를 중단했습니다.
다만 이런 변화가 처음은 아니라는 의견도 있었습니다. 취약점 스캐너가 처음 보급됐을 때도 사용자가 모든 탐지 결과를 취약점이라고 제출하는 문제가 있었습니다. Hack The Box와 TryHackMe 같은 학습 플랫폼이 등장했을 때는 보안 입문이 쉬워진 만큼 경쟁도 치열해졌습니다. AI 역시 연구자에게 필요한 기술을 바꾸고 있으며, 계속 배우는 사람은 새로운 환경에도 적응할 수 있다는 답변이었습니다.
triage 이후의 일방적인 심각도 하향
마지막 질문은 AI가 아니라 보상에 관한 내용이었습니다. 7년 차 연구자 한 명은 Critical로 제출한 취약점에 triage 팀도 같은 등급을 매겼지만, 고객이 B2나 B3로 낮춘 뒤 대화가 끊기는 일이 예전보다 많아졌다고 지적했습니다. 지원팀에 문의해도 고객의 최종 결정이라는 답만 돌아오고, 이미 판단을 마친 triage 팀과 다시 이야기하기도 어렵다는 설명이었습니다.
플랫폼 측은 뚜렷한 해결책이 없다는 점부터 인정했습니다. 제출량이 급증하면서 triage뿐 아니라 지원팀과 프로그램 담당자도 함께 바빠졌고, 이 과정에서 연구자와의 소통이 줄어들었습니다.
같은 취약점은 누가 검토하더라도 같은 결과가 나와야 하지만, 실제로는 고객의 상황과 판단에 따라 결과가 달라질 수 있다고 했습니다. 고객이 제출물을 어떻게 받아들이는지에 따라 평가가 바뀔 수도 있고, 반대로 연구자가 모르는 내부 완화 조치 때문에 실제 위험이 낮게 평가될 수도 있습니다.
다른 패널은 기업들이 이제야 제출량 증가가 일시적인 현상이 아니라는 점을 깨닫고 있다고 설명했습니다. 기존에 두 명이 처리하던 프로그램이라면 이제 세 명이 필요하다는 식으로 인력과 처리 시스템을 다시 배분하는 단계입니다. 습관적으로 등급을 낮추는 고객도 있지만, 제대로 운영되는 프로그램이라면 위험도에 맞게 보상할 이유가 분명하다는 답변으로 Q&A가 마무리되었습니다.
공개 자료를 보면 이 문제는 단순한 불만으로 넘기기 어렵습니다. HackerOne은 검증을 마쳤지만 아직 해결되지 않은 취약점이 21배, 미해결 Critical 취약점은 25배로 늘었다고 밝혔습니다. Critical 취약점의 해결률은 83% 이상에서 40% 미만으로 떨어졌습니다. 취약점을 발견하는 속도에 비해 수정하는 속도가 크게 뒤처진 상태입니다.
7/ 발견보다 검증과 수정이 어려워진 시대
이번 패널을 보고 나서 AI가 버그바운티에 만든 가장 큰 변화는 취약점 발견 이후의 병목이 드러난 것이라는 생각이 들었습니다.
예전에는 심각한 취약점을 찾는 일이 가장 어려웠습니다. 지금은 AI를 이용해 더 많은 사람이 복잡한 취약점을 빠르게 찾을 수 있습니다. 하지만 취약점을 재현하고, 실제 영향도를 판단하고, 고객에게 전달하고, 수정하고, 적절히 보상하는 과정은 여전히 사람과 조직의 속도로 움직입니다. 제출량은 2배로 늘었지만 백로그가 21배로 늘어난 이유도 여기에 있습니다.
AI가 저품질 리포트만 늘린 것도 아닙니다. 실제로 확인된 Critical 취약점도 함께 늘었고, 5년 동안 아무도 찾지 못했던 취약점이 2주 만에 발견되기도 했습니다. 영어 리포트 작성에 필요한 시간도 줄었고, 사람이 규모 때문에 시도하지 못했던 연구도 가능해졌습니다.
결국 중요한 것은 AI를 사용했는지가 아니라 어디까지 맡겼는지입니다. 반복적인 탐색과 번역, 초안 작성은 AI에게 맡길 수 있습니다. 하지만 공격 범위를 정하고, 취약점을 재현하고, 심각도와 실제 영향도를 판단하고, 최종 리포트를 읽는 일은 연구자가 직접 해야 합니다.
패널의 마지막 조언을 제 방식대로 옮기면 아래 한 문장으로 정리할 수 있습니다.
내가 직접 하지 않을 일이라면, 나의 AI에게도 시키지 말아야 합니다.
저 역시 LLM으로 취약점을 찾고 있는 입장에서, 더 많은 결과를 만드는 것보다 그 결과를 어디까지 신뢰하고 어떻게 검증할 것인지 계속 고민해 봐야겠습니다.
참고 자료
- HackerOne, Finding Fast, Fixing Slow: The Rising Exposure Debt
- HackerOne, HackerOne Introduces H1 Validation to Help Enterprises Manage Surge in AI-Discovered Vulnerabilities
- Bugcrowd, Bugcrowd policy changes to address “AI slop” submissions
- Bugcrowd, Inside the Mind of a Hacker 2026
- Elastic Security Labs, AI vulnerability triage: Bug bounty reports at $2 each
- Google Bug Hunters, OSS VRP Rule Updates 2026
- BleepingComputer, Curl ending bug bounty program after flood of AI slop reports
- HackerOne Mandates ID Verification
- CSO Online, Internet Bug Bounty program hits pause on payouts
