리눅스 커널이 이틀 만에 432개의 CVE 공개: 이것이 커널 보안에 대해 시사하는 바

사이버 보안 Jul 23, 2026북마크에 추가

리눅스 커널이 이틀 만에 432개의 CVE 공개: 이것이 커널 보안에 대해 시사하는 바
삽화 : Momiji Shirogane

리눅스 커널 보안 팀이 48시간 만에 432개의 CVE를 공개했습니다. 놀라운 수치이지만, 이 숫자를 올바르게 이해해야 합니다. 이는 2024년 채택된 CNA 정책의 직접적인 결과입니다.

사실

리눅스 커널 보안 팀이틀 만에 432개의 CVE를 발표했습니다. 이 숫자 자체는 부인할 수 없지만, 그 해석에는 맥락이 필요합니다.

2024년 2월 이후 리눅스 프로젝트는 MITRE의 CVE 번호 부여 기관(CNA)이 되었습니다. 이는 커널 팀이 자체적으로 보안 패치에 CVE 식별자를 부여할 수 있음을 의미하며, 제3자 기관을 거칠 필요가 없습니다. 그 결과 CVE 발표 빈도가 급증한 것입니다. 이는 커널이 갑자기 더 불안전해진 것이 아니라, 보안에 영향을 미칠 수 있는 모든 패치에 기본적으로 CVE가 부여되기 때문입니다.

누가 영향을 받나요? (이 숫자를 어떻게 읽어야 할까요)

이 CVE 대량 발생을 세 가지 범주로 나눌 수 있습니다:

  1. 원격 또는 LPE(로컬 권한 상승) 공격이 가능한 실제 취약성 - 즉각적인 패치가 필요한 경우입니다. 이 범주는 전체에서 소수에 불과합니다.
  2. 희귀한 하위 시스템의 이론적 취약성 - 거의 컴파일되지 않는 드라이버, 잘 배포되지 않는 아키텍처(예: SH, PA-RISC, IA-64) 코드 등입니다. 이론적으로는 유효한 CVE이지만, 99%의 설치 환경에서는 실질적인 영향이 거의 없습니다.
  3. 예방적 패치 - 트리거하기 어려운 경쟁 조건, use-after-free, 사소한 정보 유출 등입니다. 수정해야 하지만 긴급한 수준은 아닙니다.

커널의 CNA 정책(그렉 크로아-하트만(Greg Kroah-Hartman)이 지지)은 명확합니다: 보안에 영향을 미치는 모든 패치에는 CVE가 부여되며, 어떤 것이 중요한지는 사용자(배포판, 기업)가 판단해야 합니다. 이는 "이미 악용된 경우에만 CVE를 부여하던" 과거 모델과 비교해 더 투명하지만, 이러한 숫자 급등을 초래합니다.

떠오르는 관점: AI가 지원하는 버그 리포트?

사건을 다룬 The Register의 헤드라인 하단에는 "AI가 지원하는 버그 리포트가 이 급증을 부채질하고 있다"는 추측이 명시되어 있습니다. 커널 메일링리스트에서는 몇 달 전부터 이런 아이디어가 circulating되고 있습니다: 지능형 퍼징(fuzzing)과 LLM 기반 정적 분석 도구의 보편화로 버그 리포트가 급증하고 있으며, 이 중 일부(실제 양성)는 패치로 이어지고, CNA 정책에 따라 CVE로 전환됩니다.

현재로서는 커널 팀 측에서 공식적으로 확인된 바 없습니다. CNA 정책의 확장이 이 숫자를 충분히 설명할 수 있으며, AI 요인을 들먹일 필요는 없습니다. 그러나 한 가지 생각해 볼 문제입니다: 만약 CVE의 상당 부분이 AI 도구에 의해 생성된다면, 이 보고서는 어떻게 처리해야 할까요?(전용 채널, CVE 부여 전 필수 인적 검토, 설명에 명시적 마킹 등) 이 논쟁은 아직 해결되지 않았습니다.

지금 해야 할 일

지금 해야 할 일

1. raw 숫자에 당황하지 마세요: 432개의 CVE ≠ 재설치해야 할 432대의 시스템. 2. **여러분의 배포판의 advisories를 따르세요** (Debian DSA, Ubuntu USN, Red Hat RHSA) - 이들은 이미 필터링을 해줍니다. 3. 일반 데스크톱 사용자: 주간 자동 업데이트로 충분합니다. 4. 중요 시스템 fleet: 한 번에 모두 수정하려고 하지 말고, OpenSCAP, kernel-live-patching 등 기존 도구를 사용해 CVE별로 평가하세요.

분석

이 문제는 오픈 소스 보안의 오랜 논쟁입니다: 취약성 공개에 어떤 수준의 세밀함을 적용해야 할까요?

구 모델("악용된 경우에만 공개")은 가시성을 높이는 장점이 있었지만, 인공적으로 CVE 노이즈 수준을 낮추는 단점이 있었습니다. 기업들은 커널이 "깨끗하다"고 믿었지만, 실제로는 매달 수십 개의 보안 버그가 незаметно 존재했습니다.

새로운 모델(CNA 확대)은 현실을Visible하게 만들지만, 대부분의 팀에게는 raw 데이터가 쓸모없습니다. 중재는 최종 사용자가 아닌 배포판과 패치 관리 도구가 담당해야 합니다.

참조할 만한 현실적인 수치: 리눅스 커널은 안정 브랜치에서 매달 약 1,800~2,500개의 버그를 수정합니다. 그 중 보안 관련 비율은 구조적으로 상당합니다(3,000만 줄 이상의 C 코드, 그 중 상당 부분은 잘 감사되지 않은 드라이버 코드). CVE 공개가 이 현실을 반영하는 것은 건전하지만, "화재가 난 것 같다"는 인상을 주는 것은 아닙니다.

기억해야 할 점

  • 이틀 만에 432개의 CVE = 커널의 CNA 정책의 결과, 보안 붕괴가 아닙니다.
  • AI가 지원하는 리포트라는 가설이 있지만, 아직 공식 확인되지 않았습니다.
  • raw 커널 플로우가 아닌 여러분의 배포판의 advisories를 따르세요.
Resources

인공지능이 작성하고 사람의 편집 감독하에 검수한 기사입니다.

편집팀
이 기사가 도움이 되었나요?

25 명이 이 기사를 좋아합니다

좋아요
K
Kenji AraiCybersecurity expert
Cybersecurity expert, methodical watcher, never alarmist, always actionable.
공유:
LIVERadio Geek Kitsune
눌러서 청취, 모두에게 같은 소리
0··
// 편성표
// all stations
// 트랙 공유 →
토픽
탐색
정보