RHEL VEX 취약점 수집 구조 재설계

0오탐은 파서보다 데이터 모델에서 시작됐습니다

ServerCare의 RHEL 패키지 취약점 오탐을 따라가 보니 원천 포맷은 이미 VEX로 바뀌어 있었지만, 파싱 단계에는 OVAL 시절의 가정이 남아 있었습니다. 한 제품의 패치 버전을 같은 메이저의 모든 마이너 버전으로 늘리고, 모듈 조건을 판정에 쓰지 않으며, 패키지 이름을 첫 하이픈에서 자르는 문제가 함께 있었습니다.

현행 수집 테이블은 371만 행·14.7GB였습니다. 이 상태에서 파서만 부분 수정하면 어떤 행이 왜 만들어졌는지 설명하기 어려워, 기존 구현을 유지하지 않고 수집 단위와 서버 판정 경계를 다시 잡았습니다.

현재 상태는 설계·전수 측정 완료입니다. 수집기 구현, 시험 적재, 배포 전환, 운영 오탐 감소율 측정은 아직 끝나지 않았습니다.

163,152개 문서를 먼저 전수 측정했습니다

• product_tree.relationships로 약 715만 개의 product_id를 모두 제품 CPE에 연결할 수 있음을 확인했습니다.
• 아키텍처를 키에서 빼자 서로 다른 상태가 한 키로 합쳐지는 401건이 드러났습니다. 적재 실패를 피하려고 상태 우선순위와 STATUS_CONFLICT를 설계에 넣었습니다.
• MAIN과 EUS·AUS·TUS처럼 구독 채널이 다른 행은 같은 패키지·CVE라도 패치 버전이 달라 CPE를 fact 키에 남겼습니다.

2세 가지 판단이 구조를 바꿨습니다

• 호스트 CPE를 그대로 조인하지 않음 — BaseOS CPE 하나만 보고 조회하면 같은 서버가 쓰는 AppStream 행 38.2%가 빠졌습니다. 호스트 CPE에서 메이저·구독 채널을 읽고 대상 repo stream 목록으로 확장합니다.
• 구독 채널을 판정 입력으로 둠 — MAIN과 구독 채널의 패치 버전은 비교 가능한 경우 96.9% 달랐습니다. 인증서를 읽지 못한 서버는 MAIN으로 처리하되 “구독 미확인”을 함께 남기도록 했습니다.
• 모듈 조건을 먼저 거름 — mysql:8.0처럼 VEX에 모듈이 지정됐는데 서버에서 꺼져 있으면 해당 행을 제외합니다. 모듈 정보를 못 받는 경우도 조용히 넘기지 않고 상태로 드러내는 방향을 남겼습니다.

4고객사로 나가는 쓰기량까지 계산했습니다

배포DB는 고객사 on-premise 서버로 보내는 바이너리 로그의 발원지입니다. 문서가 바뀔 때 기존 행을 전부 지우고 다시 넣으면 내부 DB 부하에서 끝나지 않고 모든 고객사에 같은 쓰기가 전달됩니다.

• 재게시 문서 120개를 과거본과 비교하니 fact 행이 실제로 바뀐 비율은 22.7%였고, 문서의 75%는 fact 변화가 없었습니다.
• 문서 전체 재계산은 유지하되 저장된 행과 차이만 반영하면, 설계 산정상 하루 row event가 약 61,600건에서 7,000건으로 줄어듭니다.
• deletions.csv는 별도 watermark로 처리해 철회된 CVE의 잔여 행을 지우도록 했습니다.

5결과

• 테이블을 CPE 사전 약 90행 · fact 약 487만 행 · 문서 상태 약 6.3만 행의 3개로 정리했습니다.
• 설계상 예상 용량은 약 1.5GB입니다. 현행 14.7GB와의 차이는 첫 시험 적재에서 확인해야 하므로 완료 수치로 쓰지 않았습니다.
• 수집 범위, 상태 충돌, 패치 EVR 후보, 서버 판정 순서, 철회 처리, 배포DB 쓰기량을 한 문서에서 검토할 수 있게 만들었습니다.
• RHEL 4~7 server stream, add-on 채널, known_not_affected 저장, 에이전트 입력, 배포 전환은 결정 항목으로 남겼습니다.

6역할

기존 코드와 DB 행을 대조해 오탐을 만드는 가정을 찾고, VEX 전체 corpus를 측정해 스키마·수집 절차·판정 순서를 설계했습니다. 구현된 결과처럼 보이지 않도록 현재 완료 범위를 문서·측정·협의안으로 한정했습니다.

관련 항목: 멀티 배포판 OS 패키지 수집 개편 · OS 패키지 취약점 수집 정확도 개선