Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 CVE 공개 건수 추이를 분석하며, 자동화 증가로 취약점 보고가 급증했음을 지적합니다. 현재의 CVSS 점수 체계는 소프트웨어 개발 현실과 괴리되어 있으며, SBOM이나 EU CRA와 같은 국제적인 표준 기반 접근 방식이 필요하다고 주장합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이런 지표를 해석할 때 까다로운 점은 GitHub와 Linux 커널이 2024년 중반과 2025년 중반 무렵 자체 CVE 발급 기관(CNA) 이 됐다는 것임. 자동화가 늘고 CVE 등록 장벽도 낮아짐.
다운로드 2만 건이 넘는 내 Obsidian 플러그인도 베타 버전의 잘못된 경로 정규식 때문에 CVE를 받았는데, 2년 전이라면 이런 일은 없었을 것 같음. 2025년 이후에는 CVE 발급 문턱이 훨씬 낮아졌다고 느낌. 1, 2.
심각도 필터가 없어서 증가 추세가 과장된 건 아닌지 의심했는데, 치명적 취약점만 필터링한 결과를 발견함.
전체 CVE가 2020년 대비 약 5배인 데 비해, 치명적 CVE는 약 25배로 증가세가 오히려 더 가파름.
심각도는 그대로 비교할 수 없음. CVSS 문서는 ‘취약한 구성 요소’를 무엇으로 정할지 독자에게 맡기고, 그 선택은 점수에도 기록되지 않음.
따라서 같은 치명적 등급이라도 가상의 부실한 프로그램을 전제로 평가한 라이브러리일 수도 있고, 알려진 완화 조치가 있는 특정 웹사이트를 평가한 결과일 수도 있음.
이 피드백을 바탕으로 사이트에 추가 기능을 넣어 보겠음.
DOGE가 사이버보안 기관들을 대폭 축소했는데도 지난 2년간 CVE 발급 건수가 급증했다는 점은 놀라움. 안타깝게도 그동안 처리 대기 건수가 얼마나 쌓였는지는 알 수 없음. 관련 기사.
DOGE의 행태는 노골적으로 범죄적이었음. CVE 보고 체계 자체를 없애려 했고, 군과 여러 기관의 개입 때문에 실패했을 뿐임.
그 기관들이 취약점을 찾는 연구도 직접 하는 건가? 아니면 대부분 캐시 가능한 웹사이트를 운영하며 제보된 내용을 게시하는 역할인가?
로그 척도로 보면 해석하기 더 쉬울 것 같음. 옵션은 있지만 클릭해도 그래프가 바뀌지 않고 사이트가 멈춤.
수정하겠음. 원래 쓰던 사이트가 P2PShell 때문에 다운돼서 바이브 코딩으로 만든 개인 사이트가 크게 퍼지다니 아이러니함. 관련 게시물.
AI가 만든 코드에서 보안 취약점이 쏟아질 줄 알았는데, 정작 AI가 수십 년간 사람이 작성한 코드의 취약점을 찾아내고 있음.
둘은 동시에 일어날 수 있음. 정보기관들이 특정 인물이나 국가를 대상으로 AI 생성 코드의 출력을 조작해 왔다는 사실까지 드러날지 두고 볼 일임.
그 인간 작성 코드가 바로 AI의 학습 자료이기도 함.
사이트는 흥미롭지만, 곁가지로 CVE/CVSS 체계는 이미 수년 전부터 소프트웨어 개발 현실과 동떨어진 낡은 체계라고 봄. 대형 소프트웨어 공급업체들은 오래전부터 릴리스 기록과 보안 취약점 정보를 직접 통제하려 했고, 최근 NIST는 CVE 분석도 중단함.
이제 이 체계는 취약점 데이터베이스와 책임 있는 공개 절차라는 맥락에서만 의미가 있음. 책임 있는 공개는 발견부터 배포까지 몇 주가 아니라 몇 달이 걸리고, 다른 사람이 같은 취약점을 우연히 찾을 가능성도 낮았던 AI 이전 시대에 만들어짐.
2025년 4월 MITRE가 CVE/CWE 프로그램의 자금 지원 만료를 알린 뒤 Trump 행정부가 이를 번복하기까지 며칠이 걸림. 필요한 것은 미국 국내 정치에 휘둘리지 않는 국제적 체계임. 미국의 프로그램과 자금 자체를 탓할 일은 아니지만, 공동으로 더 견고하고 현대적인 기반을 마련해야 함. SBOM과 의무 보고를 포함하는 EU CRA는 좋은 출발점임.
CVE·CVSS·CPE는 모두 위원회식 설계의 산물처럼 보이며, 특히 CVSS와 CPE가 심함. 자기 소프트웨어에 CPE 버전 체계를 적용해 보면 알 수 있음. 대안도 있는 것으로 알지만 아직 주류는 아님.
이 체계가 낡지 않았다고 할 사이버보안 전문가는 없을 것 같음. 이미 자리 잡았고 새 체계를 만들기 어려워서 계속 쓰는 것임. 점수 자체를 없애는 편이 낫다고 봄. 원격 코드 실행인지, 로컬 공격인지, 단순 정보 유출인지 같은 세부 정보를 주면 그에 따라 위험을 관리할 수 있음.
보편적인 점수는 그럴듯하지만 실무에서는 완전히 어긋남. 내용을 이해하지 못하는 경영진이 엑셀 표를 온통 초록색으로 만들려 할 때 가장 큰 피해가 생김.
기억하기로 CVE 식별자의 원래 목적은 순수한 식별이었음. IP 주소처럼 묶음 단위로 할당되며, 번호를 부여했다는 사실만으로 대상에 관해 무엇을 말해 주지는 않음. 정부 데이터베이스는 그보다 조금 뒤에 생김.
업무상 이유가 있어도 소프트웨어 업데이트 요청을 거절당하자, 직원들이 자신들이 쓰는 구성 요소에 CVE를 등록해 강제로 업그레이드하게 했다는 글을 본 적이 있음. 그러니 건수 자체는 의미가 없음.
Linux 커널도 취약점으로 볼 여지가 있는 거의 모든 것에 CVE를 부여함. 커널이 시스템에서 차지하는 위치상 거의 모든 버그가 보안 침해에 악용될 수 있지만, 수정 시점에는 악용 가능성이 명확하지 않은 경우가 많다고 함. 그래서 발급팀은 보수적으로 접근해 식별한 모든 버그 수정에 CVE 번호를 부여하며, 이것이 커널 CVE가 유독 많은 이유라고 밝힘.
달리 말하면 이 숫자는 허상임.