← 기술 목록으로
CVECWECVSS오탐·미탐패치 버전 비교파일/함수 취약점OS 패키지컨테이너 이미지
0작업자의 메모
수집된 취약점 데이터는 제품에 들어가기 전에 한 번 더 의심해야 합니다. 고객사 검증 요청은 불편한 일이지만 데이터가 실제 환경에서 어떻게 틀릴 수 있는지 알려주는 가장 좋은 피드백이기도 합니다.
RHEL 커널 유발 취약점이나 고객사 OS 이미지 오탐을 분석한 이유는 단순히 답변서를 쓰기 위해서가 아니라, 다음 수집 로직과 판단 기준을 고치기 위해서였습니다.
1배경
제품은 수집된 파일/함수 취약점과 OS 패키지 취약점을 고객에게 제공합니다. 그런데 수집·매칭 과정에서 오탐(실제로는 취약하지 않은데 취약하다고 표기)과 미탐(실제로는 취약한데 누락)이 발생할 수 있어 데이터가 정말 실제 취약점인지 검증하는 분석이 필요했습니다.
- 예: 어떤 파일/함수의 패치 코드가 동시에 다른 취약점의 취약 코드인 경우처럼, 표면적 매칭만으로는 판단이 어긋나는 정밀 케이스가 존재
- 버전 비교 로직, 수집처 간 차이 등 다양한 원인이 오탐·미탐으로 이어짐
- 고객사는 자사 환경(컨테이너 이미지·OS 패키지 등)의 취약점 표기가 맞는지 검증을 요청
2접근
① 검증 분석오탐·미탐 여부를 정밀 분석
→
② 원인 규명버전 비교 로직·수집처 차이 등 원인 규명
→
③ 보고서고객사 요청에 근거 있는 결과 보고
→
④ 환류원인을 수집·분석 파이프라인 개선으로 반영
단발성 확인에 그치지 않고, 취약점 검증 체계를 기획·활용해 수집 데이터의 정확성을 검증하고 드러난 원인을 다시 수집·분석 파이프라인 개선으로 환류해 재발을 방지하는 순환 구조를 만들었습니다.
3한 일
- 수집된 파일/함수 취약점과 OS 패키지 취약점이 실제 취약점인지 검증하는 정밀 분석 수행 — 예: 패치 코드가 다른 취약점의 취약 코드인 경우 등
- 취약점 검증 체계를 기획·활용해 수집 데이터의 정확성을 검증하고 버전 비교 로직·수집처 차이 등 오탐·미탐의 원인을 규명
- 고객사 검증 요청(오탐·미탐 확인, 컨테이너 이미지·OS 패키지 취약점 검토 등)을 직접 검증하고 결과를 보고서로 작성·제공
- 대표 사례 ① RHEL 9.4 분석에서 커널 유발 취약점 10,995건을 식별·분석하고, 중복 취약점을 통합 표기하면 1,500건 이내로 줄일 수 있다는 개선안을 제시
- 대표 사례 ② 고객사 OS 이미지 54개의 오탐 유형을 분류하고, 수집처 데이터 최신화 이슈 등 원인별로 대응
- 검증에서 드러난 원인을 수집·분석 파이프라인 개선으로 환류
4임팩트
데이터 신뢰도 — 오탐·미탐 원인을 규명·환류해 취약점 데이터의 신뢰도 향상
고객 신뢰 확보 — 검증 요청에 근거 있는 보고서로 대응해 신뢰 확보
재발 방지 — 원인을 수집·분석 파이프라인 개선으로 반영해 동일 오탐·미탐 재발 차단
5역할
데이터 엔지니어로서 검증 분석 → 원인 규명 → 보고서 대응 → 파이프라인 환류의 전 과정을 단독으로 수행했습니다. 2026년부터는 데이터 엔지니어링 리드로서 검증 체계의 운영과 고객사 대응을 이끌고 있습니다.
연계: OS 패키지 취약점 수집 개편, 함수 추상화 해시 생성 등 수집·분석 항목과 맞물려 데이터 정확성을 높이는 작업으로 진행.