LLM WikiAccess-protected knowledge portal

WIKI

labrador-scrapers

AI Summary Purpose 데이터 수집 ETL 컴포넌트 스크래퍼 모노레포. etl components/<name / 마다 컨테이너 1개. Key points 신규 컴포넌트는 etl component template/template/ 또는 기존 etl components/osv vuln 을 본떠 만든다. 프레임워크 labrador sqlmodel BaseScraper / TransactionManager + 모델은 Bas

경로ai/repo-notes/labrador-scrapers.md
카테고리Repo Note
태그#ai-review #airflow #crawler #labrador #notes #platform #repo #repo-note #scraper #scrapers #security

# labrador-scrapers

AI Summary

Purpose:

Key points:

parser. It measures all 63,152 documents and specifies three tables (CPE dictionary, vulnerability facts, and document state), channel/module-aware matching, and document-scoped recomputation with row-diff application.

dat-3533/rhel_vex_v4 (commit 519024e): etl_components/os_pkg_vuln/rhel_vex_crawler/ — models per the final multi-OS schema (CHANNEL_ID replaces CPE, streams folded, MODULE ''-default in PK, IS_DELETED soft delete, SOURCE_ID/SOURCE_REF, URL), relationships-based parser (rhel_vex_parsing.py, pure/tested), archive+changes.csv+deletions.csv raw crawler with gap-free inclusive watermarks, document-scoped diff loader. Golden set (8-CVE sheet) zero real mismatches. Trial load, DAG (DAT-3557), and cutover remain. NOTE: fact table name equals live v3 TB_OS_PKG_VULN_RHEL — trial must target a test schema.

URLs from approved sources. High-risk sources route to written agreement, official interfaces, or replacement data; medium-risk sources require runtime rate-limit, API-key, User-Agent, and robots controls. This is neither completed legal advice nor proof that every affected production source was already removed.

Relevant when:

Do not read full document unless:

Linked documents:

Repo Info

Architecture Notes

main.py(엔트리), consts.py, base.py(Database dataclass), db_utils.py (LabradorDB: selects/insert/update, ON DUPLICATE KEY UPDATE, 100개 청크), utils.py(CommonUtil snake/camel·JSON), exceptions.py (LabradorScraperCriticalError), <name>_models.py, Dockerfile, install_deps.sh, pip.conf, version.txt.

initialize()(DB open·테이블 보장·상태 로드), scrape_data() -> List[BaseRecord] (self.done=True 될 때까지 반복 호출). 직접 DB 쓰기는 self.db = LabradorDB()로 하고 []를 반환해도 됨(osv_raw_crawler/openssf_mal 방식).

--scraper-args "k=v,k2=v2" --incremental/--no-incremental --log-to-console --log-level. find_scraper가 이름→클래스 매핑.

마지막 동기화 상태 저장. 컴포넌트별 TYPE 사용(예: OSV_RAW, OPENSSF_MAL).

install_deps.sh로 추가 의존성, COPY *.py ., ENTRYPOINT python3 main.py. PVC는 /resources에 마운트(RESOURCES_DIR).

컴포넌트: openssf_mal (OpenSSF 악성 패키지)

MAL-YYYY-NNNN)를 git clone/pull로 PVC에 받아 TB_COMP_LIB_MAL에 적재.

VULN_RANGE는 | 구분 토큰 합집합, DEPRECATED(0/1) 소프트삭제 + VIEW_COMP_LIB_MAL.

crates.io→CARGO, Maven→MAVEN, Packagist→COMPOSER. vscode/git`은 스킵.

(원본 npm_crawler/ai/labradorlabs/util/aesCbc.py). 그 외 생태계는 평문명.

SUMMARY/DETAILS/MAL_REFERENCES(=osv.references, REFERENCES는 예약어)/ALIASES. MAL과 동일 라이프사이클(같은 run_ts upsert, 변경 시 MAL/MAL_INFO 양쪽 deprecate→재upsert, full sweep 양쪽) + VIEW_COMP_LIB_MAL_INFO. MAL 행 생긴 advisory만 생성. 같은 스크래퍼가 두 테이블 함께 적재. 신규 테이블 백필 = --scraper-args "full_reconcile=true".

정본 human/reports/2026-malicious-package-collection.md.

컴포넌트: spm_scraper (Swift Package Index / SPI)

DB: gatheringdb TB_COMP_LIB_PRODUCT_SPI / TB_COMP_LIB_VERSION_SPI (LANGUAGE='swift', PACKAGE_MANAGER='SPM', PRODUCT_KEY=owner/repo).

= PRODUCT_KEY. 버전 = GitHub tags HTML 스크랩(github.com/{owner}/{repo}/tags?after=<last_tag> 커서, div.Box-body.p-0[data-view-component] … h2.f4.d-inline>a). 태그별 git clone+checkout 으로 라이선스(licensee) 추출. 태그 0개 repo는 product 통째로 skip(미적재).

sitemap이 로컬 Cloudflare 403이라 동일 데이터 SwiftPackageIndex/PackageList/packages.json (GitHub raw)을 universe로 사용. product 누락(차집합) + version 누락(repo별 GitHub 태그 vs DB). 백필 충실판 collect_spm_missing.py(크롤러 product_process 재사용, 런타임 필요) / 간이판 collect_spm_missing_simple.py(누락 태그를 version row 직접 적재, RELEASE_DATE는 GitHub /commits/{tag}, SORT_ORDER semver 재계산, LATEST_VERSION 보정). 상세 = W26 worklog. grace window(2026-07-06, extract_spm_missing_products.py --grace-days 기본 3): PackageList 최근 N일 추가분은 SPI 인덱싱→sitemap→크롤러 정상 지연(0~2일) 통과 중일 수 있어 누락 대신 spm_missing_grace.txt 로 분리(GitHub API 로 N일 전 시점 packages.json 과 비교). 근거: 7/4~7/5 추가 6건이 "누락"으로 떴으나 전부 지연이었고(태그 보유, collect_spm_new_products.py 로 즉시 백필 완료 — product 6/version 12), 7/1~7/3 추가 18건은 전부 정상 수집돼 있었음. 상세 = W28 worklog.

한계/후속 1 — GitHub 전용 스코프 (GitLab/Bitbucket 사각지대)

전부 github.com, non-GitHub 0개(2026-06-22 실측). ② PackageList 검증 validate.swift가 제출 URL의 owner/repo를 추출해 https://api.github.com/repos/{owner}/{repo} · raw.githubusercontent.com으로만 메타/기본브랜치/트리를 조회 → 비-GitHub URL은 검증 통과 불가 (코드 레벨 강제). ③ 크롤러도 spm_build_processor.py:21 git_url="https://github.com/" 하드코딩 (태그 페치·URL 컬럼 전부 github 고정; 1235줄 gitlab 분기는 SCM 링크 파싱 fallback일 뿐 실제 태그 경로 아님). 참고: 현재 공개 FAQ/Add-a-Package 마크다운엔 "GitHub만"이라는 명시 문장은 없음**(일반 git 요구사항으로만 기술) — 강제는 문서가 아니라 validate.swift가 함.

GitLab/Bitbucket Swift 패키지는 생태계엔 존재하지만 SPI 색인 밖 → 우리 DB universe 밖 → 누락으로도 안 잡힘(분모 밖). 즉 누락 체크 결론은 항상 "GitHub 호스팅 + SPI 색인 한정" 스코프. SPI 미러로서는 올바른 범위지만 GitLab/Bitbucket은 알려진 사각지대.

일반화: GitLab GET /api/v4/projects/{id}/repository/tags, Bitbucket GET /2.0/repositories/{ws}/{repo}/refs/tags. (크롤러 본체 변경 → 현재 보류.)

한계/후속 2 — GitHub tags HTML 스크랩 → GitHub API 전환 권장

태그 페이지 일부만 반환 → 가짜누락(false-positive) 에 취약. 실측(2026-06-22, 16-worker): 1차 누락 9건 중 5건이 직렬 재검증 시 0 누락(throttle 잔상). 진짜 누락은 4건뿐. → 누락 체크는 확정 전 직렬/저동시성 재검증 단계 필수**(도구에 반영).

사용 → 파싱 깨짐·throttle 가짜누락 제거 + 태그 날짜까지 한 번에(간이 백필이 이미 /commits/{tag}로 RELEASE_DATE 정확히 가져온 것처럼). 비용: rate limit — 비인증 60/hr은 11k repo에 부족, 토큰 인증 5,000/hr이면 가능(또는 GraphQL 배치). 크롤러 본체 변경 사안.

누락 포인트 상세 (코드 라인, 2026-06-22 정독)

전부 spm_build_processor.py. 가장 위험 = A1·A2·B1 연쇄(태그 HTML 커서 긁기의 조용한 절단 → 버전 0 → product까지 skip → 복구 큐 없음 → 다음 성공 풀런까지 미복구).

한 페이지라도 비200이면 그때까지 모은 것만 반환 = 조용한 절단. (16-worker 가짜누락 원인.)

없음** → 특수문자 태그명에서 커서 정지 → 무한재귀/뒤버전 누락. (우리 복제본은 quote+max_pages=200.)

A1/A2로 "fetch 실패=0"과 "진짜 태그0"을 구분 못해 일시오류 한 번에 product 통째 누락. 게다가 product 생성 전 L402, version 처리 시 L437 태그를 2번 fetch → 1차 성공(product 생성)/ 2차 실패(버전0) 시 버전0 고아 product 발생 가능.

의존 + pending/retry 마킹 없음(go 크롤러와 대비) → 한번 놓치면 복구 안 됨.

(실제 태그 날짜 아님; 기존 행 전부 동일일자였던 이유).

PK 제약 = 버전없는 패키지 처리 + 실태 (2026-06-22 분류)

→ 버전(=git 태그) 없는 패키지는 version 행 불가. PRODUCT_SPI는 LATEST_VERSION nullable이라 product만은 가능. 크롤러는 태그0이면 product까지 skip(B1)으로 처리 → 진짜 태그없는 SPI 패키지는 영구 사각지대 (product 누락에 잡히나 백필 불가=정상).

진짜 태그없음 401, 에러 0. → 고아 대부분은 버그가 아니라 진짜 태그없음. 태그있는 3개 (heirloomlogic/Persnicket 13, hjuraev/nats-swift 1, workingDog/OSRMSwift 1)는 recover_orphans.py로 15 version 복구(product 행에서 메타 상속). 남은 401은 복구 불가=정상.

(영구 사각지대=정상). 192는 product+version 둘 다 신규 생성 필요 → SPI 상세페이지(DetailParser)가 로컬 Cloudflare 403이라 크롤러 런타임 필요(미해결).

컴포넌트: 라이브러리 크롤러 (npm / pypi / conan / vcpkg / hunter)

crawler-lib-* 외에, 라이브러리(SBOM/패키지) 크롤러 일부가 이 모노레포의 etl_components/ 안에 컴포넌트로 들어와 있다. 두 계열로 나뉜다 (2026-06-23 실측).

계열 A — 레거시 ai/labradorlabs/ 포팅 (work-list LIST 방식)

crawler-lib-*와 같은 코드 계보. 컴포넌트 안에 자체 ai/labradorlabs/... 소스 트리 + info_data dict(테이블 라우팅) + LIST work-list 테이블(PROCESSED flag)을 그대로 들고 있다. main.py의 find_scraper만 BaseScraper 프레임워크에 맞춤.

- 메인 로직 ai/labradorlabs/npmCrawler.py(info_data); 진입 NpmPackageCrawler.py (NpmCrawling/NpmCrawlingIncremental), NpmPackageUpdateCrawler.py, crawling_by_name.py. - 테이블: VERSION=gatheringdb.TB_COMP_LIB_VERSION_JAVASCRIPT, PRODUCT=TB_COMP_LIB_PRODUCT, LIST=gatheringdb.TB_COMP_LIB_JAVASCRIPT_LIST, LICENSE=gatheringdb.TB_COMP_LIB_LICENSE_JAVASCRIPT. - scraper 이름: npm_package_update, npm_crawling. - 라이선스 폴백에 GitHub API(api.github.com/repos/{owner}/{repo}/tags) 사용. - 소스 URL(config.ini [NPM_CRAWLER]): 업데이트 피드 = replicate.npmjs.com/registry/_changes(CouchDB _changes), 메타 = registry.npmjs.com/{product}(전체 doc). - 피드/버전 수집 모델(누락 진단 핵심, 2026-07-09 검증): _changes 는 coalesced → 패키지는 since 순방향에서 문서 최신 seq 에 1회만 등장(버전당 X, 이전 버전 seq 는 이후 업데이트로 덮여 사라짐). 하지만 npm_package_update 는 패키지명만 work-list (processed=0, 재등장 시 ON DUPLICATE KEY UPDATE PROCESSED=VALUES(PROCESSED) 로 0 리셋)에 넣고, npm_crawling 이 registry.npmjs.com/{pkg} 전체 doc 을 받아 api_versions − db_versions 로 없는 버전 전부 삽입(npmCrawler.py:904-948). → 피드 gap ≠ 버전 누락(패키지가 피드에 1회만 떠도 그 시점에 전체 버전 백필). - 진짜 누락 조건: fetch 한 doc 이 부분 200(feed-ahead-of-meta: 피드가 메타 CDN 보다 앞섬) + 이후 재-publish 없음 → 재크롤 안 됨 → 영구 누락. 404 는 retry-ladder (PROCESSED 30~34, npmCrawler.py:29~)가 커버하지만 부분 200 은 미커버. 진단: LIST TIMESTAMP(INSERT 1회, upsert 미변경)=최초 등록 / LAST_UPDATED=마지막 크롤, version 행들의 동일 LAST_UPDATED=단일 크롤 백필. 사례 @zylem/behaviors = 실누락 아님(6월 seq 미수신 but 7/7 1회로 3/3). 상세 ai/worklog/2026/2026-W28.md.

https://pypi.org/pypi/{name}/json. - 테이블: VERSION=gatheringdb.TB_COMP_LIB_VERSION_PYTHON, PRODUCT=labradordb.TB_COMP_LIB_PRODUCT, LIST=gatheringdb.TB_COMP_LIB_PYTHON_LIST, LICENSE=gatheringdb.TB_COMP_LIB_LICENSE_PYTHON. (npm은 PRODUCT가 unqualified, pypi는 labradordb. 명시 — 컴포넌트마다 default DB 가정이 달라 주의.) - scraper 이름: pypi_package_update, pypi_package_list_full_scan, pypi_crawling, pypi_crawling_incremental, pypi_crawling_resync. - --workers 동시 워커 옵션 있음(pypi_crawling* 대상).

계열 B — labrador_sqlmodel BaseScraper, RAW→VERSION→PRODUCT 3단

git repo를 PVC(/resources)에 clone해 파일/레시피를 파싱하는 3단 스크래퍼. 각 단계가 별도 scraper로 등록되어(find_scraper) 순서대로 호출된다: RAW(원본 추출) → VERSION(버전 생성) → PRODUCT(최신버전→product). SQLModel BaseRecord 모델 + 생태계별 전용 테이블(공유 TB_COMP_LIB_PRODUCT 아님).

clone → /resources/conan-center-index. - 단계/scraper: conan_raw(ConanCrawler/ConanIncrementalCrawler) → conan_version(ConanVersionCreator) → conan_product(ConanProductCreator). - 테이블: TB_COMP_LIB_CONAN_RAW(CONAN_DATA_YML/RECIPE_FOLDER/LIBRARY_FOLDER) → TB_COMP_LIB_VERSION_CONAN(UNIQUE (CONAN_RAW_ID, VERSION)) → TB_COMP_LIB_PRODUCT_CONAN.

/resources/vcpkg. LANGUAGE='c_cpp'(version은 'C/CPP'), REPOSITORY/REPOSITORY_NAME='VCPKG'. - 단계/scraper: vcpkg_raw(VCPKGRAWCrawler) → vcpkg_version(VCPKGVersionCrawler/VCPKGVersionIncrementalCrawler) → vcpkg_product(VCPKGProductCrawler). - 테이블: TB_COMP_LIB_VCPKG_RAW → TB_COMP_LIB_VERSION_VCPKG → TB_COMP_LIB_PRODUCT_VCPKG. tests/ 디렉토리 보유(단일 product 버전수 검증 등). - version 수집 = registry 기반(2026-07-07, 0cfa080): vcpkg_registry.py가 versions/<x>-/<port>.json을 열거(oldest-first, #N dedup) 후 각 entry의 git-tree에서 git show로 vcpkg.json 또는 CONTROL(전용 파서) 읽음 → CONTROL 시절(≤2021-08) 버전 포함. registry 파일 없는 포트만 기존 vcpkg.json git-log 폴백. shallow clone이면 unshallow 가드. 백필 풀 런 2026-07-07 labCrawl1 수동 실행(갭 1,324포트/9,190버전). W28 참조.

github.com/cpp-pm/hunter clone → /resources/hunter, cmake/projects/<lib>/ 의 hunter*.cmake 파일을 파싱(FileSystemIterationBasedScraper). - crawler: HunterRawCrawler, HunterVersionCrawler, HunterProductCrawler, HunterArchiveRawCrawler + hunter_version_sorter. - 테이블: TB_COMP_LIB_RAW_HUNTER → TB_COMP_LIB_VERSION_HUNTER → TB_COMP_LIB_PRODUCT_HUNTER (+ archive raw 단계).

주의

한 곳을 고치면 나머지 점검 권장.

--eco). universe = upstream git repo 파싱(크롤러와 동일): conan=conandata.yml sources, hunter=hunter_add_version VERSION, vcpkg=ports/*/vcpkg.json의 git 히스토리(레지스트리 versions/는 CONTROL시절·port-version-suffix 때문에 8566 과다보고 → 금지, git-log가 정답). detect→extract_missing.py, backfill→backfill.py(기본 dry-run, --commit). 자세히는 W26. - ⚠️ W28 재평가(2026-07-07): 위 "과다보고 8566"에는 CONTROL 시절 실제 버전(진짜 누락)이 섞여 있음. vcpkg 크롤러는 vcpkg.json git log만 walk 하므로 포트별 매니페스트 전환(2020-06~2021-08) 이전 버전은 구조적으로 수집 불가 — 예: zeromq는 upstream distinct 36 중 4만 수집(32 결손, vcpkg.json 생성 2021-07-26). 탐지 도구도 같은 universe라 이 결손이 안 보임. 보완 방향 = registry versions/<x>-/<port>.json distinct base version + git show <git-tree>(CONTROL 파서 필요), #N suffix만 dedup. W28 참조.

등 다수 컴포넌트가 있다(ls etl_components/). 본 섹션은 라이브러리 패키지 크롤러만.

복합 PK (LANGUAGE,REPOSITORY,PRODUCT_KEY[,VERSION]), LANGUAGE='c_cpp'/REPOSITORY='Conan', CONAN_RAW_ID/auto ID 제거, version에 RAW_UPDATED 추가, product 타임스탬프 CREATED/LAST_UPDATED. DB rename 완료: 라이브 TB_COMP_LIB_VERSION_CONAN(5,676)·TB_COMP_LIB_PRODUCT_CONAN(1,929)이 신규 스키마, 옛 스키마는 *_CONAN_OLD 백업. 코드는 dat-3257/lib_crawler(5547872 스키마정렬 + 3c32f21 게이트 LAST_UPDATED). ‼️ 단, 운영 이미지가 옛 코드면 다음 크롤러 run이 깨짐 → dat-3257 머지·이미지 배포 선행 필수(미배포 시 13:00 UTC 전 DAG 정지/롤백). 옛 잔재 정리 완료(2026-06-24): 고아 TB_COMP_LIB_CONAN_VERSION(2024-10 동결) → ..._DEPRECATED 리네임(모니터 후 DROP 예정), 죽은 conan_to_comp_lib_product_op 삭제(data-platform 1f65331, 미푸시). 상세·롤백 SQL = W26 worklog.

conan 크롤러는 product를 TB_COMP_LIB_PRODUCT_CONAN 전용 테이블에만 쓴다. 공용 gatheringdb.TB_COMP_LIB_PRODUCT(REPOSITORY='Conan')로의 복사는 data-platform op conan_to_comp_lib_product_op가 했는데, 그 op가 2024-07-08경 멈춤(공용 conan MAX(CREATED)=2024-07-08) 후 2026-06-24 삭제됨. 결과: 2024-07-08 이후 추가된 conan 전부 공용 미반영 = _CONAN 1,931 vs 공용 1,634(2026-07-01), gap ~297. vuln processor·누락체크 등 공용 테이블을 읽는 소비자에겐 "누락"으로 보임(크롤러 데이터 자체는 정상). 2026-07-01 사용자 25건은 _CONAN→공용 INSERT…SELECT로 백필(공용 1,659). 근본 해결: 전파 op 복원/대체 또는 크롤러가 공용에도 upsert(+잔여 272 일괄 백필). ⚠️ vcpkg(_VCPKG)/hunter(_HUNTER)도 동일 구조 → 공용 전파 여부 점검 필요. (go/spm vuln processor 이슈와 동류 = 생태계 전용테이블 vs 공용테이블 불일치.)

Common Commands

# 로컬 실행
python3 main.py --scraper <name> --source-db <url> --target-db <url> \
  --log-to-console --log-level INFO
# openssf_mal 강제 full reconcile
python3 main.py --scraper openssf_mal --source-db <url> --target-db <url> \
  --scraper-args "full_reconcile=true"

# 커밋 전 로컬 훅 검사(도구 필요): black/isort/pylint/mypy
black --check --line-length 79 --target-version py312 --skip-string-normalization *.py
isort --check-only -m 3 *.py
pylint -d all -e W0611,W0612,W0613 *.py

Known Pitfalls

(FWK|DAT)-[0-9]+ 티켓을 추출(tr로 대문자화 — bash 3.2 OK). main에선 추출 실패 → exit 1. 반드시 DAT-xxxx/... feature 브랜치에서 커밋 후 main으로 FF 머지.

필수. 누락 시 커밋 거부.

PATH="<venv>/bin:$PATH" git commit으로 훅이 도구를 찾게 한다.

git fetch/rev-parse가 거부됨. 해결: safe.directory를 글로벌 config로 등록해야 하고 (-c/CLI는 git이 보안상 무시), 베이스가 bullseye=git 2.30.x라 GIT_CONFIG_GLOBAL (2.32+)·safe.directory=*(2.35.2+)가 안 먹힘. → HOME의 .gitconfig에 * + 명시 repo 경로를 둘 다 등록(명시 경로는 전 버전 지원). openssf_mal repo_sync.py 참고.

:73-80 이 호출 시점에 loggerDict 의 모든 기존 named 로거에 handler 부착 + propagate=True + setLevel(level) 을 강제. 부작용 2가지 — ① 중복 로깅: setup 이전에 생성된 named 로거(모듈 최상단 import 로 getLogger(__name__) 실행)는 자기 handler + root 전파로 2회 출력. ② 레벨 억제 무효화: import 시점에 낮춰둔 레벨 (예: sqlalchemy.engine=WARNING)이 run --log-level 로 되돌려짐. 회피: 노이즈 로거는 메서드/__init__ 내부 지연 import(setup 이후 생성)로 두거나 setup 호출 직후 레벨 재설정. 사례: hunter LicenseeUtil ×2(2af380b), npm SQLAlchemy echo 가 ERROR 로 오탐 (echo 억제가 setup 에 덮임 — 데이터에 "ERROR" 든 패키지에서 모니터 오탐). 상세 W28 worklog.

컴포넌트: comp_lib_vuln_processor (취약점 → product 매핑)

매핑/업데이트/삭제. repository별 언어 = base_mapper.REPOSITORY_TO_LANGUAGE (maven/npm/composer/pypi/rubygems/golang/cocoapods/spm/nuget/hunter/vcpkg/conan).

그 외 전부 → labradordb.TB_COMP_LIB_PRODUCT. 위치: base_mapper._setup_table_names(:94), db._get_comp_lib_table_name(:258), comp_lib_vuln_deletor(:95), comp_lib_vuln_data_integrator(:84). UPSERT = INSERT ... (LANGUAGE,REPOSITORY,PRODUCT_KEY,VULN_RANGE) ON DUPLICATE KEY UPDATE VULN_RANGE (db.UPSERT_COMP_LIB_PRODUCT_QUERY).

[go 수정완료 05a76da(main), spm 잔여 | 2026-07-01] go(및 spm) product를 잘못된 labradordb 구 테이블에 씀

수정(2026-07-01, main 05a76da): db.py에 단일 리졸버 resolve_comp_lib_product_table(repository) 신설, 4곳(db._get_comp_lib_table_name/base_mapper._setup_table_names/comp_lib_vuln_deletor/ comp_lib_vuln_data_integrator)이 전부 이걸 경유. golang → gatheringdb.TB_COMP_LIB_PRODUCT_GOLANG (REPOSITORY/PRODUCT_KEY/VULN 컬럼 보유 → upsert/join 불변). conan/vcpkg/hunter·나머지 불변. spm 잔여: TB_COMP_LIB_PRODUCT_SPI가 REPOSITORY 대신 PACKAGE_MANAGER 컬럼이라 REPOSITORY 기반 upsert/join과 불호환 → 별도 컬럼매핑 필요(이번 커밋 제외, labradordb 유지). py_compile OK, 테스트 없음· 로컬 deps 미설치라 런타임/DB 동작은 이미지에서 확인 필요. 아래는 원 진단.

이관했는데, vuln processor의 2분기 로직은 go(repository='golang')를 "그 외"로 보고 labradordb.TB_COMP_LIB_PRODUCT(마이그레이션 전 동결 사본, 2026-05-28 CREATED 멈춤)에 UPSERT. → ① gatheringdb의 신규 go product는 취약점(VULN_RANGE) enrichment를 못 받음, ② 옛 labradordb go 행만 재기록돼 LAST_UPDATED(on update CURRENT_TIMESTAMP)만 bump (실측 product 50건/30d). SPM도 동일 위험(gatheringdb.TB_COMP_LIB_PRODUCT_SPI인데 현재 labradordb로 감).

(no-flag/resync 추정), vuln processor와 무관.

보유 → DDL 불필요. (as_cs 케이스구분 = go 정체성 일치.)

통일. 매핑: conan/vcpkg/hunter→gatheringdb.TB_COMP_LIB_PRODUCT, golang→gatheringdb.TB_COMP_LIB_PRODUCT_GOLANG, spm→gatheringdb.TB_COMP_LIB_PRODUCT_SPI(검증 후), 그 외→labradordb.TB_COMP_LIB_PRODUCT(현행). UPSERT/JOIN 불변, 테이블명만 리졸버 경유. 옵션: 기존 labradordb go VULN_RANGE→PRODUCT_GOLANG 일회성 백필. 단위테스트로 매핑 검증. 상세 W27 worklog(2026-07-01).

Current Work

실행 검증은 이미지 재빌드 후 진행 중(PVC clone 소유권 통과 확인, 이후 적재 검증 예정).