취약점 검증 &
고객사 검증 대응

왜 검증이 필요한가

• 수집·매칭 과정에서 오탐 · 미탐 발생 — 안전한데 취약 표기, 또는 취약한데 누락
• 정밀 케이스: 어떤 함수/파일의 패치 코드가 동시에 다른 취약점의 취약 코드인 경우
• 고객사는 자사 컨테이너 이미지·OS 패키지 취약점 표기가 맞는지 검증을 요청

검증 → 환류 순환

단발 확인이 아니라 검증 체계를 기획·활용해 정확성을 검증하고, 원인을 파이프라인 개선으로 환류해 재발을 방지.

검증 분석과 고객 대응

• 파일/함수·OS 패키지 취약점이 실제 취약점인지 검증하는 정밀 분석 수행 (예: RHEL 9.4 커널 유발 취약점 10,995건 분석 → 중복 통합 시 1,500건 이내 개선안)
• 버전 비교 로직·수집처 차이 등 오탐/미탐의 원인 규명 (OS 이미지 54개 오탐 유형 분류)
• 고객사 검증 요청을 직접 검증하고 결과를 보고서로 작성·제공
• 드러난 원인을 수집·분석 파이프라인 개선으로 환류

결과

내 역할

• 데이터 엔지니어로서 검증 분석 → 원인 규명 → 보고서 대응 → 파이프라인 환류 전 과정 담당
• 2026~ 파트리더로서 검증 체계 운영·고객사 대응 주도
• 배움: 보안 데이터의 가치는 결국 정확성 — 검증과 환류가 수집만큼 중요