🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개)
0한눈에
- 대상: 수집된 파일/함수 취약점 + OS 패키지 취약점의 정확성(오탐·미탐) 검증.
- 성격: 일회성 프로젝트가 아니라 상시 업무 (2024~2026 지속).
- 담당: 데이터 엔지니어 · 데이터파트, 2026~ 파트리더로서 검증 체계 운영·고객사 대응 주도.
1왜 검증이 필요한가
수집·매칭 과정에서 오탐(실제로는 안전한데 취약 표기)과 미탐(실제 취약한데 누락)이 생긴다. 이 데이터가 그대로 고객에게 나가면 신뢰가 깨지므로, 실제 취약점인지 검증하는 정밀 분석이 필수다.
정밀 케이스 예시: 어떤 함수/파일의 패치 코드가 동시에 다른 취약점의 취약 코드인 경우. 표면 매칭만 보면 판단이 뒤집힌다 → 코드 단위 정밀 분석으로 실제 여부를 가린다.
2업무 흐름
- 수집 데이터(파일/함수·OS 패키지)의 오탐·미탐 여부를 정밀 분석
- 버전 비교 로직·수집처 차이 등 오탐/미탐의 원인 규명
- 고객사 검증 요청(오탐·미탐 확인, 컨테이너 이미지·OS 패키지 검토 등) 직접 검증 후 보고서 작성·제공. 사례: RHEL 9.4 커널 유발 취약점 10,995건을 분석하고 중복 통합 시 1,500건 이내로 줄이는 개선안 도출, 고객사 OS 이미지 54개의 오탐 유형을 원인별(수집처 최신화 이슈 등)로 분류·대응.
- 드러난 원인을 수집·분석 파이프라인 개선으로 환류 → 재발 방지
검증 → 원인 규명 → 보고 → 환류가 순환한다. 환류 단계가 없으면 같은 오탐·미탐이 반복되므로 가장 중요한 단계.
3온보딩 포인트
- 오탐·미탐의 흔한 원인: 버전 비교 로직(패치 버전 경계 판단), 수집처 차이(소스마다 권고 체계·범위가 다름).
- 고객사 요청 유형: 오탐·미탐 확인, 컨테이너 이미지·OS 패키지 취약점 검토가 대표적.
- 모든 검증 결과는 근거를 담은 보고서로 남긴다 — 고객 신뢰와 내부 환류의 근거가 됨.
- 검증은 수집·분석 파이프라인과 분리되지 않는다. 검증에서 나온 원인은 반드시 파이프라인 개선으로 연결.
4공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/vulnerability-verification.html)은 고객사명(예: 신한라이프·삼성 등)·내부 티켓 ID·내부 테이블명·호스트명·동료 이름 등 내부 식별자를 제거하고, CVE·CWE·CVSS·오탐·미탐·패치 버전·컨테이너·OS 패키지·함수/파일 취약점 같은 일반 개념어만 남겨 일반화했다. 이 내부 문서는 본인 참고/온보딩용으로 식별자 유지가 가능하다.