SQLite critical CVE 소동, LLM 생성 보안 보고서의 비용

JFrog Security Research가 최근 SQLite 관련 critical CVE 묶음을 검증한 결과, 핵심 주장들이 실제 코드와 맞지 않는다고 밝혔다. 새로 만들어진 GitHub 저장소가 SQLite 취약점 advisory를 대량으로 올렸고, NVD와 CISA ADP metadata에도 높은 심각도로 반영되었다. 하지만 JFrog가 공식 SQLite 소스와 target version을 대조하고 PoC를 AddressSanitizer 환경에서 실행하자, 보고서의 상당 부분은 존재하지 않는 함수, 틀린 line number, 성립하지 않는 use-after-free 시나리오로 무너졌다.

대표 사례는 CVE-2026-51302다. advisory는 SQLite 3.41.0에서 exprComputeOperands()가 dangling pointer를 dereference한다고 주장했지만, JFrog에 따르면 그 함수는 해당 버전에 존재하지 않았다. CVE-2026-51303은 3.51.3에서 expr.c가 패치되었다는 식의 설명을 담았지만, JFrog가 3.51.2와 3.51.3을 비교했을 때 src/expr.c 변경은 없었다. CVE-2026-51296은 SQLite 3.41.0의 json.c에 존재하지 않는 line number를 지목했다.

중요한 점은 “LLM이 보안 취약점을 찾을 수 없다”가 아니다. 실제로 LLM 기반 분석은 fuzzing, triage, exploitability 검토에서 도움을 줄 수 있다. 이번 사례의 문제는 검증되지 않은 advisory가 CVE 생태계 안으로 들어오면서 신호 대 잡음비를 낮춘다는 데 있다. 보안팀은 이미 alert fatigue와 false positive에 시달린다. critical 등급으로 올라온 항목이 실제 코드에 없는 함수를 근거로 삼는다면, 진짜 취약점을 가려내는 비용은 더 커진다.

HN 댓글도 이 지점을 파고들었다. 커뮤니티 discussion은 자동 생성 보고서가 검증 파이프라인을 통과할 때 생기는 공격면, 그리고 NVD metadata를 신뢰하는 downstream scanner의 부담을 주로 짚었다. 원문은 JFrog Security Research 분석이며, 토론은 HN 스레드에서 이어졌다.