AI가 지어낸 SQLite 취약점에 '치명적' CVE가 붙었다

보안 담당자는 아침마다 새로 올라온 CVE 목록을 확인합니다. 여기에 우리가 쓰는 라이브러리 이름이 뜨면 그날 일정이 통째로 바뀝니다. 그런데 그 목록에 실제로는 존재하지 않는 취약점이 올라오기 시작했습니다. 그것도 ‘치명적(Critical)’ 등급을 달고 말입니다.

AI가 지어낸 버그가 공식 번호를 받기까지

구조는 단순합니다. 누군가 LLM에 오픈소스 프로젝트 코드를 통째로 던져주고 “취약점을 찾아달라"고 시킵니다. 모델은 그럴듯한 분석을 뱉어냅니다. 함수 이름도 맞고 파일 경로도 맞습니다. 설명은 교과서처럼 매끄럽고요. 다만 그런 취약점이 없을 뿐입니다.

이 보고서가 CVE 채번 기관에 접수됩니다. 그리고 통과합니다. 번호가 발급되고 심각도 점수가 매겨집니다. 전 세계 취약점 스캐너가 이 데이터를 그대로 빨아들입니다.

SQLite라서 더 뼈아픕니다. SQLite는 지구상에서 가장 많이 배포된 데이터베이스입니다. 스마트폰마다, 브라우저마다, 항공기 소프트웨어에까지 들어가 있습니다. 검증에 편집증적인 프로젝트로도 유명합니다. 테스트 코드가 본체 코드보다 수백 배 많습니다. 그런 프로젝트에 없는 버그가 공식 기록으로 남았습니다.

“AI 슬롭"이라는 이름의 부채

JFrog를 비롯한 보안 벤더는 이 현상을 AI 슬롭(AI slop)이라고 부릅니다. 대충 만들어 대량으로 뿌리는 AI 생성물이라는 뜻입니다.

취약점 보고에서 이게 유독 악질인 건 검증 비용의 비대칭 때문입니다. AI로 그럴듯한 취약점 보고서를 만드는 데는 몇 분이면 됩니다. 가짜라는 걸 증명하는 쪽은 사정이 다릅니다. 사람 엔지니어가 코드를 읽고 재현을 시도한 다음, 왜 트리거되지 않는지까지 논증해야 합니다. 몇 시간, 길면 며칠입니다.

curl의 다니엘 스텐베르그가 이미 비슷한 하소연을 했습니다. 버그 바운티로 들어오는 AI 생성 리포트를 걸러내느라 실제 취약점 대응 시간이 잠식된다는 겁니다. 오픈소스 메인테이너 대부분은 무급 자원봉사자입니다. 이들에게 “가짜를 반박할 의무"가 계속 쌓입니다.

왜 걸러지지 않았나

CVE 시스템은 미국의 MITRE가 총괄하고, 수백 개의 CNA(CVE 번호 발급 기관)가 분산해서 번호를 찍습니다. NVD는 여기에 심각도 점수와 메타데이터를 붙입니다.

이 구조는 인터넷 초창기에 설계됐습니다. 취약점 보고에는 비용이 든다는 전제를 깔고 있었습니다. 실력 있는 사람이 시간을 들여 분석해야 나오는 결과물이니, 접수된 보고는 일단 성의 있는 것으로 치고 보는 게 합리적이었습니다.

LLM이 그 전제를 무너뜨렸습니다. 이제 취약점 보고서 생산 비용은 사실상 0에 수렴합니다. NVD는 2024년부터 이미 처리 적체에 시달려 왔습니다. 인력과 예산은 그대로인데 접수량만 폭증했습니다. 정교하게 위장한 가짜를 걸러낼 여력이 있을 리 없습니다.

오염된 데이터베이스가 만드는 연쇄 피해

가짜 CVE 하나가 만드는 파장은 생각보다 큽니다.

첫째, 스캐너가 오탐을 뿜습니다. 사내 보안 도구가 “치명적 취약점 발견"이라고 알람을 울립니다. 팀이 달려듭니다. 며칠 태우고 나서야 애초에 존재하지 않는 버그였다는 걸 압니다.

둘째, 컴플라이언스가 얽힙니다. 요즘은 SBOM(소프트웨어 자재명세서) 제출이 계약 조건인 곳이 많습니다. 명세서에 미해결 Critical CVE가 하나라도 있으면 납품이 막힙니다. 존재하지 않는 취약점 때문에 계약이 지연되는 일이 실제로 벌어집니다.

셋째가 제일 위험합니다. 경보 피로가 쌓입니다. 가짜 알람이 반복되면 사람은 알람 자체를 무시하기 시작합니다. 진짜가 섞여 들어오는 순간이 문제입니다.

넷째, 이 데이터가 다음 세대 AI의 학습 데이터로 들어갑니다. 오염된 기록으로 학습한 모델이 다시 오염된 보고서를 생산합니다. 그렇게 한 바퀴가 돕니다.

그래서 무엇을 봐야 하나

당장 개인이 할 수 있는 일은 제한적입니다. 다만 전제 하나는 바꿔둘 만합니다. CVE 번호가 붙었다는 사실이 곧 검증됐다는 뜻은 아닙니다.

실무에서는 Critical 등급이 떴다고 바로 움직이지 않는 곳이 늘었습니다. 먼저 업스트림 프로젝트의 공식 입장을 확인합니다. SQLite처럼 관리가 촘촘한 프로젝트는 대개 메일링 리스트나 커밋 로그에 흔적이 남습니다. 흔적이 없으면 일단 의심합니다.

구조적 해법도 논의됩니다. 보고자 신원을 더 확인하자, 재현되는 PoC(개념 증명 코드)를 반드시 붙이게 하자, 채번 기관도 감사를 받게 하자. 다만 어느 것도 무료가 아닙니다. 진입 장벽을 높이면 선의의 독립 연구자도 함께 막힙니다.

마무리

이번 일은 SQLite에 버그가 있느냐 없느냐의 문제가 아닙니다. 사실을 기록하는 시스템 자체가 사실이 아닌 것을 흡수하기 시작했습니다. CVE 데이터베이스는 보안 업계가 30년 가까이 신뢰의 기준점으로 삼아온 곳입니다. 그 기준점이 흔들리면 그 위에 세워진 모든 자동화가 함께 흔들립니다.

AI가 생산량을 이렇게 늘려놓으면 검증 비용은 누가 냅니까. 지금까지는 대부분 무급 오픈소스 메인테이너들이 떠안아 왔습니다. 그 방식이 얼마나 더 버틸지는 모르겠습니다. 다만 지금 구조라면 버티는 쪽이 먼저 지칩니다.