RHEL VEX 수집기 구현과 채널·모듈 데이터 검증
채널·모듈 정보를 보존하는 수집기와 Airflow DAG를 구현하고, 65,440개 문서 시험 적재와 회귀 검증을 마쳤습니다.
작업 요약
개발 완료 · 65,440개 문서 시험 적재 · 최종 파싱 오류 0건
OVAL 시절의 가정이 남아 있었습니다
ServerCare의 RHEL 패키지 취약점 오탐을 따라가 보니 원천 포맷은 이미 VEX로 바뀌어 있었지만, 파싱 단계에는 OVAL 시절의 가정이 남아 있었습니다. 한 제품의 패치 버전을 같은 메이저의 모든 마이너 버전으로 늘리고, 모듈 조건을 판정에 쓰지 않으며, 패키지 이름을 첫 하이픈에서 자르는 문제가 함께 있었습니다.
현행 수집 테이블은 371만 행·14.7GB였습니다. 이 상태에서 파서만 부분 수정하면 어떤 행이 왜 만들어졌는지 설명하기 어려워, 기존 구현을 유지하지 않고 수집 단위와 서버의 취약점 판정 기준을 다시 정했습니다.
RHEL VEX 개발을 완료했습니다. 수집기·DAG 구현과 main 병합, 시험 적재 및 DEV DB 수집을 마쳤습니다. 운영 배포 여부와 오탐 감소율은 별도 확인 항목입니다.
전수 분석 뒤 65,440개 문서를 시험 적재했습니다
- 설계 단계에서는 VEX 문서 63,152개를 전수 분석했습니다.
product_tree.relationships로 약 715만 개의product_id를 모두 제품 CPE에 연결했고, 같은 저장 키에 서로 다른 상태가 모이는 401건을 찾아 우선순위를 정했습니다. - 구현에서는 CPE 문자열을
CHANNEL_ID로 바꾸고 같은 채널의 저장소 스트림을 합쳤습니다. MAIN·EUS·AUS·TUS의 패치 버전 차이는 채널별로 보존했습니다. - 8월 27일 별도 시험 DB에 문서 65,440개를 적재했습니다. 일시적인 MySQL 시간 초과 2건은 재처리했고, 최종적으로 모든 문서의 파싱이 끝났습니다. 8개 CVE·421행 회귀 검증에서도 데이터의 실질적인 불일치는 0건이었습니다.
CPE·구독 채널·모듈 조건을 나눠 확인했습니다
- 호스트 CPE를 그대로 조인하지 않음 — BaseOS CPE 하나만 보고 조회하면 같은 서버가 쓰는 AppStream 행 38.2%가 빠졌습니다. 호스트 CPE에서 메이저·구독 채널을 읽고 대상 repo stream 목록으로 확장합니다.
- 구독 채널을 판정 입력으로 둠 — MAIN과 구독 채널의 패치 버전은 비교 가능한 경우 96.9% 달랐습니다. 인증서를 읽지 못한 서버는 MAIN으로 처리하되 “구독 미확인”을 함께 남기도록 했습니다.
- 설치 패키지의 모듈을 확인 — 호스트 전체의 활성 모듈 설정만으로 판단하지 않고, 패키지별
MODULARITYLABEL을 VEX의mysql:8.0같은 모듈 조건과 비교하도록 정했습니다. 필요한 입력을 받지 못하면 확인되지 않은 상태를 남깁니다. 이 항목의 검증 수치는 수집 데이터와 회귀 기준을 대조한 결과입니다.
아키텍처와 판정 경계
수집 DB에는 채널 사전, 취약점 데이터, 문서 상태를 나눠 저장합니다. 판정 입력의 CPE는 내부 채널로 변환하고, CHANNEL_ID와 설치 패키지·모듈 조건으로 조회 범위를 좁힙니다. 배포 DB에는 채널 사전과 취약점 데이터만 전달하도록 구성했습니다.
취약 버전은 단일 패치 버전 컬럼 대신 VERSION_RANGE에 저장합니다. 패치 이전의 모든 버전과 특정 구간만 취약한 경우를 같은 형식으로 표현하도록 공통 스키마를 정했고, 먼저 RHEL 수집기에 적용했습니다. 다른 OS 수집기의 전환까지 완료한 것은 아닙니다.
Airflow DAG는 원문 수집과 파싱을 두 작업으로 나눴습니다. 최초에는 전체 아카이브를 읽고, 이후에는 4시간 주기로 변경·철회 목록을 처리하도록 구성했습니다. 문서 처리 상태와 진행 기준 시각을 DB에 남겨 실패한 구간부터 다시 실행할 수 있게 했습니다.
고객사로 나가는 쓰기량까지 계산했습니다
배포DB는 고객사 on-premise 서버로 보내는 바이너리 로그의 발원지입니다. 문서가 바뀔 때 기존 행을 전부 지우고 다시 넣으면 내부 DB 부하에서 끝나지 않고 모든 고객사에 같은 쓰기가 전달됩니다.
- 재게시 문서 120개를 과거본과 비교하니 fact 행이 실제로 바뀐 비율은 22.7%였고, 문서의 75%는 fact 변화가 없었습니다.
- 문서 전체 재계산은 유지하되 저장된 행과 차이만 반영하면, 설계 산정상 하루 row event가 약 61,600건에서 7,000건으로 줄어듭니다.
deletions.csv는 별도 진행 기준 시각으로 추적하고, 철회된 문서의 행은IS_DELETED로 삭제 상태를 표시하도록 구현했습니다.
결과
- RHEL VEX 개발을 완료했습니다. 수집기와 Airflow DAG 구현·main 병합, 시험 적재와 DEV DB 수집 결과를 확인했습니다.
- 시험 적재에서 채널 사전 87행 · 취약점 2,778,589행 · 문서 상태 65,440행을 확인했습니다. 초기 CPE 단위 설계 수치와는 저장 단위와 원문 시점이 달라 단순 감소율로 비교하지 않았습니다.
- 8개 CVE·421행의 회귀 기준과 대조해 데이터의 실질적인 불일치 0건을 확인했습니다. 수집 범위에는 RHEL 4~7 서버 스트림도 포함했습니다.
- 테스트 DB 분리, 실패 상태 재처리, 문서 철회와 변경 행 반영 경로를 검증했습니다. 최종 저장 용량과 고객사 전달 쓰기량은 운영 환경에서 추가 확인해야 합니다.
역할
기존 코드와 DB 행을 대조해 오탐을 만드는 가정을 찾고, VEX 원문을 전수 분석해 스키마와 판정 순서를 정했습니다. 이어서 수집기·파서·변경 행 적재 로직과 Airflow DAG를 구현하고 시험 적재와 회귀 검증을 맡았습니다. 수집기 개발 완료와 운영 배포 상태는 구분해 기록했습니다.
관련 항목: 멀티 배포판 OS 패키지 수집 개편 · OS 패키지 취약점 수집 정확도 개선