작성일: 2026-08-28 대상: 관제 CPE 매칭 3문항 기준 테이블: labradordb.TB_COMP_FILE_VULN_V1 근거: comp_file_vuln_v1_all 매핑 코드 (mapping_info_from_cve_raw → comp_file_vuln_raw → comp_file_vuln_v1)
짧은 버전 (이걸 보내면 됩니다):
TB_COMP_FILE_VULN_V1 기준입니다. 이 테이블에는 CPE 문자열이 없고, NVD CPE에서 제품명만 뽑아 OSS에 붙인 결과입니다.
- 원문 완전 일치가 아닙니다. CPE를 소문자·구분자로 나눈 뒤 이름 토큰이 겹치면 매칭합니다. 버전은 범위로만 씁니다.
- 1:N입니다. 한 CVE가 여러 OSS에 붙을 수 있습니다.
- 1:1 CPE 개수는 이 테이블로 셀 수 없습니다. CPE가 남지 않고, 지금은 OSS–CVE 약 8.5만 행입니다.
긴 버전:
CPE 매칭 관련 세 항목은 파일 컴포넌트 취약점 테이블 TB_COMP_FILE_VULN_V1 기준으로 답합니다.
이 테이블에는 CPE 문자열이 없습니다. NVD CPE를 파싱해 파일 컴포넌트(OSS_ID)와 CVE를 붙인 결과만 있습니다.
- CPE 표기 정규화 후 매칭인지, 원문 완전 일치인지
원문 완전 일치가 아닙니다. NIST CPE 정규화(WFN) 비교도 아닙니다.
NVD configurations의 CPE를 vendor / product / version으로 나눈 뒤, vendor·product는 소문자로 바꾸고 구분자(-, _, .)로 쪼갭니다. 그 토큰을 CVE reference URL에서 뽑은 OSS 이름 토큰과 양방향 부분문자열로 비교합니다. 버전은 매칭 키가 아니고, 영향 범위(VULN_RANGE)로만 넣습니다.
그래서 CPE 문자열이 자산 표기와 같아야 붙는 구조가 아닙니다. 이름 토큰이 겹치면 붙습니다.
- CPE 1개가 자산 1개에만 매핑되는지, 다수에도 매핑되는지
다수에 매핑됩니다. 1:1이 아닙니다.
같은 CVE의 CPE 여러 개는 vendor:product로 합치고, 그다음 URL 조건(SOURCE_URL LIKE '%추출URL%')으로 파일 컴포넌트에 붙입니다. 테이블 PK가 (OSS_ID, VULN_ID)라서 한 CVE가 여러 OSS에 행으로 쌓입니다. 한 OSS가 여러 CVE를 가지는 반대 방향도 됩니다.
- 1:1로 매핑 가능한 CPE 문자열 개수
이 테이블로는 셀 수 없습니다. CPE 원문이 남지 않기 때문입니다.
저장되는 것은 OSS–CVE 매핑입니다. 현재 labradordb.TB_COMP_FILE_VULN_V1 기준 약 8.5만 행입니다. 매핑 설계가 1:N이라, 1:1 CPE 개수를 규모 지표로 쓰기는 어렵습니다.
정리하면, 파일 컴포넌트 취약점은 CPE 문자열 동등 비교가 아니라 CPE에서 뽑은 제품명 토큰 + URL로 OSS에 붙이는 방식입니다.