버전 숫자는 진실이 아니다 — 취약점 매칭이 틀리는 이유

버전 숫자는 진실이 아니다 — 취약점 매칭이 틀리는 이유

백포트와 커널이 스캐너를 오작동시키는 방식, 그리고 정확도 회복

게시 날짜

작성자

Team Riskmap

취약점 관리의 신뢰는 ‘점수’가 아니라 ‘매칭’에서 먼저 무너진다. 자산에 설치된 소프트웨어를 CVE와 연결하는 이 과정이 틀리면, 존재하지 않는 위험에 인력을 쓰거나(오탐) 실재하는 위험을 놓친다(미탐). 특히 리눅스 배포판의 백포트(backport)와 커널은 버전 문자열만으로 판정하는 스캐너를 체계적으로 오작동시킨다. 본 글은 취약점 매칭이 왜 틀리는지, 정확도를 어떻게 회복하는지를 다룬다.

문제 정의 — 버전 숫자는 진실이 아니다

다수의 취약점 도구는 컴포넌트의 버전 번호를 읽어 CVE의 영향 범위와 대조하는 방식으로 취약 여부를 결정한다. 문제는 이 전제가 엔터프라이즈 리눅스에서 깨진다는 점이다. Red Hat은 이렇게 설명한다. “일부 보안 스캐닝·감사 도구는 발견한 컴포넌트의 버전 번호만으로 취약점을 판단한다. 이는 백포트된 보안 수정을 고려하지 못해 오탐(false positive)을 만든다.”[1]

백포트란 최신 버전으로 올리는 대신, 안정성을 유지하며 보안 패치만 기존 버전에 이식하는 방식이다. 취약 코드는 제거됐지만 버전 번호는 그대로다. 그래서 버전만 보는 스캐너는 이미 패치된 시스템을 ‘취약’으로 보고한다.

근거 — 오탐과 미탐, 양방향으로 틀린다

오탐(false positive): 위 백포트 사례가 대표적이다. 운영자는 이미 안전한 자산에 대한 경보에 시간을 쓰고, 반복되면 경보 자체를 불신하게 된다.

미탐(false negative): 반대 방향도 있다. 소프트웨어가 버전을 제대로 노출하지 않거나 플레이스홀더 버전(예: 1.0.0.0)을 보고하면, 버전 매칭은 실재하는 취약점을 통과시킨다. 또 제품명이 과도하게 일반화되면(같은 이름의 서로 다른 제품·모듈) 무관한 CVE가 대량으로 잘못 매칭돼 오탐이 폭증한다.

커널은 이 문제가 가장 첨예한 영역이다. 리눅스 커널은 배포판마다 광범위하게 백포트되므로, 상위 취약점 데이터베이스의 ‘버전 범위’로는 특정 배포판 커널이 실제로 취약한지 판정할 수 없다. 버전 범위를 그대로 적용하면 오탐과 미탐이 동시에 발생한다.

분석 — 정확도는 ‘어느 소스로 판정하느냐’의 문제

해법의 핵심은 버전 문자열이 아니라 패치 상태가 실제로 기록된 곳을 판정 근거로 삼는 것이다. Red Hat은 2000년 1월 이후 모든 보안 권고에 CVE를 연결해 두었고, 서드파티 도구가 백포트 여부까지 반영해 판정할 수 있도록 기계 판독용 OVAL 정의를 제공한다.[1] 배포판의 보안 권고와 OVAL·CVE 인덱스가 버전 숫자보다 우선하는 진실의 원천이다.

오픈소스 생태계에서는 OSV(Open Source Vulnerabilities)처럼 패키지·에코시스템 단위로 정밀하게 매칭하는 데이터가 버전 범위 방식의 한계를 보완한다.[2] 반면 NVD의 CPE 기반 버전 범위는 백포트·배포판 특수성을 담지 못한다는 한계가 잘 알려져 있다.[3]

리스크맵이 현장에서 확인하는 패턴도 동일하다. 커널 취약점은 상위 DB의 버전 범위 대신 배포판·OSV 계열의 소스로 판정해야 오탐과 미탐이 함께 줄어든다. 제품명 과일반화·플레이스홀더 버전 같은 매칭 오류 유형은 판정 소스와 정규화 규칙을 정교화해야 걸러진다.

실무 대응 — 매칭 정확도를 검증 가능하게

① 판정 소스를 명시하라. “무엇을 근거로 이 자산이 취약하다고 했는가”를 CVE·권고·OVAL·OSV 중 무엇으로 판정했는지까지 추적 가능하게 한다.

② 백포트를 반영하라. 엔터프라이즈 리눅스는 버전이 아니라 배포판 권고/OVAL로 판정한다. 버전만 보는 도구는 리눅스에서 오탐 공장이 된다.

③ 커널은 별도 규칙으로. 커널 CVE는 상위 DB의 버전 범위를 그대로 신뢰하지 말고 배포판·OSV 기반으로 교차 판정한다.

결론

CVSS 점수를 논하기 전에, 그 취약점이 정말 우리 자산에 존재하는가부터 맞아야 한다. 매칭이 틀리면 그 위에 쌓은 모든 우선순위와 조치가 함께 틀린다. 정확한 취약점 관리는 버전 숫자를 넘어, 패치 상태가 실제로 기록된 소스로 자산을 판정하는 데서 시작된다.

참고문헌

[1] Red Hat, Security Backporting Practice, Red Hat Customer Portal.

[2] OSV (Open Source Vulnerabilities), osv.dev — 오픈소스 취약점 정밀 매칭 데이터베이스.

[3] NIST National Vulnerability Database, CPE 기반 버전 범위 매칭의 한계 관련 문서.