[CVE] AI가 만든 가짜 CVE와 인간 검증의 병목

들어가며

최근 2026년 CVE를 follow-up 하면서 인상적인 사례를 보았습니다. 처음에는 특정 DBMS 벤더의 취약점처럼 보였지만, 공개 보도와 JFrog 분석을 따라가 보면 실제는 SQLite를 대상으로 한 가짜 CVE 묶음이었습니다. 취약점 설명은 그럴듯했고, CVSS 점수도 높게 붙어 있었지만, 실제 검증 과정에서는 존재하지 않는 함수나 취약점과 무관한 코드 라인을 근거로 삼은 항목이 확인되었습니다.

이 사례가 흥미로운 이유는 단순한 오탐(false positive)이 아니라, AI 환각(hallucination)으로 보이는 취약점 보고서가 CVE 생태계 안으로 유입되었다는 점입니다. AI는 보안 연구의 생산성을 높이는 도구가 될 수 있지만, 동시에 검증되지 않은 보고서를 대량 생산하는 도구도 될 수 있습니다.

이 글에서는 해당 사례를 계기로, AI 시대의 취약점 제보가 왜 급증할 수밖에 없는지, 인간 검증이 왜 병목이 되는지, 그리고 보안 실무자가 어떤 방식으로 대비해야 하는지 정리합니다.

 

 

사건의 핵심: 취약점처럼 보이지만 취약점이 아닌 보고서

CVE(Common Vulnerabilities and Exposures)는 취약점 식별 체계입니다. 보안 실무자는 CVE 번호를 기준으로 영향도 평가, 패치 우선순위 결정, 자산 점검, 보안 관제 룰 작성 등을 수행합니다.

하지만 CVE가 붙었다고 해서 그 항목이 항상 “검증 완료된 실제 취약점”을 의미하지는 않습니다. CVE는 기본적으로 식별자입니다. 그 식별자가 붙는 과정에는 CNA(CVE Numbering Authority), 벤더, 연구자, NVD(National Vulnerability Database), 배포판 보안팀 등 여러 주체가 관여합니다.

이번 사례에서 눈에 띄는 부분은 다음과 같습니다.

• SQLite 대상 고위험 CVE들이 공개됨
• 일부 항목은 CVSS 9점대 이상의 심각도로 표기됨
• JFrog가 검증한 결과, 보고서의 코드 참조가 실제 코드와 맞지 않음
• 존재하지 않는 함수 또는 취약점과 무관한 라인을 근거로 듦
• PoC(Proof of Concept) 실행 결과 실제 오류나 취약 동작이 재현되지 않음
• 이후 관련 CVE들이 플래그 처리되거나 제거·반려되는 흐름으로 이어짐

즉, “그럴듯한 취약점 보고서”는 있었지만, 취약점을 구성하는 핵심 요건인 영향 버전, 취약 코드, 재현 가능한 트리거, 보안 영향, 패치 근거가 충분하지 않았던 것입니다.

 

왜 AI 시대에 취약점 제보는 폭증하는가

AI가 취약점 연구를 도와주는 것은 분명 긍정적인 면이 있습니다. 코드를 빠르게 읽고, 위험한 API 사용 패턴을 찾고, 기존 취약점과 유사한 구조를 비교하는 데 도움을 줄 수 있습니다. 보안 입문자에게는 학습 곡선을 낮추는 도구가 되기도 합니다.

하지만 같은 이유로, 저품질 취약점 제보도 폭증할 수밖에 없습니다.

1. 보고서 작성 비용이 거의 0에 가까워졌습니다

과거에는 취약점 보고서를 작성하려면 최소한 다음 과정이 필요했습니다.

1. 대상 소프트웨어의 특정 버전을 확인합니다.
2. 코드를 읽고 위험한 흐름을 찾습니다.
3. 입력값이 실제로 해당 코드 경로에 도달하는지 검증합니다.
4. PoC를 작성합니다.
5. 크래시, 정보 유출, 권한 상승 등 보안 영향을 재현합니다.
6. 패치 또는 완화 방안을 제시합니다.
7. 벤더에게 전달할 수 있는 형태로 보고서를 정리합니다.

지금은 AI에게 코드 일부와 원하는 취약점 유형을 던져주면, 몇 분 안에 그럴듯한 보고서가 나옵니다. 문제는 “그럴듯함”과 “검증됨”이 다르다는 점입니다.

AI는 문맥상 자연스러운 설명을 생성할 수 있지만, 그 설명이 실제 코드베이스에 존재하는 함수, 실제 호출 경로, 실제 취약 조건과 일치하는지 자동으로 보장하지 않습니다.

 

 

2. 공격자에게도 같은 생산성 향상이 적용됩니다

AI는 방어자만 쓰는 도구가 아닙니다. 공격자는 다음 작업에 AI를 활용할 수 있습니다.

• 대량의 오픈소스 프로젝트 스캔
• 취약 패턴 후보 생성
• PoC 코드 초안 작성
• 피싱 문구 생성
• 취약점 보고서 위장
• 자동화된 버그바운티 제출
• CVE 데이터베이스 또는 보안 피드 오염 시도

특히 취약점 제보 영역에서는 “실제 취약점 발굴”보다 “취약점처럼 보이는 보고서 대량 생산”이 훨씬 쉽습니다. 이것이 문제입니다.

AI는 공격의 성공률만 높이는 것이 아니라, 검증해야 할 노이즈의 양도 늘립니다.

 

 

3. 보상 구조가 저품질 보고서를 유도할 수 있습니다

취약점 제보에는 명성, 이력, 금전 보상, 연구 실적이라는 동기가 붙습니다. 좋은 동기일 수도 있지만, 반대로 “많이 제출하는 것” 자체가 목적이 되면 품질은 떨어질 수 있습니다.

AI를 이용하면 다음과 같은 행위가 쉬워집니다.

• 실제 검증 없이 CVE 요청 문서 생성
• 기존 취약점 패턴을 이름만 바꿔 재활용
• 존재하지 않는 코드 경로를 근거로 보고서 작성
• 자동화된 SAST 결과를 과장해 고위험 취약점처럼 포장
• CVSS 점수를 과도하게 높게 산정

이런 보고서가 일부라도 CVE 생태계로 들어오면, 그 뒤의 비용은 모두 방어자와 메인테이너가 부담합니다.

 

 

인간 검증은 왜 병목이 되는가

JFrog 연구자가 The Register에 전달한 말이 핵심을 잘 짚습니다. 생성형 AI는 그럴듯한 advisory를 만드는 비용을 거의 0에 가깝게 낮췄지만, 검증 비용은 그대로입니다.

취약점 검증은 여전히 사람이 해야 할 일이 많습니다.

 

 

1. 코드를 실제로 읽어야 합니다

취약점 보고서에 특정 함수가 언급되어 있다면, 먼저 그 함수가 해당 버전에 존재하는지 확인해야 합니다. 존재한다면 호출 경로가 있는지 봐야 합니다. 호출 경로가 있다면 공격자가 제어 가능한 입력이 도달하는지 확인해야 합니다.

AI가 “이 함수에서 use-after-free가 발생합니다”라고 말해도, 실제로는 다음 중 하나일 수 있습니다.

• 해당 함수가 현재 버전에 없음
• 함수명은 있지만 코드가 다름
• 해당 코드 경로는 외부 입력으로 도달할 수 없음
• 메모리 해제가 발생하지만 재사용되지 않음
• 크래시는 가능하지만 보안 영향이 없음
• 테스트 환경에서만 발생하는 비현실적 조건임

이 구분은 아직 자동화만으로 완전히 해결하기 어렵습니다.

 

2. PoC를 재현해야 합니다

보안 영향은 말로 주장하는 것이 아니라 재현되어야 합니다. 최소한 다음이 확인되어야 합니다.

• 영향받는 정확한 버전
• 빌드 옵션
• 실행 환경
• 입력값
• 크래시 또는 비정상 동작
• sanitizer, debugger, 로그 등 증거
• 패치 후 재현 불가 여부

PoC가 “실행된다”는 것과 “취약점이 재현된다”는 것도 다릅니다. JFrog 사례에서도 PoC가 정상 쿼리를 실행했을 뿐, 메모리 누수나 오류를 만들지 못한 경우가 언급되었습니다.

 

3. 보안 영향도를 판단해야 합니다

버그가 있다고 해서 모두 취약점은 아닙니다. 취약점이라고 해도 모두 Critical은 아닙니다.

예를 들어 다음 질문이 필요합니다.

• 공격자가 원격에서 트리거할 수 있는가?
• 인증이 필요한가?
• 기본 설정에서 발생하는가?
• 데이터 유출, 권한 상승, 원격 코드 실행(RCE)으로 이어지는가?
• DoS라면 서비스 영향 범위가 어느 정도인가?
• 현실적인 exploit primitive가 있는가?

이 판단은 코드, 제품 사용 방식, 위협 모델(threat model), 배포 환경을 함께 봐야 합니다. 단순히 LLM이 “Critical”이라고 썼다고 Critical이 되는 것이 아닙니다.

 

4. 메인테이너와 벤더의 시간이 가장 비쌉니다

오픈소스 메인테이너나 벤더 보안팀은 이미 많은 일을 하고 있습니다. 실제 취약점 대응, 릴리스 관리, 사용자 커뮤니케이션, 보안 패치, 회귀 테스트까지 해야 합니다.

여기에 AI가 만든 저품질 보고서가 대량으로 들어오면 어떤 일이 생길까요?

• 진짜 취약점 대응이 늦어짐
• 메인테이너 피로도가 증가함
• CVE 데이터 품질이 낮아짐
• 보안팀이 오탐 티켓 처리에 시간을 소모함
• 자동화된 취약점 관리 시스템의 신뢰도가 떨어짐

결국 AI가 만든 속도는 인간 검증 단계에서 막힙니다. 그리고 그 병목은 단순한 처리량 문제가 아니라, 보안 생태계의 신뢰 문제로 이어집니다.

 

CVE 데이터베이스 오염이 위험한 이유

가짜 CVE는 단순히 “틀린 정보 하나”로 끝나지 않습니다. CVE는 여러 시스템의 입력값이기 때문입니다.

일반적인 기업 환경에서는 CVE 정보가 다음 흐름으로 전파됩니다.

CVE/NVD/벤더 advisory
        ↓
취약점 스캐너
        ↓
자산 관리 시스템
        ↓
보안 티켓
        ↓
패치 우선순위
        ↓
경영진 보고 / 감사 대응 / SLA 관리

이 흐름에 가짜 CVE가 들어가면 다음 문제가 생깁니다.

 

1. 패치 우선순위가 왜곡됩니다

실제 위험도가 높은 취약점보다 가짜 Critical CVE가 먼저 처리될 수 있습니다. 보안팀 입장에서는 CVSS 9.8로 들어온 항목을 무시하기 어렵습니다. 하지만 검증되지 않은 Critical이 많아질수록 진짜 Critical의 신호가 약해집니다.

 

2. 스캐너 결과에 대한 불신이 커집니다

보안 스캐너가 계속 잘못된 결과를 내면 개발팀은 이렇게 반응합니다.

“또 보안팀 오탐이네요.”

이 말이 반복되면, 진짜 취약점 티켓도 설득력이 떨어집니다. 보안팀의 가장 큰 자산은 도구가 아니라 신뢰입니다. 데이터 품질이 낮아지면 그 신뢰가 먼저 손상됩니다.

 

3. 자동화된 의사결정이 잘못됩니다

많은 조직이 취약점 대응을 자동화하고 있습니다.

• Critical이면 자동 티켓 생성
• 인터넷 노출 자산이면 SLA 단축
• exploit 공개 여부에 따라 우선순위 상승
• 특정 패키지가 포함되면 빌드 차단
• 컨테이너 이미지 배포 중단

이런 자동화는 입력 데이터가 신뢰할 만할 때 강력합니다. 반대로 입력 데이터가 오염되면 자동화는 실수를 빠르게 확산시키는 장치가 됩니다.

 

앞으로 이런 사례는 더 많아질 가능성이 높습니다

필자는 이번 사례가 예외적인 사건이라기보다, 앞으로 더 자주 보게 될 신호라고 생각합니다. 이유는 단순합니다.

• AI로 보고서 생성 비용은 계속 낮아집니다.
• CVE와 버그바운티는 여전히 명성과 보상을 제공합니다.
• 오픈소스 생태계의 검증 인력은 제한적입니다.
• NVD 같은 공공 취약점 데이터베이스도 처리량 부담을 겪고 있습니다.
• 기업 보안팀은 이미 너무 많은 취약점 티켓을 처리하고 있습니다.

즉, 공격자와 저품질 제보자는 “대량 생성”을 할 수 있지만, 방어자는 여전히 “정밀 검증”을 해야 합니다. 이 비대칭성이 핵심입니다.

보안에서 비대칭성은 익숙한 개념입니다. 공격자는 한 번 성공하면 되고, 방어자는 모든 경로를 막아야 한다는 말이 있습니다. AI 시대에는 여기에 하나가 더 추가됩니다.

공격자는 보고서를 대량 생성할 수 있고, 방어자는 하나씩 검증해야 합니다.

이 구조가 바뀌지 않으면, 인간은 점점 더 큰 병목이 됩니다.

 

 

어떻게 대비해야 할까

그렇다고 모든 CVE를 의심하고 아무것도 믿지 말자는 뜻은 아닙니다. 필요한 것은 “무조건 신뢰”와 “무조건 불신” 사이의 검증 체계입니다.

 

1. 벤더 확인 여부를 우선 봐야 합니다

가장 먼저 확인할 것은 벤더 또는 메인테이너가 해당 취약점을 인정했는지입니다. 물론 이번 예시의 사례는 벤더에서 직접 공개한 취약점이기 때문에 신빙성을 보장한다고는 할 수 없지만 교차 검증은 필요합니다.

확인 포인트는 다음과 같습니다.

• 공식 advisory가 있는가?
• 보안 릴리스 노트에 언급되었는가?
• 패치 커밋이 존재하는가?
• issue 또는 pull request가 연결되어 있는가?
• 메인테이너가 disputed, rejected, not affected로 표시했는가?

벤더 확인이 없고, CVE 설명만 그럴듯하다면 우선순위를 낮추거나 보류하는 것이 합리적입니다.

 

 

2. 코드 근거가 실제로 존재하는지 확인해야 합니다

AI가 만든 보고서는 코드 참조에서 흔히 무너집니다.

확인해야 할 질문은 간단합니다.

- 언급된 파일이 실제 영향 버전에 존재하는가?
- 언급된 함수가 존재하는가?
- 코드 라인이 실제 취약 주장과 관련 있는가?
- 공격자가 제어 가능한 입력이 해당 코드까지 도달하는가?
- 패치 커밋이 그 코드 경로를 수정하는가?

이 단계에서 존재하지 않는 함수가 나오면 거의 끝입니다. 더 볼 필요 없이 신뢰도를 크게 낮춰야 합니다.

3. PoC는 “실행”이 아니라 “영향”을 확인해야 합니다

PoC가 돌아간다는 말은 의미가 약합니다. 중요한 것은 실제 보안 영향입니다.

예를 들어 메모리 취약점이라면 다음 증거가 필요합니다.

• AddressSanitizer 결과
• Valgrind 결과
• crash dump
• debugger backtrace
• 재현 가능한 입력 파일
• 패치 전/후 비교

웹 취약점이라면 다음이 필요합니다.

• 요청/응답 캡처
• 인증 조건
• 권한 조건
• 데이터 유출 또는 상태 변경 증거
• 기본 설정에서의 재현 여부

PoC가 단순히 정상 입력을 넣고 정상 출력을 받는다면 취약점 증거가 아닙니다.

 

4. CVSS 점수를 그대로 믿지 않아야 합니다

CVSS(Common Vulnerability Scoring System)는 유용하지만, 입력값이 잘못되면 점수도 잘못됩니다. 특히 AI가 생성한 보고서는 CVSS 벡터를 과장하기 쉽습니다.

실무에서는 다음을 따로 보아야 합니다.

• 인터넷 노출 여부
• 실제 자산 내 사용 여부
• 라이브러리 호출 가능 여부
• vulnerable function 도달 가능성
• exploit 공개 여부
• EPSS 등 실제 악용 가능성 지표
• CISA KEV 등 알려진 악용 목록 등재 여부

“CVSS 9.8이니까 무조건 긴급”이 아니라, “우리 환경에서 실제로 공격 가능한가”를 확인해야 합니다.

 

5. 취약점 관리 파이프라인에 검증 단계를 넣어야 합니다

조직 차원에서는 CVE 수집 후 바로 티켓을 만들기보다, 중간에 신뢰도 평가 단계를 두는 것이 좋습니다.

신규 CVE 수집
  ↓
벤더 advisory 확인
  ↓
패치 커밋 / release note 확인
  ↓
자산 내 실제 사용 여부 확인
  ↓
도달 가능성(reachability) 평가
  ↓
우선순위 산정
  ↓
티켓 생성 / 패치 / 예외 처리

모든 CVE에 대해 완전한 수동 검증을 하기는 어렵습니다. 대신 다음과 같이 단계화할 수 있습니다.

• 인터넷 노출 자산 + KEV 등재: 즉시 대응
• 벤더 확인 + exploit 공개: 긴급 검증
• 벤더 미확인 + 코드 근거 불명확: 보류 또는 낮은 우선순위
• CVSS만 높고 재현 근거 없음: 검증 큐로 분리
• disputed/rejected 표기: 자동 티켓 생성 제외

 

개인적인 고찰: AI보다 사람이 느려서 문제가 아니라, 사람이 마지막 책임자라서 문제입니다

이 사례를 보면서 든 생각은 단순히 “AI가 위험하다”가 아닙니다. 오히려 AI는 앞으로 보안 업무에서 빠질 수 없는 도구가 될 것입니다. 필자도 취약점 분석, 로그 정리, 코드 리뷰 보조, 문서 초안 작성에서 AI의 효율을 체감하고 있습니다.

문제는 AI가 아니라 검증 책임의 위치입니다.

AI는 가능성을 제시할 수 있습니다. 하지만 그 가능성이 실제 취약점인지, 공격 가능한지, 우리 조직에 영향을 주는지, 고객에게 어떤 리스크로 설명해야 하는지는 결국 사람이 판단해야 합니다.

그리고 이 판단은 느립니다. 느릴 수밖에 없습니다. 코드를 읽어야 하고, 환경을 만들어야 하고, PoC를 돌려야 하고, 벤더 문서를 확인해야 하고, 이해관계자에게 설명해야 합니다. 이 과정은 AI가 보고서 하나를 생성하는 속도와 비교할 수 없습니다.

따라서 앞으로의 보안 업무는 “AI를 쓰느냐 마느냐”가 아니라, AI가 만든 결과물을 어떤 검증 구조 안에 넣을 것인가의 문제가 될 것입니다.

필자는 다음 세 가지가 중요해질 것이라고 봅니다.

1. 증거 중심 문화
   취약점 보고서에는 주장보다 증거가 중요합니다. 코드 위치, 재현 절차, 패치 커밋, 로그, 크래시 덤프가 없는 보고서는 우선순위를 낮춰야 합니다.
2. 신뢰도 기반 취약점 관리
   CVSS 하나로 움직이는 방식은 점점 위험해집니다. 벤더 확인, exploit 성숙도, 자산 노출도, 도달 가능성, KEV 여부를 함께 봐야 합니다.
3. 인간 검증자의 시간을 보호하는 자동화
   자동화는 인간을 대체하기보다, 인간이 볼 가치가 있는 항목을 선별해야 합니다. 존재하지 않는 함수, 없는 파일, 벤더 미확인 항목, 재현 불가 PoC를 먼저 걸러내는 것만으로도 큰 차이가 납니다.

AI 시대의 보안 병목은 “사람이 느리다”가 아닙니다. 사람이 최종 판단을 내려야 하는 항목이 너무 많아진다는 점입니다. 그래서 앞으로의 방어 전략은 더 많은 티켓을 만드는 것이 아니라, 더 적은 티켓을 더 정확하게 만드는 방향으로 가야 합니다.

 

 

마치며

AI가 만든 가짜 CVE 사례는 취약점 관리의 전제를 다시 생각하게 만듭니다. CVE, NVD, CVSS, 스캐너 결과는 모두 중요하지만, 그 자체로 진실은 아닙니다. 결국 보안 실무자는 “이 취약점이 실제로 존재하는가”, “우리 환경에서 공격 가능한가”, “지금 당장 대응해야 하는가”를 검증해야 합니다.

앞으로 AI는 공격자와 방어자 모두의 속도를 높일 것입니다. 하지만 검증의 책임은 여전히 사람에게 남습니다. 따라서 보안 조직은 AI를 도입하는 것만큼이나, AI가 만든 노이즈를 걸러내는 체계를 준비해야 합니다.

 

References

• JFrog Security Research, Software Vulnerabilities: https://research.jfrog.com/vulnerabilities/
• The Register, “AI slop pollutes the CVE pipeline with fake vulns”, 2026-08-03: https://www.theregister.com/security/2026/08/03/ai-slop-pollutes-the-cve-pipeline-with-fake-vulns/5282462
• JFrog Blog, “Vulnerability or Not a Vulnerability?”, 2026-02-16: https://jfrog.com/blog/vulnerability-or-not-a-vulnerability/
• JFrog Blog, “How Inflated CVE Severity Scores can Affect Software Pipelines”, 2026-06-30: https://jfrog.com/blog/where-cve-severity-scores-go-wrong/
• MITRE CVE Program: https://www.cve.org/
• NVD, National Vulnerability Database: https://nvd.nist.gov/