가짜 CVE, AI 생성 보고서와 검증의 필요성

그럴듯한 취약점 보고서를 만드는 비용이 낮아지면서 소프트웨어 유지보수 담당자와 보안팀에 미치는 여파도 커지고 있다. 2026년 7월 SQLite을 대상으로 공통 취약점 및 노출(CVE) 6건이 공개됐고, 그중 2건은 심각도 점수 9.8을 받았다. 보고서는 메모리 안전성 관련 버그를 설명하고 기술적 해설과 개념 증명 코드를 포함해 그럴듯해 보였다.

하지만 JFrog 연구진은 보고서에서 언급한 함수 중 일부가 영향을 받는 버전에 존재하지 않는다는 사실을 밝혀냈다. 게다가 개념 증명(PoC) 중 주장된 취약점을 재현한 것은 하나도 없었다. 현재 SQLite의 CVE 페이지에는 이 6건의 보고서가 버그가 아니라고 나와 있으며, 이후 해당 CVE 기록은 거부됐다.

문제는 SQLite에만 국한되지 않는다. curl을 유지보수하는 개발자인 Daniel Stenberg는 지난해 접수된 보안 보고서 중 약 20%가 AI가 만들어낸 저품질 결과물이라고 추정했다. GitHub의 CVE 번호 부여 기관(CNA)은 2026년 5월 CVE 요청을 거의 4,000건 접수했다. 이는 전년 대비 약 10배 증가한 수치다. GitHub는 이러한 증가의 원인을 AI 탓으로 돌리지 않았고 제출물의 품질이 저하됐다고 언급하지도 않았지만, 엄청난 물량 증가는 취약점 공개 절차가 감당하기 어려운 상황임을 보여준다.

AI 덕분에 상세한 취약점 주장을 만들어내기는 쉬워지고 있지만, 그 주장이 타당한지 확인하는 데는 시간이 많이 든다. 또한 CVE가 보안 피드와 공개 데이터베이스에 올라가고 나면 원본 기록을 수정해도 모든 사본이 자동으로 수정되는 것은 아니다. 이에 따라 보고된 취약점과 기술적으로 검증된 취약점을 구분해야 할 필요성이 커지고 있다.

‘가짜’ CVE란 무엇인가?

사람들은 잘못 보고됐을 가능성이 높은 CVE를 가리킬 때 흔히 ‘가짜 CVE’라는 표현을 쓴다. 하지만 가짜라고 해서 의도적으로 오도하려는 것은 아니다. 정적 분석이 유효성 검사 절차를 놓치거나 입력값을 공격자가 제어할 수 있는 것으로 잘못 해석해 문제가 생길 수도 있다. 보고서가 실제 함수를 상세히 설명하면서도 유효하지 않은 공격 경로를 주장할 수 있다. 실제로 취약점이 아닌 조건이 보고된 경우에도 식별자(CVE ID)가 부여됐다가 나중에 취소될 수 있다. 이는 의도적으로 꾸며낸 보고서와는 다르다.

이견이 있다고 해서 가짜 CVE인 것도 아니다. 공급업체는 연구자가 제시한 악용 가능성, 위협 경계 또는 함수가 신뢰할 수 없는 입력을 처리하도록 설계됐는지에 관한 조사 결과에 이의를 제기할 수 있다. 하지만 이의 제기만으로 연구자가 잘못했다는 사실이 입증되는 것은 아니다. CVE가 거부됐다고 해서 반드시 조작된 것이라는 뜻도 아니다. 중복이거나 행정상의 이유로 거부될 수 있다. CVE 식별자 자체가 독립적인 기술 검증을 의미하지는 않지만, 업계는 실제 보고를 진지하게 받아들여야 한다.

가짜 CVE가 문제가 되는 이유

최근 나타나는 문제 중 하나는 사람들이 조사 결과를 제대로 검증하지 않은 채 AI를 이용해 취약점 보고서를 작성한다는 것이다. 이러한 보고서에는 상세한 기술 설명과 코드 참조, 심지어 PoC까지 포함될 수 있어 그럴듯해 보일 수 있다. 하지만 SQLite CVE 사례에서 보았듯이, 언급된 함수 중 일부는 영향을 받는 버전에 존재하지도 않았다.

GitHub는 2026년에 취약점 제출이 크게 늘었다고 밝혔지만, 그 증가를 AI 탓으로 돌리거나 제출물의 품질이 저하됐다고 보고하지는 않았다. 우려되는 점은 보고서 수가 늘어날수록 조사에 필요한 업무량도 증가한다는 것이다. 조사 결과가 실제인지 여부와는 관계없이 그렇다.

취약점 보고서를 분류해 본 사람이라면 실무적인 어려움을 쉽게 알아차릴 수 있다. AI 모델은 의심스러운 API 호출을 찾아내고, 대략적인 공격 시나리오를 짜고, 전문적으로 보이는 보고서를 빠르게 작성할 수 있다. 그 시나리오가 실제로 성립하는지 판단하려면 정확한 릴리스를 확인하고, 제어 흐름을 추적하고, 데이터가 함수에 어떻게 전달되는지 파악하고, 테스트 환경을 구축한 뒤, 주장된 공격을 실행해야 할 수도 있다. 보고서가 정확하든 아니든 같은 절차를 거쳐야 하며, 이 과정에는 상당한 비용이 들 수 있다.

가짜 CVE는 평판에도 피해를 줄 수 있다. 취약점 발표는 스캐너 피드와 보안 데이터베이스, 검색 결과에 빠르게 퍼질 수 있다. 하지만 뒤이은 정정은 그만큼 널리 퍼지지 않을 수 있다. 보고서가 이의 제기나 거부를 받은 뒤에도 공급업체는 최초 보고서를 본 고객에게 해명해야 하는 입장에 놓일 수 있다.

팀이 잘못된 보고서를 조사하느라 시간을 쓰면 실제 취약점을 놓치거나 조사가 늦어질 위험도 있다. 유지보수 담당자와 보안팀의 자원이 한정돼 있을 때 오탐을 반박하는 데 쓰는 시간은 실제 보안 문제를 조사하는 데 쓸 수 있었던 시간이다.

자동화로 대응하기

많은 조사 담당자가 새롭게 쏟아지는 보고서를 처리하기 위해 여전히 수동으로 분류하고 있지만, 이런 방식은 지속 가능하지 않다. 자동화는 취약점 주장을 실제 영향을 받는 릴리스 및 구성과 대조해 검증하는 데 큰 도움이 되고 있다. 확인할 질문은 다음 다섯 가지다.

• 구성과 권한을 비롯한 공격 전제 조건은 타당한가?
• 주장된 함수가 영향을 받는 버전에 존재하는가?
• 공격자가 취약한 코드에 도달할 수 있는가? 관련 코드가 영향을 받는 조건에서 실행될 수 있는지, 그리고 공격자가 해당 코드에 도달하는 입력을 제공할 수 있는지 판단해야 한다.
• 테스터가 통제된 테스트 환경이나 PoC를 통해 해당 동작을 재현할 수 있는가?
• 관찰된 동작이 보안 권고문에 기술된 보안 영향을 실제로 나타내는가?

에이전트형 도구는 테스트 환경을 만들고, 코드 경로를 분석하고, PoC를 생성하며, 검토를 위해 실행 증거를 기록할 수 있다. 하지만 모든 주장의 진위를 자동으로 판별할 수 있는 것은 아니다. 취약점이 실제로 존재하더라도 환경이 불완전하거나 트리거가 잘못되면 PoC가 실패할 수 있다. 테스터는 주장된 악용 가능성을 입증하지 못한 채 충돌만 재현할 수도 있다. 이러한 점 때문에 인간의 판단이 여전히 중요하다. 하지만 이러한 도구를 활용하면 보고서 하나가 엔지니어링, 취약점 관리, 고객 지원 전반의 시간을 더 많이 잡아먹기 전에 팀이 재현 가능한 답에 한층 가까이 다가갈 수 있다.

CVE 생태계의 과부하 극복하기

간결한 정책 하나로 허위 CVE 문제를 마법처럼 해결할 수는 없다. 하지만 제출 시 더 강력한 증거를 요구하고 재현 상태를 더 명확히 표시하면 도움이 될 것이다. 이견이 있는 기록을 더 명확하게 처리하고 후속 데이터의 오류를 더 신속히 바로잡는 것도 도움이 된다. 연구자들이 AI를 활용해 도출한 결과를 제출 전에 검증하도록 장려해야 한다.

보안팀과 공급업체는 증거를 검토하는 데 주력해야 한다. CVE 심각도 점수가 높더라도 해당 환경에서 취약한 경로에 접근할 수 있는지는 알 수 없다. PoC가 실패했다고 해서 모든 것이 안전하다는 뜻은 아니다. 또한 CVE ID를 받았다고 해서 문제를 이해하는 데 필요한 기술적 작업을 팀이 수행하지 않아도 되는 것은 아니다.

AI는 취약점을 발견하는 역량을 높이는 동시에, 그럴듯해 보이지만 틀린 주장을 만들어 내는 일도 가능하게 한다. 보고서가 급증하는 상황에서 조직은 검증에 투자해야 한다. 검증에는 테스트를 만들고, 결과를 재현하고, 가정을 점검하며, 증거를 더 쉽게 평가할 수 있도록 하는 일이 포함된다. 에이전트형 보안 테스트가 중요한 역할을 할 수 있는 분야다.