자체 빌드 이미지 3종(cloudnative-pg/cnpg-postgresql/etcd) + 대응 헬름 차트 도입

security-catalog 프로젝트에서 첫 실사용 자체 빌드 이미지 3종을 포팅한다 — 전부
상위 태그·베이스 OS 교체로 해소 안 되는 CVE(Go 모듈 정적 링크 또는 미수정 CRITICAL/
HIGH)를 자체 빌드(소스 컴파일 또는 SUSE BCI 재설치)로 대응한다:

- images/cloudnative-pg: CNPG operator, release-1.30 소스 컴파일 + bci-micro
- images/cnpg-postgresql: PostgreSQL 18.4, bci-base + zypper 재설치
- images/etcd: etcd v3.7.1, 소스 컴파일(x/text 강제 업그레이드) + bci-micro

함께 추가:
- manifests/helm/{cloudnative-pg,cnpg-cluster,etcd} — 위 이미지를 참조하는 카탈로그 차트
- scripts/deploy-test/*.sh, .claude/deploy-test-procedure.md — CVE 0건과 별개로
  "실제로 뜨는가"를 검증하는 배포 스모크 테스트
- .claude/pitfalls.md — 자체 빌드/배포 테스트 중 실측한 함정 모음

검토 중 발견해 반영한 수정:
- cloudnative-pg 차트의 image 블록을 etcd와 동일한 registry/repository/tag 3필드+
  따옴표 포맷으로 통일 — 기존 포맷(repository에 registry+repo 결합, 따옴표 없음)은
  patch-catalog-tag.py 의 split 패처가 tag만 갱신하고 repository는 그대로 남기는
  조용한 부분 치환을 일으켜, 향후 레지스트리 마이그레이션 시 깨진 참조를 만들 수 있었다
- cnpg-cluster 차트의 SLES 커버리지 코멘트를 최신 실측(trivy가 SLES 15.7을 정상
  커버함, 2026-07-29 재측정)에 맞게 정정 — 폐기된 "측정 불가/OVAL 우회 필요" 결론이
  남아있었다
- CLAUDE.md/MEMORY.md 의 "images/ 디렉토리 없음" 서술을 갱신하고, 레지스트리
  마이그레이션(docker.io/wbsong111 → docker.io/paasup)·decisions/analysis 문서 이관·
  리소스 프로파일 추가를 다음 작업으로 기록

이 3개 이미지는 아직 dip-catalog 자체 CI(build-image.yml)로 빌드·게이트·push 를
실행해본 적이 없다 — 현재 참조 태그는 security-catalog 쪽에서 이미 검증된 것이다.

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

images/cnpg-postgresql/README.md

@@ -0,0 +1,132 @@
+# cnpg-postgresql — CloudNativePG PostgreSQL 자체 빌드
+
+CNPG 오퍼레이터가 관리하는 PostgreSQL 인스턴스 이미지를 직접 빌드한다.
+`manifests/helm/cnpg-cluster/1.0.0/custom-values.yaml` 의 `imageName` 이 이 산출물을 가리킨다.
+
+security-catalog 프로젝트에서 포팅했다. 목표 정의·이미지 선택 규칙·후보 비교 실측·이미지
+채택 결정·빌드 자동화(CI) 문서(`doc/cve-zero-pipeline.md`, `doc/image-selection.md`,
+`doc/analysis/cnpg-image-vuln-comparison.md`, `doc/decisions/0001-cnpg-postgresql-image.md`,
+`doc/architecture/build-pipeline.md`)는 security-catalog 프로젝트에 있고 dip-catalog 에는
+아직 이관되지 않았다.
+
+> **자체 빌드는 대응 우선순위 3번이다.** 상위 태그 교체·베이스 OS 교체로 목표를
+> 만족할 수 있으면 그 쪽을 쓴다. 자체 빌드는 업스트림 서명·provenance·SBOM attestation 을
+> 잃고 재빌드 책임을 지는 선택이다.
+
+---
+
+## 왜 자체 빌드하나
+
+업스트림 `ghcr.io/cloudnative-pg/postgresql:18.4-standard-trixie` 는 실효 CRITICAL/HIGH
+23건을 갖고 있고, **전부 수정 버전이 없다**(Debian `unimportant` 9 / `no-dsa` 7 /
+`postponed` 3 / 미분류 4). SUSE 는 같은 CVE 들을 이미 백포트했다 — 베이스 OS 를 바꾸면
+벤더 판정이 달라진다.
+
+**단, 수치가 낮아진 것이 실제 개선인지 벤더 미평가인지 반드시 구분해야 한다.**
+`cve-gate.py` 의 교차 검증(`--crossref`)이 이를 돕는다. security-catalog 의
+`scan-sbom.sh` 가 제공하던 커버리지 자가진단(`CoverageProbe`)은 dip-catalog 의
+`scan-sbom.sh` 에는 아직 없다(`doc/sbom-pipeline.md` 참고).
+
+## 베이스 OS
+
+이 이미지는 **SUSE BCI 15.7** 로 빌드됐다(security-catalog 프로젝트 ADR, 미이관).
+
+| 파일 | 베이스 | 패키지 관리자 | 측정 가능성 |
+| --- | --- | --- | --- |
+| `suse.Dockerfile` | `registry.suse.com/bci/bci-base:15.7` | zypper + PGDG rpm | ✅ trivy 로 완전 측정 |
+
+`ubuntu:24.04` 기반 빌드(후보 B)는 security-catalog 프로젝트에서 검토 후 제거됐다 —
+카탈로그가 채택하지 않아 재빌드되지 않은 채 낡아가고 있었다(빌드 하루 만에 findings
+38 → 46). 관련 실측은 이관되지 않았다.
+
+### 업스트림과의 차이
+
+**원칙: 업스트림 Dockerfile 과의 차이를 최소로 유지한다.** 패키지 구성·uid·확장 목록을
+임의로 줄이면 오퍼레이터가 이미지에 기대하는 조건이 깨진다.
+
+`suse.Dockerfile` 은 업스트림 CNPG(Debian/apt/PGDG-deb)를 SUSE(zypper/PGDG-rpm)로
+이식한 것이라 저장소 설정·패키지명·경로가 전부 다르다. 대응 관계는 파일 상단 주석 참고.
+
+`patched` 단계의 `zypper update -y` 가 실제로 기여한 몫: 베이스 이미지는 주기적으로만
+재빌드되므로 배포판 아카이브보다 뒤처져 있다. 이 단계가 없으면 그 시점의 미패치 취약점이
+그대로 남는다 — 자동 재빌드가 필요한 이유가 이것이다.
+
+### 업스트림 빌드 레시피 변경 점검 (수동, 자동화 대상 아님)
+
+`cloudnative-pg/postgres-containers` 저장소가 자체 Dockerfile 구조를 바꾸면(새 확장,
+새 하드닝 단계 등) 이 포트도 따라가야 한다. **CI 로 자동 감지하지 않는다** — 배포판이
+달라(Debian vs SUSE) 의미 있는 diff 가 안 나온다.
+
+**권장 점검 주기: CNPG 마이너 릴리스마다.** 업스트림 Dockerfile 을 훑어보고 구조가
+바뀌었으면 `suse.Dockerfile` 을 손으로 다시 이식한다.
+
+---
+
+## 빌드
+
+```sh
+# 카탈로그가 쓰는 베이스 OS (기본값)
+IMAGE=cnpg-postgresql BASE_OS=suse bash scripts/build/build-hardened-image.sh /tmp/out
+
+# 레지스트리에 push 까지 (현재 실제 배포 이미지도 이 네임스페이스에 있다)
+IMAGE=cnpg-postgresql BASE_OS=suse REGISTRY=docker.io/wbsong111 \
+  bash scripts/build/build-hardened-image.sh /tmp/out
+
+# 교차 검증을 함께 (사각지대 후보를 뽑는다. CI 에는 아직 연결되지 않았다)
+CROSSREF=/tmp/ref/standard-trixie.json IMAGE=cnpg-postgresql BASE_OS=suse \
+  bash scripts/build/build-hardened-image.sh /tmp/out
+```
+
+수행 순서: **빌드 → 기능 검증(`verify.sh`) → SBOM → 전 심각도 스캔 → 게이트 판정.**
+기능 검증을 통과하지 못하면 스캔으로 넘어가지 않는다.
+CVE 0건이어도 동작하지 않는 이미지는 카탈로그에 넣을 수 없다.
+
+### 파일 구성
+
+| 파일 | 역할 |
+| --- | --- |
+| `<base-os>.Dockerfile` | 빌드 정의 |
+| `<base-os>.build.env` | 베이스·앱 버전·확장 목록. `BUILD_ARGS` 에 나열한 이름만 `--build-arg` 로 전달된다 |
+| `verify.sh` | 기능 검증. **베이스 OS 공통** — CNPG 요구사항은 베이스와 무관하다 |
+
+베이스 OS 가 늘어도 이 구조는 그대로다 — `build-hardened-image.sh` 는 `BASE_OS` 환경변수로
+`<base-os>.build.env` 를 고른다.
+
+### 태그에 빌드일을 넣는다
+
+```
+docker.io/wbsong111/cnpg-postgresql:18.4-bci15.7-hardened-20260729
+                                     └ 앱 ─┘└ 베이스 ─┘└ 하드닝 ┘└ 빌드일 ┘
+```
+
+같은 앱 버전이라도 `zypper update` 결과가 시점마다 다르다. 롤링 태그를 피하고
+자체 이미지에도 같은 실수를 하지 않는다(빌드일 포함 고정 태그).
+
+이 태그는 security-catalog 프로젝트에서 이미 빌드·게이트 PASS·push 된 실제 이미지다.
+dip-catalog 는 이를 그대로 재사용한다 — 재빌드·재푸시 여부는 `MEMORY.md` 참고.
+
+---
+
+## 실측 (security-catalog, 2026-07-29 / trivy 0.72.0 기준)
+
+| | `bci15.7-hardened-20260728` |
+| --- | --- |
+| 커버리지 자가진단 | ✅ `ok` |
+| 전 심각도 findings | 0 |
+| 실효 고유 C/H | **0 / 0** |
+| 게이트 | **PASS** |
+
+### 채택 당시 비교 (후보 A/B/C, security-catalog 기준)
+
+| | 업스트림 `standard-trixie` (A) | Ubuntu 24.04 자체빌드 (B, 제거됨) | **SUSE BCI 15.7 (C, 채택)** |
+| --- | --- | --- | --- |
+| 패키지 수 | 148 | 147 | 182 |
+| trivy findings (전 심각도) | 316 | 46 | 0 |
+| 실효 고유 C/H | 23 | 0 | 0 |
+| 미조사 사각지대 | 0 | 18건 | 18건 |
+| 서명·attestation | ✅ | ❌ | ❌ |
+| 배포 검증 | — | ✅ failover 2초 | ✅ failover 3초 |
+| gid | `postgres` | ⚠️ `tape` | `postgres` |
+
+이 수치는 dip-catalog 에서 재측정한 것이 아니라 security-catalog 프로젝트에서 이관한
+기록이다 — dip-catalog 자체 게이트로 재확인은 아직 하지 않았다(`MEMORY.md` 참고).