AI 취약점 보고서, 진짜와 가짜 가르는 검증 절차 7가지 [2026]

앤트로픽은 2026년 10월 8일 사람 검토를 거치지 않은 모델 생성 취약점 보고서를, 신청해 선정된 핵심 오픈소스 프로젝트에 무료로 보내는 'OSS Scanner'를 열었다. 일주일 앞선 10월 1일 구글은 "대부분 유효하지 않은 자동화 제출이 크게 늘었다"며 자사 오픈소스 버그바운티(OSS VRP)의 제품 취약점 접수를 일시 중단했다.

AI가 찾았다는 취약점 보고는 진짜도 늘었고 가짜도 늘었다. 앤트로픽이 공개한 자체 대시보드(2026년 10월 2일 기준)를 보면 외부 보안업체 6곳이 재현·검토한 후보 6,123건 가운데 5,674건(92.7%)이 실제 버그로 판정됐다. 이미 보고된 중복과 '고치지 않음' 판정까지 넣은 수치이고, 앤트로픽도 이를 영향을 가늠하는 대리 지표 하나로만 보라고 적었다. 반면 curl은 2025년 들어 접수 보고 중 실제 취약점 비율이 5% 아래로 떨어지자 2026년 1월 31일 버그바운티를 끝냈다. 가짜 보고는 지어낸 엔드포인트와 근거 없는 영향, 재현되지 않는 공격을 그럴듯하게 적는다.

외부 제보, 버그바운티, 사내 AI 스캐너 어디서 오든 'AI가 찾았다'는 보고를 받은 개발팀이 할 일은 같다. 재현되는지, 보고서가 말한 코드가 우리 코드에 실제로 있는지, 외부 입력이 그 경로에 닿는지부터 확인한다. 아래에 진짜와 가짜를 가려 고치는 검증 절차 7가지와, 우리가 AI로 취약점을 분석할 때 지킬 것을 정리했다.

AI 취약점 보고서, 무엇이 달라졌나

앤트로픽은 2026년 4월 7일 일반에 출시하지 않은 모델 미토스 프리뷰를 공개하며 주요 기업·재단과 '프로젝트 글래스윙'을 시작했다(기업 대응은 미토스 쇼크 정리 참고). 10월 6일에는 글래스윙을 사이버 검증 프로그램(CVP)에 합쳐, 심사를 통과한 보안팀이 차단이 덜한 최신 모델을 쓰게 했다. 일부 참여사 설문을 바탕으로 한 앤트로픽 집계에 따르면 글래스윙 참여사들은 2026년 4~7월 적어도 12만9천 건의 검증된 취약점을 찾았고, 앤트로픽 자체 오픈소스 점검(4~10월)의 5,500건을 더한 가운데 3만3천 건 이상이 지금까지 치명 또는 높음 등급을 받았다. 회사는 33개 참여사 보고의 부분 자료라 실제보다 적게 잡혔을 것으로 보면서도, 기관마다 분류 방식이 달랐고 패치 수를 밝힌 참여사는 절반이 안 된다고 적었다.

10월 8일 '사이버 미션' 발표문에서 앤트로픽은 "취약점을 찾기는 어느 때보다 쉬워졌지만, 찾은 것을 검증하고 우선순위를 정하고 고치는 일은 여전히 어렵다"고 썼다. 글래스윙에서도 취약점을 찾은 뒤 고치기까지 몇 달이 걸리는 일이 잦았다고 했다. 같은 날 연 OSS Scanner는 사람 검토 없는 모델 보고서를 받겠다고 신청한 프로젝트에만 보내는 서비스로, 회사는 잘못된 심각도 같은 부정확한 내용이 섞일 수 있다고 밝히고 참 양성률(보고 중 실제 취약점 비율) 90% 이상을 예상했다.

개발팀에게 달라진 것은 보고서가 들어오는 속도다. 보고서를 만드는 비용은 크게 내려갔지만 진짜인지 확인하는 비용은 여전히 받는 쪽이 낸다. curl 보안팀은 7명인데, 보고 한 건마다 3~4명이 각자 30분에서 길게는 세 시간씩 붙는다고 2025년 7월 밝혔다.

진짜도 늘었다: AI가 찾은 취약점 보고 사례

대시보드 수치는 2025년 11월 1일부터 2026년 10월 2일까지 발견한 건을 센 것이라, CVP 발표의 '4~10월 검증 5,500건'과 기간과 집계 방식이 다르다. 대시보드의 유지보수자 보고 6,157건 가운데 4,824건은 외부 검토 없이 앤트로픽이 직접 보낸 것으로 '오탐이 섞일 수 있음'이라고 표시돼 있다. 앤트로픽은 유지보수자가 검증 전 결과까지 모두 달라고 해서 보낸 보고가 5천 건 가까이 된다고 밝혔다. 패치 수는 뒤늦게 따라오는 지표이고, 업스트림에 패치가 나왔다고 널리 설치됐다는 뜻은 아니라는 설명도 붙였다.

curl의 Daniel Stenberg는 2025년 8월 11일 구글 Big Sleep 팀이 보낸 보고를 AI로 curl 보안 문제를 정확히 찾아 보고한 것으로 보이는 첫 사례로 꼽았다. 이 결함은 일반 릴리스 기준 curl 8.13.0~8.15.0의 쿠키 경로 범위 밖 읽기(CVE-2025-9086)로, 2025년 9월 10일 8.16.0에서 고쳐졌다(지원 계약 고객용 배포판 Rock-solid curl은 8.14.x 계열 8.14.2부터 영향 없음). 9월에는 Joshua Rogers가 잠재 문제 목록을 넘겼는데, Stenberg는 이 목록이 주로 AI 기반 코드 분석 도구로 뽑은 것이라고 이해한다고 적었다. 컴파일러 경고, 여러 정적 분석기, OSS-Fuzz를 늘 돌려 온 curl에서 200개가 넘는 새 후보가 나왔고, 첫 목록에서만 버그 수정 약 50건이 반영됐다. 앤트로픽이 발표문에 실은 Stenberg의 평가는 OSS Scanner로 고칠 만한 curl 문제를 여럿 찾았고, 그중 하나는 최근 몇 년 사이 보고된 curl 취약점 가운데 가장 심각한 축에 든다는 것이다. 구글은 2025년 7월 Big Sleep이 위협 인텔리전스를 바탕으로 SQLite 취약점(CVE-2025-6965)을 찾아 실제 악용 시도를 미리 막았다고 밝혔다. AI 코드 분석으로 찾은 리눅스 커널 취약점은 CopyFail 정리에 있다.

가짜도 늘었다: 저품질 보고에 멈춘 버그바운티

AI 버그바운티 제보의 부작용을 숫자로 보여 준 곳은 curl이다. curl은 2025년 7월 기준 그해 보안 보고의 약 20%가 AI 슬롭(AI로 대충 만든 저품질 보고)이었고 실제 취약점은 약 5%였다고 밝혔다. 2026년 1월 26일에는 예년 15%를 넘던 확인 비율이 2025년 5% 아래로 떨어졌다며, 2019년부터 확인 취약점 87건에 10만 달러 넘게 지급한 버그바운티를 1월 31일로 끝냈다. 이유로는 AI 슬롭, 예전보다 나빠진 사람 보고, 돕기보다 흠집 내기에 치우친 태도를 함께 들었다. 3월 1일부터 보고 창구는 다시 HackerOne으로 돌렸지만 보상금은 없다.

구글은 10월 1일 X 게시물에서 OSS VRP 제품 취약점 접수를 일시 중단한 이유로 대부분 유효하지 않은 자동화 제출이 크게 늘어난 것을 들었다. 공급망 보고와 이미 접수된 보고는 그대로 처리하고, 2027년 1분기에 개편 내용을 알리겠다고 했다. 이 제출이 AI 도구로 만든 것인지는 밝히지 않았다.

Go 보안팀은 2026년 9월 보안 정책에 LLM 생성 보고 조항을 넣었다. 최신 LLM은 실제 중요한 보안 버그를 아주 잘 찾지만 상상 속 문제나 보안 버그가 아닌 실제 문제도 아주 잘 찾는다며, LLM 출력을 무분별하게 대량으로 넘기는 보고자에게는 발견 공로를 인정하지 않겠다고 했다. HackerOne 행동 강령은 지어낸 엔드포인트나 근거 없는 영향 주장 같은 환각이 든 AI 결과에 기대는 제출을 금지하고, 저품질·미검증 보고를 대량으로 내면 첫 위반에 최종 경고, 두 번째에 12개월 정지, 세 번째에 영구 퇴출을 기본 제재로 두고, 사안에 따라 더 무겁게도 가볍게도 할 수 있다고 밝혔다.

원인: 보고서는 싸졌고 검증은 여전히 사람 몫이다

앤트로픽은 최근 6개월 동안 2만9천 건이 넘는 후보를 찾았지만 사람이 검토·분류한 것은 약 6천 건이라며 검증할 사람의 역량이 병목이라고 밝혔다. 모델이 후보를 내는 속도와 사람이 확인하는 속도의 차이가 그대로 받는 쪽으로 넘어온다. Go 정책의 표현대로 LLM 보고의 가치는 선별에 있는데, 수십 건을 보내고 그 안에 숨은 한 건을 찾게 하면 선별을 유지보수자에게 떠넘기는 셈이다.

보상도 원인으로 꼽힌다. curl은 돈을 받을 수 있다는 기대가 저품질 보고의 큰 이유라고 본다. 파이썬 소프트웨어 재단(PSF)의 Seth Larson은 2024년 12월, LLM 환각 보고는 언뜻 그럴듯해 반박에 시간이 든다고 짚었다. 도구 결과를 검토 없이 옮기는 보고도 같다. urllib3는 SSLv2를 명시적으로 끄는 코드를 '안전하지 않은 SSLv2 사용'으로 잡은 도구 결과를 그대로 보고받았다.

좋은 AI 보고에도 한계가 있다. OSS Scanner 보고를 받은 유지보수자 일부는 심각도가 부풀려지거나 스캐너가 프로젝트의 위협 모델을 잘못 이해했다고 했다. Stenberg는 AI 분석기가 주석을 진지하게 받아들이는 탓에 낡은 주석이 틀린 사실을 담고 있으면 잘못된 보고를 낼 수 있다고 적었다.

AI 취약점 보고서 검증 절차 7가지

아래 7개 질문에 예/아니오로 답한다. 외부 제보, 버그바운티, 사내 AI 스캐너 결과에 똑같이 쓴다. '아니오'인 항목부터 보완한다.

1. 우리 최신 빌드에서 PoC를 직접 재현했는가

HackerOne 행동 강령은 AI를 썼더라도 발견을 검증하고 공격 단계를 잇고 재현 가능한 개념 증명(PoC)을 내야 한다는 요구는 같다고 밝히고, PoC가 없거나 재현되지 않거나 영상만 있거나 영향을 보이지 못한 보고는 '해당 없음(N/A)'으로 닫는다. 구글 OSS VRP 규칙도 최신 빌드에서 빌드되는 PoC, 재현 절차, 영향 버전, 공격 시나리오를 요청한다. 웹·API 취약점이라면 요청과 응답 원문을 함께 받는다. 재현은 운영 환경이 아닌 격리된 환경에서 한다. 재현되지 않으면 먼저 영향 버전, 빌드 옵션, 실행 환경이 맞는지 확인하고 부족한 근거를 요청한다. AI 생성이 의심되는 저품질 보고라면 Seth Larson이 2024년 12월 유지보수자에게 권한 대로 근거를 더 달라고 짧게 답하고 일단 닫은 뒤, 답이 오면 다시 검토할 수 있다.

2. 보고서가 말한 함수·파일·엔드포인트가 우리 코드에 실제로 있는가

보고서에 적힌 함수 이름, 파일 경로, 엔드포인트, 버전을 보고 시점의 커밋에서 검색한다(git grep -n "함수명" <커밋>). 없는 이름이 나오면 환각을 의심하고, git log -S"함수명" --oneline으로 그 이름이 언제 생기고 사라졌는지도 본다. 있더라도 배포되는 코드인지 본다. curl이 공개한 AI 슬롭 목록에는 테스트 서버 코드(tests/server/mqttd.c)의 버퍼 오버플로를 주장한 보고가 있는데, curl 정책은 테스트 코드와 테스트 서버의 문제를 보안 취약점으로 받지 않는다. 주석과 실제 동작이 다르면 보고서가 낡은 주석을 근거로 삼았는지도 확인한다.

3. 외부 입력이 그 코드 경로까지 닿는가

결함이 실제로 있어도 닿지 않으면 위험이 달라진다. curl은 2025년 9월 정확히 짚은 krb5-ftp 결함이 다른 이유로 코드가 동작하지 않아 도달할 수 없었던 덕에 CVE가 되지 않았다고 밝히고, 이 교훈으로 그 기능을 아예 뺐다. SQLite는 지금까지 보고된 자사 취약점이 모두 공격자가 임의 SQL을 실행하거나 조작한 DB 파일을 열게 할 수 있어야 성립한다고 설명한다. Seth Larson은 PoC가 라이브러리를 안전하지 않게 써서 취약점이 우리 코드가 아니라 PoC 쪽에 있는 경우가 많다고 했다. HackerOne도 기존 완화 장치를 고려하지 않은 발견은 실제 공격 경로를 보이지 않는 한 유효하지 않다고 본다. 외부 진입점에서 해당 코드까지 입력을 따라가고, 필요한 설정·빌드 옵션·권한 전제를 적는다. PoC가 내부 함수를 직접 부르는 형태라면 같은 입력을 실제 외부 인터페이스(HTTP 요청, 업로드 파일, 명령줄 인자)로 다시 넣어 같은 결과가 나는지 본다.

4. 영향 버전, 이미 고쳤는지, 중복인지 확인했는가

OSS Scanner 초기판 검증에서 기준을 못 넘은 12건 가운데 11건은 실제 결함이지만 이미 알려진 문제나 같은 스캔의 다른 결과와 중복이었다. 결함이 어느 커밋에서 들어왔는지 이분 탐색(bisect)으로 찾고, 최신 브랜치에서 이미 고쳤는지, 기존 이슈·보안 권고와 겹치는지 본다. 재현 스크립트가 결함이 있으면 1, 없으면 0을 돌려주게 만든 뒤 git bisect start <문제 커밋> <정상 커밋>과 git bisect run ./repro.sh로 결함이 들어온 커밋을 찾는다. 앤트로픽 보고서도 가능하면 결함이 들어온 시점을 이분 탐색해 붙인다. curl 공지처럼 영향 버전, 들어온 커밋, 고친 커밋을 함께 남기면 다음 보고 처리가 빨라진다(CVE-2025-9086 공지는 영향 버전 8.13.0부터 8.15.0까지, 지원 배포판 8.14.x 계열의 예외(8.14.2 이상), 결함을 넣은 커밋, 고친 커밋, 8.16.0 업그레이드 권고를 한곳에 실었다).

5. 심각도를 우리 서비스 맥락으로 다시 매겼는가

같은 결함도 점수가 갈린다. curl은 CVE-2025-9086을 공격자가 같은 이름의 http 사이트를 쥐거나 중간자 위치에 있어야 한다는 점 등을 들어 낮음(Low)으로 매겼지만, NVD에 실린 CISA의 CVSS 3.1 점수는 7.5(높음)다. curl 공지는 이 결함이 curl 명령줄 도구에는 해당하지 않는다고도 적었다. 우리 제품이 영향받는 구성 요소를 실제로 쓰는지도 등급에 넣는다. 구글은 CVE-2025-6965를 블로그에서 '치명적인 보안 결함'이라 불렀지만, CNA로서 직접 매긴 CVSS 4.0 점수는 7.2(높음)이고 NVD의 CVSS 3.1 점수는 7.7(높음)이다. Go 보안팀은 같은 JSON 파서 결함도 신뢰할 수 있는 로컬 파일을 읽을 때와 HTTP 요청 본문을 읽을 때 영향이 다르다며 CVSS를 매기지 않는다. HackerOne은 심각도 부풀리기를 반복하면 행동 강령 위반으로 본다. 앤트로픽 대시보드의 심각도 비교표에서도 모델이 '치명'으로 매긴 259건 가운데 외부 업체가 '치명'으로 본 것은 116건이었다(2026년 10월 2일 기준). 보고서의 점수는 출발점으로 쓰고, CVSS 벡터의 공격 경로·필요 권한 항목이 우리 환경과 맞는지 본 뒤 외부 노출, 인증 필요 여부, 닿는 데이터로 우리 등급을 다시 정한 근거를 남긴다. 노출·악용 여부로 패치 순서를 정하는 방법은 제로데이 패치 우선순위에 정리했다.

6. 수정 뒤 회귀 테스트와 같은 패턴 검색까지 했는가

AI 보고서에 수정안이 붙어 와도 초안으로 다룬다. 앤트로픽 CVD 정책은 후보 패치에 출처를 표시해 보내고, 운영 수준 수정은 유지보수자에게 함께 만들자고 제안한다. curl은 AI 도움으로 쓴 코드도 코딩 표준, 문서, 테스트 케이스를 갖춰야 받는다. PoC를 실패하는 테스트로 먼저 옮기고, 고친 뒤 통과하는지 본다. 같은 함수 호출이나 같은 입력 처리 방식이 다른 곳에 있는지 저장소 전체를 검색하고, 고친 버전이 실제 운영 환경에 배포됐는지까지 확인한다.

7. 공개 일정과 제보자 소통 규칙을 문서로 두었는가

앤트로픽 CVD 정책은 90일 또는 패치 공개 중 이른 쪽을 공개 시점으로 삼고, 수정이 진행 중이면 요청에 따라 14일을 연장할 수 있고, 실제 악용 중인 치명 취약점은 7일 안 패치·완화를 목표로 한다. 30일간 답이 없으면 외부 조정 기관으로 넘기는 것을 목표로 하고, 패치 뒤에는 원칙적으로 45일을 기다려 세부 기술을 공개하되 상황에 따라 이 기간을 줄이거나 늘린다. 심각도 판단이 엇갈리면 대체로 유지보수자 판단을 따른다. 반면 사람이 검토하지 않은 OSS Scanner 보고에는 오탐 가능성 때문에 90일 기한을 두지 않는다. Go는 7일 안에 접수를 확인하고, 첫 확인 뒤 90일 안에 고치거나 공개한다. 우리도 접수 확인 기한, 공개 기한, 거절 시 사유 회신, AI 사용 고지(curl은 AI로 찾았다면 보고서에 반드시 밝히라고 정했다)를 보안 정책 문서(SECURITY.md 등)에 적는다. OSS Scanner가 받는 위협 모델 파일처럼 시험 대상, 적대적 입력, 범위 밖, 심각도 기준, 중복 판단 단위를 미리 적어 두면 사람 보고자와 AI 보고자 모두 헛걸음이 준다.

AI 취약점 분석을 직접 할 때 지킬 것

• 허가된 대상만: 앤트로픽 CVP의 레드팀 단계도 시험 허가를 받은 시스템에만 공격 시험을 허용하고, 일반 모델로는 코드 리뷰, 자사 소스 코드의 취약점 찾기, 보안 경보 분류를 할 수 있다고 안내한다. HackerOne도 AI를 쓴 활동이 프로그램 범위와 자동화·요청량 제한을 지키게 한다.
• 비밀값과 고객 데이터는 빼고 넣기: 앤트로픽 CVP는 오남용 감시를 위해 참여 조직에 원칙적으로 데이터 보관을 요구한다. 외부 AI 서비스에 코드·로그를 보내기 전에 보관 기간과 계약 조건을 확인하고, API 키·토큰·개인정보는 지운다. 앤트로픽은 OSS Scanner 에이전트를 인터넷을 끈 격리 환경에서 돌리고 보고 메일 암호화를 선택할 수 있게 했다. 보고서 자체도 비밀로 다룬다. curl이 GitHub 비공개 보고에서 첫 문제로 꼽은 것도 보고 전체가 메일 알림으로 나가 비밀이 일찍 샐 수 있다는 점이었다.
• AI 결과는 후보로 기록: 앤트로픽 대시보드는 심각도를 모델, 외부 검토 업체, 유지보수자 평가로 나눠 기록한다. 사내에서도 'AI 후보'와 '사람이 재현한 결과'를 나눠 관리한다.
• 밖으로 보낼 때는 사람이 검토하고 AI 사용을 밝히기: 2024년 12월 Seth Larson은 AI로 취약점을 탐지하는 것 자체를 권하지 않았고, 그래도 보고한다면 사람이 먼저 검토하고, 몇 건만 보낸 뒤 반응을 기다리고, 보고만이 아니라 패치를 들고 가라고 했다. curl은 보고 전에 결과를 직접 재확인하라고 요구하고, AI 보고를 그대로 붙이지 말고 확인한 내용을 자기 말로 쓰라고 권한다. 앤트로픽 CVD 정책도 보내는 보고는 원칙적으로 사람이 검토·확인한 것이며 AI로 찾은 보고는 그렇게 표시한다고 적었다. 다만 유지보수자가 원한 경우에는 검증 전 보고도 그대로 보냈다.

AI로 넓게 찾고 레드팀이 재현하는 진단

보안 전문 기업 SENTRIX의 AI 심화 취약점 진단은 '탐색은 AI. 검증은 레드팀.' 방식이다. 자동화는 합의한 대상의 노출·구성 정보를 모으고 패턴 기반 점검으로 취약점 후보를 정리하며, 전문가는 그 후보를 서비스 맥락과 실제 재현 결과로 검토해 연쇄 공격 경로의 재현 조건과 영향을 확인하고, 확인된 결과와 추가 확인이 필요한 후보를 나눠 수정 방향을 안내한다. 재점검 범위·횟수는 계약 시 확정하며, 모든 취약점의 발견을 보장하는 서비스는 아니다. 우리 웹 서비스·API를 AI 점검 도구로 넓게 훑고, 나온 후보가 실제로 재현되는지 레드팀이 확인한 결과가 필요하다면 진단 범위부터 상의하세요. 진단 문의하기

참고 자료

• 앤트로픽, Expanding the Cyber Verification Program(2026-10-06)
• 앤트로픽, Introducing the Anthropic Cyber Mission(2026-10-08)
• 앤트로픽 Frontier Red Team, Launching an opt-in vulnerability-finding service for open-source software(2026-10-08)
• 앤트로픽 Frontier Red Team, OSS Scanner 안내·FAQ(2026-10-08)
• 앤트로픽 Frontier Red Team, Anthropic's coordinated vulnerability disclosure dashboard·About(2026-10-02 기준)
• 앤트로픽, AI가 찾은 취약점의 조정 공개(CVD) 정책(2026-03-06 갱신)
• 앤트로픽, Project Glasswing: Securing critical software for the AI era(2026-04-07)
• Daniel Stenberg(curl), Death by a thousand slops(2025-07-14)
• Daniel Stenberg(curl), A new breed of analyzers(2025-10-10)
• Daniel Stenberg(curl), The end of the curl bug-bounty(2026-01-26)
• Daniel Stenberg(curl), curl security moves again(2026-02-25)
• curl, Contribute to the curl project(On AI use in curl)·Vulnerability Disclosure Policy(2026-10-14 확인)
• curl, CVE-2025-9086: Out of bounds read for cookie path(2025-09-10)
• NIST NVD, CVE-2025-9086(2025-09-12)·CVE-2025-6965(2025-07-15)
• 구글, A summer of security: empowering cyber defenders with AI(2025-07-15)
• SQLite, Vulnerabilities(2026-10-14 확인)
• 구글 Bug Hunters, Google Open Source Software Vulnerability Reward Program Rules·규칙 변경 커밋(2026-09-30)
• 구글 VRP, OSS VRP 제품 취약점 접수 중단 안내(X 게시물)(2026-10-01)
• Go, Go Security Policy(2026-09-03, LLM 생성 보고 조항 추가)
• HackerOne, Code of Conduct(2026-10-14 확인)
• Seth Larson, New era of slop security reports for open source(2024-12-03)