세계에서 가장 단단한 코드에 뜬 '치명적 취약점'
SQLite라는 이름, 한 번쯤 들어보셨을 거예요. 여러분의 스마트폰, 웹 브라우저, 심지어 비행기 소프트웨어에까지 들어가 있는 초소형 데이터베이스거든요. 서버를 따로 띄우는 MySQL 같은 DB와 달리 파일 하나로 동작하는 임베디드 DB라서, 세상에서 가장 널리 배포된 소프트웨어 중 하나로 꼽혀요. 그런데 이 SQLite에 '치명적(Critical)' 등급의 보안 취약점 번호, 그러니까 CVE가 발급되는 일이 벌어졌어요. 보안 담당자라면 심장이 철렁할 소식이죠.
그런데 보안 연구 기업 JFrog가 이 CVE를 파고들어 보니 황당한 결론이 나왔어요. 해당 취약점이 실제 코드에는 존재하지 않는, LLM이 그럴듯하게 지어낸 내용이었다는 거예요. 보고서의 함수 이름과 공격 시나리오는 그럴싸한데, 정작 SQLite 소스 코드를 열어보면 재현 자체가 불가능한 이야기였던 거죠.
CVE가 뭐길래 이게 큰일이냐면
CVE는 쉽게 말해 '취약점마다 붙는 주민등록번호' 같은 거예요. 전 세계 보안 도구와 보안팀이 이 번호를 기준으로 소통하죠. CNA라고 부르는 발급 기관들이 번호를 부여하는데, 문제는 이 과정에서 취약점이 진짜인지 코드 수준까지 검증하는 절차가 생각보다 허술하다는 점이에요. 신고 내용이 형식만 갖추면 번호가 나오는 경우가 있거든요.
여기에 LLM이 기름을 부었어요. 그럴듯한 취약점 보고서를 몇 초 만에 대량으로 찍어낼 수 있게 됐으니까요. 실제로 curl 프로젝트의 메인테이너 Daniel Stenberg는 AI가 만들어낸 가짜 취약점 신고가 버그바운티(취약점을 찾아주면 포상금을 주는 제도)에 쏟아져서 검토하느라 시간을 다 뺏긴다고 공개적으로 호소한 적이 있어요. SQLite 개발팀도 오래전부터 검증 없이 발급되는 엉터리 CVE 문제를 지적해 왔고요. 아이러니한 건, SQLite는 테스트 코드가 본체 코드보다 수백 배 많고 100% 브랜치 커버리지를 유지하는, 세계에서 가장 철저하게 테스트되는 코드베이스 중 하나라는 점이에요. 그런 프로젝트조차 가짜 CVE 앞에서는 속수무책이었던 거죠.
가짜 CVE 하나가 일으키는 나비효과
'가짜면 무시하면 되지 않나?' 싶을 수 있는데, 현실은 그렇지 않아요. 요즘 개발 파이프라인에는 Dependabot, Trivy, Snyk 같은 의존성 스캐너가 깔려 있잖아요. 이 도구들은 CVE 데이터베이스를 기준으로 경보를 울려요. 치명적 등급의 SQLite CVE가 등록되는 순간, SQLite를 쓰는 전 세계 수많은 프로젝트의 CI가 빨간불을 켜고, 보안팀은 패치 여부를 확인하느라 야근을 하게 되는 거예요. 존재하지도 않는 취약점 때문에요. 더 무서운 건 '양치기 소년' 효과예요. 가짜 경보가 반복되면 조직 전체가 경보에 무감각해져서, 진짜 치명적 취약점이 나왔을 때 대응이 늦어질 수 있거든요.
우리는 어떻게 대응해야 할까
실무적으로 챙길 포인트는 이래요. 첫째, 스캐너가 경보를 울리면 CVE 번호와 점수만 보고 움직이지 말고, 원문 어드바이저리와 해당 프로젝트의 공식 채널을 먼저 확인하세요. 프로젝트 측이 이의를 제기한 'disputed' 상태인 경우도 있거든요. 둘째, 취약하다는 코드 경로를 우리 서비스가 실제로 쓰는지 따져보는 트리아지(우선순위 분류) 과정을 팀에 만들어두면 좋아요. 모든 경보에 똑같이 반응하면 정작 중요한 걸 놓치게 되니까요. 셋째, 취약점을 신고하는 입장이라면, LLM이 써준 보고서를 직접 재현해보지 않고 제출하는 건 생태계 전체에 민폐라는 걸 기억해야 하고요.
정리하면
AI가 보안 리서치를 돕는 시대에, 검증 없는 AI 산출물이 보안 인프라의 신뢰 자체를 흔들 수 있다는 걸 보여준 사건이에요. 여러분 팀은 CVE 경보가 울리면 어떤 절차로 진짜인지 확인하시나요? 트리아지 노하우가 있다면 댓글로 공유해 주세요.
🔗 출처: Hacker News