CVE 트래커

CVE Tracker

cve.0xosprey.com ▲ 174 댓글 67 Group_B

요약

공개된 CVE를 날마다 다시 세는 사이트로, 올해 발표 건수가 벌써 지난해의 1.8배입니다.

0xOsprey라는 이용자가 만든 개인 사이트입니다. CVE(공개된 보안 취약점마다 붙는 고유 번호)의 공식 목록인 CVEProject/cvelistV5 저장소를 매일 받아 발표 건수를 다시 집계합니다.

왜 중요한가

  • 취약점 발표가 얼마나 빨리 늘고 있는지 공식 원자료로 날짜 단위까지 확인할 수 있습니다.
  • 월별 건수가 올해 1월 4,302건에서 9월 1만 4,934건으로 세 배 넘게 늘었습니다. 증가 속도 자체가 빨라지고 있다는 뜻입니다.

핵심 내용

  • 10월 24일 기준 누적 건수는 395,222건이고, 올해 전체는 약 10만 4천 건으로 예상했습니다.
  • 연간 발표 건수는 2020년 1만 8,363건, 2025년 4만 8,151건이었고 올해는 10월까지 8만 6,344건입니다.
  • 이번 달은 24일까지 1만 3,542건이 나왔고, 월말 예상치는 약 1만 6,808건입니다.
  • 예측치는 지난 12개월 동안 같은 날짜까지 한 달 치의 몇 할이 나왔는지 그 중앙값으로 계산합니다.
  • 일·주·월·연 단위와 누적 보기, 로그 스케일, 예약일(번호를 미리 받아 둔 날) 기준 보기를 고를 수 있습니다.

HN 반응

  • 리눅스 커널과 GitHub가 직접 CVE를 발급하면서 문턱이 낮아져 숫자가 부풀었다는 지적과, AI가 오래된 코드의 취약점을 실제로 찾아낸 결과라는 해석이 갈렸습니다.
  • 심각 등급만 보면 2020년보다 약 25배 늘었다는 자료도 나왔지만, 등급을 매기는 기준이 제각각이라 비교하기 어렵다는 반박이 뒤따랐습니다.

댓글

30개 표시 · 전체 67개
  1. philips HN

    이런 지표에서 까다로운 점은 GitHub와 리눅스 커널이 각각 2024년 중반1과 2025년 중반2에 자체 CNA가 됐다는 사실이라고 생각합니다. 이 때문에 자동화가 많이 새로 생겼고, CVE를 실제로 등록하는 문턱도 낮아졌습니다.

    작은 사례를 하나 들자면, 저는 다운로드가 2만 회가 넘는 Obsidian 플러그인을 운영하는데, 베타 릴리스에서 경로 정규식이 잘못됐다는 이유로 CVE가 하나 발급됐습니다. 2년 전이었다면 절대 일어나지 않았을 일이라고 생각합니다.

    그래서 2025년 이후에는 CVE가 발급되는 기준이 예전보다 훨씬, 정말 훨씬 낮아졌다고 느낍니다.

  2. DeepYogurt HN

    GitHub는 적어도 2022년부터 CVE 요청을 처리해 왔습니다.

    https://github.blog/security/vulnerability-research/removing-the-stigma-of-a-cve/

  3. 0xOsprey HN

    좋은 지적이네요, 말씀해 주셔서 감사합니다. 지금 사이트를 손보고 있는데, 이 부분의 뉘앙스도 담아 보겠습니다.

  4. wild_pointer HN

    심각도가 높은 CVE만 따로 보면 그래프가 다를지 궁금하네요. 예를 들어 이런 것(https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/)은 빼고요.

  5. tomxor HN

    심각도 필터가 없어서 추세가 과장돼 보이는 게 아닌가 의심했습니다.

    그런데 이걸 찾았습니다.

    https://craci.com/resources/CVE-publication-trends?sev=critical

    치명적(critical) CVE의 추세는 오히려 더 나쁩니다. 2020년의 약 25배인데, 전체 CVE는 2020년의 약 5배입니다.

  6. DeepYogurt HN

    심각도는 서로 곧바로 비교할 수 있는 값이 아닙니다. CVSS 문서는 "취약한 구성 요소"를 무엇으로 잡을지를 읽는 사람에게 맡겨 놓았습니다. 게다가 어떤 구성 요소를 골랐는지는 점수에 담기지도 않습니다. 그래서 어떤 치명적 취약점은 이론상의(그리고 형편없는) 프로그램을 기준으로 점수를 매긴 라이브러리의 것일 수도 있고, 이미 완화책이 알려진 웹사이트 하나를 기준으로 매긴 것일 수도 있습니다.

  7. arbirk HN

    링크 감사합니다!

    1. Red Hat처럼 줄어드는 곳도 있는 것 같네요.
    2. 지금은 "지능형" 컴퓨팅, 휴리스틱 에이전트 알고리즘, 자금, 소프트웨어 취약점에 대한 관심이 전부 몰려 있으니 이런 양상은 예상할 만합니다. Glasswing, Daybreak, Fairwind, Purple 같은 프로젝트가 한창 진행 중이고 효과도 있어 보입니다.
  8. tetha HN

    그들은 심각도 높은 취약점을 찾아내거나, 찾은 취약점을 심각도 높게 발표할 동기도 있죠.

    결국 그 많은 하드웨어와 연구가 가장 치명적인 취약점 하나 못 찾아낸다면 무슨 가치가 있겠어요?

  9. mxey HN

    많은 CVE가 실제 내용에 비해 심각도가 너무 높게 매겨져 있습니다.

  10. danso HN

    DOGE가 사이버 보안 [0] 기관들을 그렇게 심하게 망가뜨려 놓고도 최근 2년간 발급된 CVE 수가 폭증했다니 놀랍습니다. 안타깝게도 그사이 밀린 작업이 얼마나 쌓였는지는 알 수 없습니다.

    [0] https://www.securityweek.com/mitre-signals-potential-cve-program-deterioration-as-us-gov-funding-expires/amp/

  11. SimianSci HN

    DOGE는 정말 대단히 범죄적이었어요. 그 팀은 CVE 보고 시스템을 아예 없애려고 했고, 군과 여러 기관이 개입해서 막지 않았다면 실제로 그렇게 됐을 겁니다.

  12. MetaWhirledPeas HN

    DOGE는 정말 대단히 범죄적이었어요. 그 팀은 CVE 보고 시스템을 없애려고 했고

    솔직히 궁금합니다. 그렇게 해서 얻는 범죄적 이득이 뭔가요?

  13. farnsworth HN

    "정부가 왜 이걸 해야 하나, 다른 누군가가 이걸로 돈을 벌 수도 있는데"라는 논리일 거라고 생각합니다.

  14. AnneTrotter HN

    그 논리에는 두 가지 문제가 있습니다.

    1. 지금은 정부가 이 일을 하고 있고, 이 일은 핵심적입니다. 대체할 것도 없이 시스템을 뜯어내면 재앙 같은 결과가 나오고, 그러면 수익도 줄어듭니다(몇 사람이 죽을 수도 있지만, 뭐 수익이 우선이니까요). 어쨌든 핵심 구성 요소를 넘기려면 계획을 세워서 해야 합니다.

    2. CVE 시스템은 전 세계 많은 주체에게 신뢰받아야 합니다. 정부는 역사적으로 특정 편을 들지 않았고 그런 신뢰를 얻어 왔습니다. 지금도 대체로 그렇습니다. 영리 기업 중에는 그만한 신뢰를 받는 곳이 없습니다. 영리 모델에서는 그 신뢰가 진정으로 보편적일 수 없으니까요.

  15. Vaushite HN

    고용주의 이익을 위해 정부를 방해하는 거죠.

  16. kridsdale1 HN

    세상이 불타는 걸 구경하려는 거죠.

  17. vasco HN

    그 기관들이 CVE를 찾으려고 연구를 하긴 하나요? 아니면 그냥 캐시하기 쉬운 웹사이트에 올라온 걸 게시하는 정도인가요?

  18. danso HN

    CVE 시스템은 완벽과는 거리가 멀고, NIST도 (2025년 이전부터) 밀린 작업을 분류하고 처리하는 능력에 대해 비판이 점점 커지고 있습니다. 그래도 그들의 역할이 들어온 것을 그냥 게시하는 데 그치지는 않는다고 생각합니다.

    https://www.securityweek.com/cve-and-nvd-a-weak-and-fractured-source-of-vulnerability-truth/

  19. vasco HN

    제 말은 그들이 CVE 수와는 아무 상관이 없다는 겁니다. 뭔가를 새로 밝혀내는 것도 아니고요.

  20. theteapot HN

    "그들"이 누구죠? cve.org는 CISA의 위탁을 받아 MITRE가 운영합니다.

  21. koolba HN

    하지만 거기서 조사하거나 검증하거나 PoC를 만들어 보는 건 없어요. 그냥 고유 ID를 발급하고 결국 텍스트 뭉치를 게시하는 중앙 창구일 뿐이에요.

  22. k2enemy HN

    멋지네요. 로그 스케일로 보면 해석하기가 더 쉬울 것 같습니다. 옵션은 있는데, 눌러도 차트가 바뀌지 않고 제 환경에서는 사이트가 멈춰 버립니다.

  23. 0xOsprey HN

    고치겠습니다. 알려 주셔서 감사합니다.

    제가 바이브 코딩으로 만든 개인 사이트가 화제가 된 이유가, 제가 예전에 쓰던 사이트가 P2PShell 때문에 다운돼서라는 게 아이러니하네요...

    https://x.com/0x_Osprey/status/2113152597767172346

  24. haaz HN

    저도요.

  25. braiamp HN

    어디선가 본 댓글이 기억납니다. 어떤 회사의 직원들이 업무에 쓰는 소프트웨어의 CVE를 일부러 등록해서 업그레이드를 강제했다는 얘기였습니다. 업무상 이유가 있는데도 일반적인 업데이트 요청이 계속 거절당했기 때문이죠. 그러니 숫자는 중요하지 않습니다.

    또 리눅스 커널은 취약점으로 볼 수 있는 건 뭐든 CVE를 부여합니다.

    시스템에서 리눅스 커널이 위치한 계층 때문에, 거의 모든 버그가 커널의 보안을 침해하는 데 악용될 수 있습니다. 하지만 버그를 고칠 때는 악용 가능성이 뚜렷이 드러나지 않는 경우가 많습니다. 그래서 CVE 배정 팀은 지나치다 싶을 만큼 신중을 기해, 자신들이 식별한 모든 버그 수정에 CVE 번호를 부여합니다. 리눅스 커널 팀이 발급하는 CVE가 겉보기에 이렇게 많은 이유가 여기에 있습니다.

    다시 말해 그 숫자는 가짜입니다.

  26. red75prime HN

    다시 말해 그 숫자는 가짜입니다.

    다시 말해 CVE를 부여하는 방식은 그대로인데 CVE 수가 급격히 늘었다는 거죠.

  27. braiamp HN

    그건 틀렸습니다. 커널은 예전에는 CVE를 거의 부여하지 않았고, 지금은 후하게 부여합니다. 그러니 방식이 바뀐 겁니다.

  28. philips HN

    맞습니다. 그리고 그 모든 게 2024년에 바뀌었으니 꽤 최근입니다: http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/

  29. dgacmu HN

    실제 숫자는 조심스럽게 해석해야 하지만, 변화 자체는 분명 실재합니다.

  30. xnx HN

    다른 사람들도 지적했듯이, 우리는 AI가 짠 코드에서 보안 취약점이 나올 거라고 생각했는데, 알고 보니 AI가 드러내고 있는 것은 수십 년 된 사람이 짠 코드의 취약점입니다.

Hacker News에서 보기 ↗