facts

최근 깃허브(GitHub)의 특정 저장소(programmervuln/cveadvisory-)를 통해 배포된 SQLite 취약점 권고안 55건 중 54건이 조작된 것으로 드러났다. JFrog 보안 연구팀의 분석 결과, 이들 대부분은 거대언어모델(LLM)이 생성한 허위 정보, 이른바 'LLM 슬롭(Slop)'이었다. 문제는 미국 국립취약점데이터베이스(NVD)와 사이버보안 및 인프라 보안국(CISA)의 ADP(Authorized Data Publishers)가 이 보고들을 빠르게 '심각(Critical)' 단계로 분류하며 공신력을 부여했다는 점이다. 레드햇(Red Hat) 역시 특정 CVE(CVE-2026-51302)에 초기 심각도 점수 10.0점을 부여했다가 이후 7.6점으로 하향 조정했다.

허위 보고서들은 기술적으로 매우 그럴듯하게 작성되었으나 실제 코드와는 완전히 동떨어져 있었다. 예를 들어, 특정 버전의 SQLite에 존재하지 않는 함수(`exprComputeOperands()`)에서 힙 유즈-애프터-프리(Heap Use-After-Free)가 발생한다고 주장하거나, 실제 소스 코드의 라인 번호가 댓글이나 메모리 할당 호출문임에도 불구하고 취약점 지점이라고 지목했다. 심지어 패치되었다고 주장한 버전(3.51.3)의 소스 코드를 이전 버전과 비교했을 때 아무런 변경 사항이 없는 경우도 확인됐다. 연구팀이 직접 쿼리를 실행해 PoC(Proof of Concept, 개념 증명) 테스트를 진행했으나, 대부분의 페이로드는 파서 단계에서 실패하거나 정상적으로 작동하며 아무런 오류를 일으키지 않았다.

market-flow

이번 사건은 취약점 보고 및 검증 파이프라인의 구조적 결함이 LLM의 생성 능력과 결합했을 때 발생하는 리스크를 보여준다. 현재 MITRE의 공개 양식을 통한 CVE 제출 과정에는 실질적인 신원 확인 절차가 없다. 누구나 취약점 설명과 CVSS(공통 취약점 점수 시스템) 점수를 제안할 수 있는 구조다. 과거에는 NVD 전문가들이 제출된 CVE를 수동으로 분석하고 검증하는 안전장치 역할을 했으나, 2024년 2월부터 이 체계가 무너졌다.

취약점 보고 건수가 폭증하면서 NIST(미국 국립표준기술연구소)가 심층 분석을 사실상 중단했기 때문이다. CISA 등 다른 데이터 발행자들이 보완에 나섰지만, 글로벌 파이프라인은 파편화되었고 처리 대기 물량은 쌓여만 갔다. 현재의 시스템은 제출 단계에서 PoC나 버그 재현 증명을 필수적으로 요구하지 않는다. 이 때문에 그럴듯하게 작성된 AI 생성 허위 권고안이 검증 없이 GHSA(GitHub Security Advisories)나 기업용 보안 스캐너까지 그대로 흘러 들어가는 경로가 열렸다.

reader-impact

보안 실무자와 AI 도입 기업이 주목해야 할 지점은 '자동화된 대응'의 위험성이다. 많은 기업이 심각도 점수에 따라 자동으로 티켓을 생성하고 패치 우선순위를 정한다. 존재하지 않는 취약점을 해결하기 위해 엔지니어가 시간을 낭비하는 '유령 패치' 비용이 실질적인 부담으로 다가온다. 특히 AI 에이전트를 활용해 취약점 분류와 수정(Remediation)을 자동화하는 환경에서는 더 치명적이다. AI 에이전트가 허위 CVE를 바탕으로 존재하지 않는 함수를 찾거나, 잘못된 패치를 생성해 코드에 적용할 경우 오히려 새로운 보안 홀을 만들 가능성이 크기 때문이다.

따라서 한국의 보안 담당자와 개발자는 CVSS 점수라는 수치적 지표에만 의존하는 방식에서 벗어나야 한다. 신뢰할 수 있는 출처의 PoC가 존재하는지, 실제 코드 변경 사항이 확인되는지를 먼저 검증하는 단계가 필수적이다. 이번 사례처럼 NVD나 CISA 같은 공신력 있는 기관의 초기 분류조차 오류일 수 있다는 전제하에, 자동화 도구가 제안하는 수정 사항을 맹신하지 않고 사람이 최종 검증하는 프로세스를 유지하는 것이 유일한 방어책이다.