리눅스 커널 CVE, 과연 모든 시스템에 적용 가능할까?

리눅스 커널 보안팀의 CVE 할당 프로세스(CVE Assignment Process)와 CVE의 정의에 대한 설명이 주를 이룸

CVE의 무분별한 적용과 CVSS 점수의 맹점에 대한 비판이 제기됨

CVE의 적용 범위(Scope)에 대한 논의가 활발하게 진행됨

사용자 환경(User Environment)에 따른 CVE의 유효성 판단의 중요성이 강조됨

CVE 할당 기준과 실제 적용의 괴리

게시물에 따르면 리눅스 커널 CNA 팀은 취약점(Vulnerability)을 cve.org의 정의에 따라 판단하며, 사용자 시스템에 미치는 영향은 고려하지 않는다. 특히, `panic_on_warn` 옵션 활성화 시, `WARN_ON()` 발생을 해결하는 모든 커밋에 CVE가 할당된다. 하지만, 특정 하드웨어 드라이버(Hardware Driver) 관련 취약점은 해당 드라이버가 사용되지 않는 시스템에는 무의미하다는 지적이 제기된다.

CVSS 점수의 무의미함과 CVE의 오해

커뮤니티에서는 CVSS(Common Vulnerability Scoring System) 점수가 사용자 환경(User Context)을 고려하지 않아, 실제 시스템의 위험도를 정확하게 반영하지 못한다고 지적한다. 특히, NIST/NVD와 같은 기관에서 부여하는 CVSS 점수는 잘못된 보안 인식(False Sense of Security)을 심어줄 수 있으며, 불필요한 업데이트를 유발할 수 있다는 비판이 제기된다. 따라서, 사용자 맞춤형 위험 평가(Customized Risk Assessment)가 중요하다고 강조한다.

CVE의 유효 범위와 개선 방향

논의에서는 CVE가 제품 또는 배포판 수준에서 의미를 갖는다는 주장이 제기된다. USB 스캐너 드라이버(USB Scanner Driver)의 취약점이 특정 환경에만 영향을 미치는 것처럼, 커널 수준의 CVE는 모든 시스템에 동일하게 적용될 수 없다. 따라서, 구조화된 문제 명명 시스템(Structured Issue Naming Repository)을 통해, 사용자 환경에 맞는 CVE 정보를 제공하는 것이 필요하다는 의견이 제시된다.

자동화된 테스트 환경과 안정성 확보

커뮤니티에서는 안정적인 커널 릴리스를 위해 자동화된 테스트 환경(Automated Testing Labs)의 중요성을 강조한다. 특히, 안정화된 커널 릴리스에 대한 테스트 외에도, 메인라인(Mainline) 및 개발자 트리(Maintainer Trees)에 대한 테스트가 필요하다는 의견이 제시된다. 또한, 커널CI(KernelCI)와 같은 테스트 결과 공유 플랫폼을 통해, 개발자와 사용자 간의 정보 공유를 활성화해야 한다.