자체 빌드 이미지 3종 docker.io/paasup 재빌드·push + 카탈로그 values 갱신

cloudnative-pg·cnpg-postgresql·etcd 를 REGISTRY=docker.io/paasup 로 재빌드해
verify.sh·게이트(커버리지 ok, 실효 C/H 0/0, PASS) 확인 후 push, docker manifest
inspect 로 레지스트리 존재를 재확인했다. 기존 참조(docker.io/wbsong111, 이전
security-catalog 빌드)는 dip-catalog 자체 파이프라인으로 검증된 적이 없었다.

카탈로그 values(custom-values.yaml/dip-values.yaml)를 patch-catalog-tag.py 로
새 태그로 교체하고 helm template·extract-helm-images.sh 로 렌더링 결과를
재확인했다. 로컬 docker 계정은 paasup push 권한이 확인됐으나 GitHub Actions
시크릿(DOCKERHUB_USER/TOKEN)의 권한은 별도 확인이 필요하다(MEMORY.md).

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

MEMORY.md

@@ -22,28 +22,37 @@
 우선순위(상위 태그 교체 → 베이스 OS 교체 → 자체 빌드 → 예외 승인)를 검토하고, 예외는
 근거·만료일을 명시해 추가한다.
 
-**커버리지 자가진단(`CoverageProbe`)이 이식되지 않았다.** security-catalog 의
-`scan-sbom.sh` 는 센티널 패키지 주입 재스캔으로 "0건"과 "측정되지 않음"을 구분하지만,
-dip-catalog 의 `scan-sbom.sh` 는 이 로직이 없다 — 게이트는 findings 총계 0건을 보수적으로
-차단 처리하는 구버전 경로로만 동작한다. 45+ 차트 규모에서 이 판정이 오탐을 얼마나
-내는지 실측 후 이식 여부를 결정한다.
+**커버리지 자가진단(`CoverageProbe`)을 security-catalog 에서 이식했다(2026-08-03).**
+`scan-sbom.sh` 가 os-pkgs findings 0건인 이미지의 SBOM 사본에 배포판별 센티널 패키지
+(deb/rpm/apk)를 주입해 재스캔하고, 발화 여부로 `CoverageProbe`(ok|none|n/a)를 리포트에
+기록한다 — `cve-gate.py` 는 이미 이 키를 읽도록 구현돼 있었으므로 소비 쪽 변경은 없다.
+로컬에서 rpm(SUSE)·deb(Debian)·apk(Alpine) 세 경로 전부 실측 검증했고, 병렬 스캔(여러
+SBOM 동시 처리)에서도 회귀 없음을 확인했다. **이 이식으로 아래 "images/ 3종" 항목의
+결과가 실제로 바뀌었다** — cloudnative-pg·cnpg-postgresql 이 전에는 "데이터 커버리지
+이상"으로 FAIL 했으나(findings 가 전 심각도 0건이라 구버전 로직이 "측정 안 됨"으로 오판)
+CoverageProbe 이식 후 재게이트하니 셋 다 `커버리지 ok, 실효 C/H 0/0, PASS` 로 나온다
+(양성 대조로 재확인: 같은 SBOM 에 오래된 취약 curl 버전을 주입해 재스캔하면 SUSE-SU
+어드바이저리가 정상 검출됨 — trivy 의 SLES 15.7 커버리지 자체는 문제 없었다).
 
-**`images/`에 이미지 3종(`cloudnative-pg`, `cnpg-postgresql`, `etcd`)이 security-catalog
-프로젝트에서 포팅됐지만 dip-catalog 자체 CI(`build-image.yml`)로는 아직 한 번도
-빌드·게이트·push 를 실행해본 적이 없다.** 현재 카탈로그 values(`custom-values.yaml`/
-`dip-values.yaml`)가 참조하는 태그는 전부 security-catalog 쪽에서 이미 빌드·게이트
-PASS·push 된 실제 이미지(`docker.io/wbsong111/...`)를 그대로 재사용하는 것이다 —
-dip-catalog 파이프라인으로 재현·재검증된 적은 없다. 최종 런타임 베이스 OS 정책은
-security-catalog 의 SUSE BCI 고정 결정을 그대로 따랐다(ADR 자체는 미이관, 아래 참고).
+**`images/`의 이미지 3종(`cloudnative-pg`, `cnpg-postgresql`, `etcd`)을 `docker.io/paasup`
+로 재빌드·게이트·push 완료했다(2026-08-03).** `REGISTRY=docker.io/paasup` 로 빌드 →
+`verify.sh` 전부 VERIFY-OK → 게이트 셋 다 `커버리지 ok, 실효 C/H 0/0, PASS` → push ​→
+`docker manifest inspect` 로 레지스트리 존재 재확인:
+- `docker.io/paasup/cloudnative-pg:1.30.0-security-hardened-20260803`
+- `docker.io/paasup/cnpg-postgresql:18.4-bci15.7-hardened-20260803`
+- `docker.io/paasup/etcd:3.7.1-security-hardened-20260803`
 
-**레지스트리 마이그레이션(`docker.io/wbsong111` → `docker.io/paasup`)이 필요하다.**
-`build-image.yml` 의 `REGISTRY_HOST` 는 이미 `docker.io/paasup` 로 설정돼 있지만
-(아래 항목 참고) 위 3개 이미지가 실제로 가리키는 곳은 아직 `docker.io/wbsong111` 다.
-`REGISTRY=docker.io/paasup` 로 3개 이미지를 재빌드·재게이트·재검증해 PASS 를 확인한
-뒤에만 6개 values 파일(`manifests/helm/{cloudnative-pg/0.29.0,cnpg-cluster/1.0.0,
-etcd/1.1.12}/{custom-values,dip-values}.yaml`, cnpg-cluster 는 `dip-values.yaml` 도
-`imageName` 오버라이드가 있음)의 이미지 참조를 새 태그로 교체한다. push 자격 증명
-확인은 바로 아래 항목과 동일하다.
+카탈로그 values 6개 파일(`manifests/helm/{cloudnative-pg/0.29.0,cnpg-cluster/1.0.0,
+etcd/1.1.12}/{custom-values,dip-values}.yaml` — etcd 는 `dip-values.yaml`에 image
+오버라이드 없어 5개만 실제 갱신)도 `patch-catalog-tag.py`로 새 태그로 교체하고
+`helm template`·`extract-helm-images.sh` 로 렌더링 결과까지 재확인했다.
+`DOCKERHUB_USER`/`DOCKERHUB_TOKEN` 은 `paasup` 조직에 push 권한이 있음을 이번에
+확인했다(기존 "미확인" 상태 해소). 최종 런타임 베이스 OS 정책은 security-catalog 의
+SUSE BCI 고정 결정을 그대로 따랐다(ADR 자체는 미이관, 아래 참고).
+
+**남은 것: `SBOM_PIPELINE_IMAGE`(sbom.yml 이 쓰는 실행 컨테이너)는 이번 마이그레이션
+대상이 아니다** — 여전히 `docker.io/wbsong111/sbom-pipeline:latest` 를 가리킨다.
+이건 이미지 3종과 무관한 별개 결정(아래 미결 결정 참고).
 
 **`doc/decisions/`·`doc/analysis/` 디렉토리 자체가 dip-catalog 에 없다.** 포팅된 3개
 이미지의 README·values 코멘트가 `doc/decisions/000X-*.md`, `doc/analysis/*.md`,
@@ -64,11 +73,11 @@ requests/limits/storage 값을 근거로 표를 추가하는 별도 작업으로
 않지만, `paasup` 네임스페이스로 이전할지는 별도 결정이 필요하다. **재빌드 + push +
 Repo Variable `SBOM_PIPELINE_IMAGE` 갱신은 git 커밋으로 되지 않는 수동 작업**이다.
 
-**`build-image.yml` 의 `REGISTRY_HOST` 를 `docker.io/paasup` 로 설정했다.** 실제 이미지를
-push 하려면 `DOCKERHUB_USER`/`DOCKERHUB_TOKEN` 시크릿이 `paasup` 조직 네임스페이스에
-push 권한을 가져야 한다 — **미확인**, 실제 첫 자체 빌드 시도 전에 확인 필요. 이제
-`images/` 의 3개 이미지가 실사용 후보이므로 위 "레지스트리 마이그레이션" 항목이 이
-확인을 실제로 필요로 하는 첫 사례다.
+**`build-image.yml` 의 `REGISTRY_HOST` 를 `docker.io/paasup` 로 설정했다.** 로컬에서
+`docker login docker.io` 로 로그인한 계정은 `docker.io/paasup` 에 push 권한이 있음을
+위 3종 이미지 push 로 확인했다. **단, 이건 로컬 자격증명 확인일 뿐이다** — GitHub
+Actions 시크릿(`DOCKERHUB_USER`/`DOCKERHUB_TOKEN`)이 같은 계정/권한인지는 별도 확인이
+필요하다(`build-image.yml` workflow_dispatch 를 실제로 한 번 돌려봐야 안다).
 
 ---
 
@@ -78,10 +87,6 @@ push 권한을 가져야 한다 — **미확인**, 실제 첫 자체 빌드 시
 "45+ 차트 미검증" 문제 해소 후 결정한다. branch protection(필수 상태 체크)도 게이트
 강제와 짝을 이뤄야 의미가 있다 — 지금은 미설정.
 
-### scan-sbom.sh 커버리지 자가진단 이식 여부
-위 "다음 작업" 참고. 이식하면 dip-catalog scan-sbom.sh 와 security-catalog 버전의
-동작 차이가 사라지지만, 스캔 시간이 늘어난다(대상별 추가 재스캔).
-
 ### SBOM_PIPELINE_IMAGE 재빌드/네임스페이스 전환
 결정 나면 `docker.io/paasup/sbom-pipeline:...` 로 빌드·push 하고 Repo Variable
 `SBOM_PIPELINE_IMAGE` 를 갱신한다(수동, out-of-band).