이런 방식은 신호 대 잡음비를 떨어뜨려 진짜 CVE를 가려내기 훨씬 어렵게 만듦
반면 LLM이 실제 CVE도 상당수 발견하고 있으며, 블랙햇이 이를 최대한 활용하고 있을 가능성이 높음

CVE 대다수는 실제로 악용할 수 없는 잡음에 가까움. LLM이 생성한 CVE도 대부분 링크된 글처럼 허위이거나 악용 불가능한 유형일 것으로 봄

어느 쪽이든 도메인 전문가가 LLM 사용을 주도해야 함. 제품 개발, 글쓰기, 이미지 등에서 반복해서 보듯 유능한 사람이 이끌지 않으면 잡음만 생김

기존 기술 기업 밖에서는 소프트웨어 보안이 허술한 경우가 많음. 오래된 소프트웨어의 기본 취약점이나 알려진 문제가 있는 낡은 패키지를 확인할 자원이 부족하고, 관리자가 특정 해법을 고집하거나 내부망의 유지보수 모드 서비스를 거의 점검하지 않기도 함
전체 소프트웨어 스택을 제대로 검사할 수 있더라도 쏟아지는 CVE를 모두 처리하기는 어려움. AI가 결국 소프트웨어를 과거보다 훨씬 안전하게 만드는 전환기에 있으며, 잡음 많은 CVE는 사람이 검토하기 전에 에이전트가 취약점을 검증하는 체계로 이어질 가능성이 큼
다만 에이전트 검토에는 LLM 사용 비용, 저장소에 즉시 적용하기 어려운 도메인·취약점 지식, Anthropic 같은 제공자의 방어 목적 사용 제한 문제가 있음. AI 제공자가 선의와 악의를 어떻게 구분할지, 오픈소스 모델이 따라잡으면 그 구분이 의미가 있을지도 불분명함. 원하든 원하지 않든 사이버 군비 경쟁에 들어선 셈임

제출 내용을 검증하지 않으면 시스템 전체를 끝없는 허위 보고로 범람시키는 대규모 공격 경로가 되어 신뢰성이 크게 떨어짐

그래서 많은 대형 프로젝트가 CNA로 전환해, 아무나 검토·검증되지 않은 CVE를 할당받지 못하게 하고 있음
Red Hat은 최후 수단 CNA인 듯하므로 직접 CNA가 되지 않고도 프로젝트를 Red Hat 관할에 넣어 처리할 가능성이 있음

이를 계기로 업계가 CVE보다 나은 체계를 설계하라는 압박을 받길 바람. LLM 이전부터 신호 대 잡음비가 형편없었으므로 10년 뒤에도 CVE가 유의미한 체계로 남을 것 같지 않음
다만 현 체제에서 이익을 얻는 수많은 중간업자를 생각하면 낙관하기 어려움

어떤 조직이 그런 정책을 두는지 궁금함. 상당한 자기기만을 하거나 오픈소스 사용을 전면 금지하지 않는 이상, 규모와 관계없이 실행 가능한 정책으로 보이지 않음

공격적으로 악용하면 끔찍할 수 있음. 사람이 보기 전에 에이전트가 문제를 재현하게 하는 것이 최선의 방어책 같지만, 그것조차 비용이 듦

실제 업무에서도 보안 담당자들이 완전히 지쳐 있음. 허위 보고를 진지하게 받아 잠시 조사하고, 근거를 붙여 DNF를 작성하고, 기록을 갱신한 뒤 검사 결과에서 사라지길 기다리는 데 시간을 낭비함
결국 무언가 바뀔 수밖에 없으며, 낙관적으로 누구나 등록하게 두는 방식은 폐지될 것으로 봄

환각으로 만든 CVE를 패치하는 절차는 다음과 같음 git stash -m "sigh" git commit --allow-empty -m "Patch: CVE-2026-51302" git stash pop

LLM이 실제로 할 수 있는 일보다 사람들이 기대하는 능력이 훨씬 큰 과도한 열광의 또 다른 사례임
LLM 기반 AI는 방대한 입력 말뭉치에서 주어진 상황에 통계적으로 가장 가능성 높은 출력을 계산하는 확률적 시스템임. 확률이 아니라 확실성이 필요한 보안 분야에서 틀리면 신뢰를 크게 잃으며, 이번에는 코드 주석을 취약점을 만드는 코드로 잘못 판단했음
LLM은 텍스트 예측 엔진이지 지능을 가진 인공지능이 아니므로 그렇게 취급해서는 안 됨. 이를 이용해 취약점을 생성한 이들은 도구의 특성상 이런 일이 생길 것을 알았거나 알았어야 함
그 결과를 처리하는 팀들이 수십만~수백만 달러 규모의 생산성 손실을 떠안게 됨

인용된 코드가 해당 버전에 존재하지 않거나 무관한 로직을 가리키고, PoC도 충돌을 일으키지 않았다면 이런 검사를 자동화해 즉시 거부해야 함

좋은 생각임. LLM에게 검사를 맡기면 “재현했다”고 답했다가 정말 실행했냐고 물으면 실행하지 않았다고 사과하고, 잠시 뒤 이번에는 확실히 실행해 재현했다고 다시 주장할 것임

CVE 자체가 대부분 터무니없어 보이므로 이런 PoC 실행은 매우 조심해야 함. 실제 버그 보고가 아니라 PoC 실행 자체를 노린 공격일 가능성도 있으나 코드를 깊이 살펴보지는 않았음
한 저장소에서 schreibfaul1 ESP32-audioI2S와 SQLite의 CVE를 섞어 관리하는 이유도 의문이며, 서로 다른 제품의 CVE를 한 저장소에 모으는 것이 일반적인 관행인지 궁금함

이 사건이 자동화된 취약점 수집의 구조적 문제를 보여준다고 하지만, 정작 이들은 취약점을 자동 색인하고 의존성을 CVE와 연결하는 X-Ray를 만들고 있음

비전문가 관점에서는 시스템에 확률적 불확실성을 더 끌어들인 느낌임. 예전에는 주로 사람의 실수나 오해를 처리하면 됐지만, 이제는 압축된 인간 전문성과 함께 균질화된 결함까지 상대해야 함

존재하지도 않는 취약점에 치명적 등급이 붙는 것은 황당하며, 분류·검토 비용은 여전히 유지보수자가 부담함