Files

T

wbsong111 7746570ec0 자체 빌드 이미지 프레임워크를 security-images 레포로 이관하고 카탈로그 쪽을 정리한다

images/·scripts/build/build-hardened-image.sh·suggest-go-upgrades.py·
build-image.yml·.claude/image-authoring.md·이미지 ADR(0001·0002·0004)을 삭제했다 —
전부 별도 public 레포 security-images 로 이미 이관됐다.

카탈로그 쪽에는 "무엇을 배포 중인가"를 아는 부분만 남긴다:
- catalog/image-map/<image>.env — 옛 catalog.env 의 카탈로그 레이아웃 정보만 뗀 것
- scripts/build/check-rebuild-needed.py — 드리프트 탐지(A 파트)만 남기고 핀 판단
  (B 파트: pin_changes/apply_changes/parse_module_specs)은 제거
- scripts/build/apply-published-tags.py(신규) — security-images 의 published.json
  을 읽어 카탈로그 values 를 패치
- .github/workflows/{self-build-drift-check,catalog-tag-update}.yml(신규) — 각각
  드리프트 스캔+트리거, 발행 태그 반영

effective_severity 를 cve-gate.py 로 옮겼다 — check-rebuild-needed.py 가 핀 도구를
거치지 않고 게이트를 직접 로드하게 하기 위한 선행 작업이다.

두 레포의 계약은 published.json 스키마 하나뿐이다 — security-images 는 이 카탈로그를
모른다(단방향 의존). 이관 배경·결합점 전체는
doc/migrations/self-build-images-to-security-images.md.

부수 수정: 자체 빌드 이미지를 참조하는 차트 values/README 의 죽은 링크(images/**,
doc/decisions/000{1,2,4}, .claude/image-authoring.md)를 security-images 레포를
가리키는 서술로 교체. deploy-test 스크립트·CUSTOM-README 의 개인 Docker Hub 계정
(docker.io/wbsong111) 을 docker.io/paasup 로 교체.

pitfalls.md 의 "스캐너 결과를 그대로 믿지 말 것" 절은 sbom-cve-gate skill 이 차트
축 설명에 실제로 참조하고 있어 남겼다 — "이미지 태그의 베이스 OS" 절만 제거했다
(다른 참조 없음, security-images 문서로 이관 완료).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-24 15:21:29 +09:00

3.1 KiB

Raw Blame History

name, description

name	description
sbom-cve-gate	카탈로그 이미지의 SBOM 생성·CVE 스캔·게이트 판정을 실행하거나 결과를 해석할 때 사용한다. "SBOM 만들어줘", "취약점 스캔 돌려줘", "CVE 게이트 확인", "이 이미지 CRITICAL 몇 개야", "예외 등록" 같은 요청이 해당한다. scripts/pipeline/(extract-helm-images.sh, generate-sbom.sh, scan-sbom.sh, cve-gate.py)과 sbom.yml 워크플로를 다룬다.

name

description

sbom-cve-gate

카탈로그 이미지의 SBOM 생성·CVE 스캔·게이트 판정을 실행하거나 결과를 해석할 때 사용한다. "SBOM 만들어줘", "취약점 스캔 돌려줘", "CVE 게이트 확인", "이 이미지 CRITICAL 몇 개야", "예외 등록" 같은 요청이 해당한다. scripts/pipeline/(extract-helm-images.sh, generate-sbom.sh, scan-sbom.sh, cve-gate.py)과 sbom.yml 워크플로를 다룬다.

SBOM·CVE 게이트 실행

extract-helm-images.sh → generate-sbom.sh → scan-sbom.sh(+CoverageProbe) → cve-gate.py

실행 경로 2가지

기본은 GitHub 워크플로다 — 파이프라인은 도구가 설치된 컨테이너(vars.SBOM_PIPELINE_IMAGE) 안에서 돈다.

gh workflow run helm-catalog-sbom --repo <org>/dip-catalog -f limit=3   # 빠른 검증
gh workflow run helm-catalog-sbom --repo <org>/dip-catalog              # 전체(limit=0)
gh run watch --repo <org>/dip-catalog

로컬에서 돌릴 때도 같은 컨테이너를 쓴다(정확한 docker run 명령은 doc/sbom-pipeline.md "로컬/컨테이너 실행" 참고). 레지스트리 인증이 필요하다 — TRIVY_USERNAME/TRIVY_PASSWORD(단일) 또는 DOCKER_CONFIG(다중). 빠른 검증은 generate 단계에 LIMIT=3.

결과 해석 시 반드시 볼 것

CoverageProbe를 먼저 본다. findings 0건이 "진짜 0건"인지 "스캐너가 그 배포판을 모르는 것"인지 구분하는 유일한 수단이다.

값	의미
`ok`	데이터 있음 — 0건은 진짜 0건
`none`	데이터 없음 → 게이트가 차단한다(거짓 clean)
`n/a`	OS 패키지 없음(distroless 등)

게이트는 고유 CVE 단위로 집계하고 max(벤더 등급, NVD 등급) 를 실효 등급으로 쓴다 — 벤더가 하향 평가한 CVE를 놓치지 않기 위함이다(.claude/pitfalls.md "스캐너 결과를 그대로 믿지 말 것"). 승인 예외는 doc/cve-exceptions.json(근거·만료일 필수, .trivyignore 안 씀).

현재 상태 — 게이트는 warn-only다

sbom.yml은 cve-gate.py를 --warn-only로 호출한다. 게이트가 실패해도 워크플로/PR을 막지 않는다. 45+ 카탈로그 차트가 아직 이 게이트로 트리아지된 적이 없어, 강제 전환 전에 전체 스캔 1회로 현황 파악이 선행돼야 한다.

최신 미결 사항·전환 판단 근거는 MEMORY.md를 본다 — 이 skill에 중복 기록하지 않는다.

차단 CVE 대응 우선순위

상위 태그 교체 → 베이스 OS 교체 → 자체 빌드 → 예외 승인

자체 빌드로 가야 한다면 별도 레포 security-images에서 한다 — 그 레포의 docs/image-authoring.md가 절차 단일 출처다. 판정 로직 상세는 scripts/pipeline/cve-gate.py의 모듈 docstring을 1차 출처로 본다.

참고

doc/sbom-pipeline.md — 파이프라인 상세(단계별 입출력, 실행 이미지)
doc/cve-exceptions.json — 승인 예외
.claude/pitfalls.md — 스캐너 신뢰 관련 실측 함정

3.1 KiB Raw Blame History