🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개)
0한눈에
- 대상: 공개 패치 정보 기반 파일/함수 단위 취약점 데이터셋 수집 파이프라인.
- 문제: V3는 단일 프로세스에서 수집·검증·저장을 모두 처리 → 관리 난이도, 데이터 중복, 비효율 DB 구조로 인한 성능 문제.
- 해결: 수집 2단계 분리 + DB 스키마 정규화 + 상태 플래그(
processed) 기반 처리.
1V3가 왜 한계였나
V3는 패치 커밋 식별, 소스/diff 수집, 저장까지 모든 작업을 단일 프로세스가 담당했다. 그 결과:
- 로직이 한 덩어리라 운영·디버깅·부분 확장이 어려움.
- 데이터 중복과 비효율적인 테이블 구조로 저장 공간 낭비 + 쿼리 성능 저하.
- 중간 실패 시 어디까지 처리됐는지 추적 불가 → 전체 재실행 또는 누락 위험.
2V4 구조 — 수집 2단계 분리
패치 소스공개 취약점/패치 정보
→
① 커밋 수집패치 커밋 URL 수집·검증
→
② 소스/diff 수집커밋 URL 기반 소스코드·diff
→
정규화 DB취약점 데이터셋
- 1단계: 패치 커밋 URL을 수집하고 유효성을 검증해 저장.
- 2단계: 검증된 커밋 URL을 입력으로 받아 소스코드·diff 정보를 수집.
- 각 단계 항목에
processed 상태 플래그를 두어 대기 / 완료 / 실패를 추적.
- 실패 건만 골라 재처리 → 전체 재실행 불필요, 누락 최소화.
단계를 분리했기 때문에 1단계(커밋 수집)와 2단계(소스/diff 수집)를 독립적으로 운영·재시도·확장할 수 있다. 1단계가 잘못된 URL을 걸러주므로 2단계 입력 품질이 올라간다.
3DB 스키마 정규화
- V3의 중복 데이터 구조를 정규화해 동일 정보의 반복 저장을 제거.
- 저장 효율 개선 + 조인/조회 기준 쿼리 성능 개선.
processed 플래그를 스키마에 반영해, 처리 상태가 데이터 자체로 추적되도록 함.
4온보딩 포인트
- 수집 흐름은 항상 커밋 URL 수집·검증(1) → 소스/diff 수집(2) 순서. 2단계는 1단계 검증 결과에 의존.
- 장애·누락 조사 시 먼저
processed 상태로 어디서 멈췄는지 확인.
- 재처리는 전체 재실행이 아니라 실패 상태 항목만 다시 돌리는 것이 원칙.
- 설계 원칙: 단일 프로세스에 책임을 몰지 말고 단계 분리 + 상태 추적 + 정규화로 신뢰도를 확보.
5공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/vuln-func-collection-v4.html)은 내부 식별자(내부 코드네임·테이블명·호스트명·티켓 ID 등)를 제거하고 문제·접근·임팩트·역할 중심으로 일반화했다. 이 내부 문서는 본인 참고/온보딩용이며 내부 식별자를 그대로 유지할 수 있다.