wbsong111
1a747f61a8
images/·manifests/helm/·.claude/ 의 20개 파일이 doc/decisions·doc/analysis 등 **이 레포에 존재한 적 없는 경로 15종을 48곳에서** 인용하고 있었다. security-catalog 에서 포팅할 때 따라온 것인데, 그 레포는 개인 레포(github.com/wbsong111/security-catalog)라 팀 구성원은 접근조차 못 한다 — "security-catalog 에 있으나 이관되지 않았다" 는 안내가 아무 역할을 하지 못했다. 원문을 통째로 복사하지 않았다 ---------------------------- 원본 문서들이 서로를 근거로 인용한다. decisions/0001 하나만 봐도 analysis/cnpg-image-baseline.md · analysis/vendor-unassessed-data-sources.md 처럼 **인용 목록에 없던 또 다른 미이관 문서**를 가리킨다. 복사는 문제를 옮기는 것이지 없애는 게 아니다. 그리고 대부분은 애초에 dip-catalog 가 더 나은 것을 갖고 있다. 7곳에서 인용되던 analysis/sles-oval-measurement.md 는 원문 스스로 "이 문서는 결정하지 않는다. 재측정하면 갱신된다" 고 밝히는 스냅샷인데, dip-catalog 는 같은 측정을 CoverageProbe 로 매 스캔마다 자동으로 한다. 문서를 복사하는 것보다 게이트를 가리키는 것이 정확하다. 그래서 성격별로 나눴다 --------------------- 재측정으로 복원 안 되는 것 → doc/decisions/ 에 자립적 ADR 로 다시 씀 (4건) 이미 단일 출처가 있는 것 → 그쪽으로 인용 교체 (11종 경로) ADR 4건은 security-catalog 0001·0005·0006·0007 이 원본이고, 결론과 근거만 추려 dip-catalog 맥락으로 새로 썼다 — **레포 밖을 가리키는 링크가 0이다.** 번호는 이 레포에서 0001~0004 로 다시 붙였고 원본 대응은 각 문서와 README 에 적었다. 왜 안 가져온 것은 안 가져왔는지도 README 표에 남겼다. 인용 교체는 카테고리별로: analysis/*-cve.md, cnpg-image-vuln-comparison.md → 해당 ADR · images/<image>/README.md analysis/sles-oval-measurement.md → 게이트 CoverageProbe (doc/sbom-pipeline.md) cve-zero-pipeline.md, architecture/build-pipeline.md → doc/sbom-pipeline.md image-selection.md → .claude/image-authoring.md charts/*/deploy-test.md → scripts/deploy-test/*.sh + 절차 문서 찾은 오류 2건 ------------- - images/cloudnative-pg/source.build.env 가 인용한 decisions/0004-cloudnative-pg-operator-self-build.md 는 **번호 오기**다. 원본 0004 는 postgresql-chart-selection 이고 이 결정은 0005 다. - cnpg-cluster values.yaml·templates/database.yaml 이 인용한 doc/deploy-test-cnpg.md 는 **원본 레포에도 없다.** CREATE EXTENSION 함정 설명은 주석 자체에 이미 있어 인용만 뺐다. 검증 ---- 우리 파일의 깨진 doc/ 인용 0건 (전수 스캔) 새 문서·수정 문서의 로컬 링크 전부 실재 확인 helm template cnpg-cluster · etcd · cloudnative-pg 정상 렌더 남은 doc/health-checking.md(144곳)·doc/integration/*(2곳)은 업스트림 CRD·차트 안의 문자열로 우리가 쓴 인용이 아니다 — 건드리지 않았다. Closes #33 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
cloudnative-pg — CloudNativePG 오퍼레이터 자체 빌드
CNPG 오퍼레이터(컨트롤러) 이미지를 업스트림 소스에서 직접 컴파일한다.
manifests/helm/cloudnative-pg/0.29.0/custom-values.yaml·dip-values.yaml 의
image.repository/image.tag 가 이 산출물을 가리킨다.
security-catalog 프로젝트에서 포팅했다. 채택 결정과 받아들인 비용은 ADR 0002, 게이트·SBOM 파이프라인은 doc/sbom-pipeline.md, 신규 자체 빌드 이미지 추가 절차 전반은 .claude/image-authoring.md 가 갖는다. 아래 CVE 번호는 자체 빌드에 착수한 시점의 근거다 — 현재 수치는 게이트가 낸다.
자체 빌드는 대응 우선순위 3번이다. 상위 태그 교체·베이스 OS 교체로 목표를 만족할 수 있으면 그 쪽을 쓴다. 자체 빌드는 업스트림 서명·provenance·SBOM attestation 을 잃고 재빌드 책임을 지는 선택이다.
왜 자체 빌드하나 — 그리고 왜 cnpg-postgresql 과 다른 방법인가
업스트림 ghcr.io/cloudnative-pg/cloudnative-pg:1.30.0 은 실효 HIGH 3건
(CVE-2026-39822 stdlib, CVE-2026-56852 golang.org/x/text, GHSA-hrxh-6v49-42gf
google.golang.org/grpc)으로 차단된다. 상위 태그가 없다(2026-07-30 확인, 최신 릴리스가
여전히 v1.30.0). 업스트림 배포 이미지 베이스가 gcr.io/distroless/static-debian13
(OS 패키지 사실상 0개)라 베이스 OS 를 바꾸는 것만으로는 고쳐지지 않는다 — CVE 는
바이너리에 정적 링크된 Go 모듈 버전이 원인이다. 자체 빌드(소스 컴파일)만 유효한 대응이다.
cnpg-postgresql(OS 베이스 교체 + zypper 패치)과 성격이 다르지만, 오케스트레이션은
동일한 scripts/build/build-hardened-image.sh
하나를 공유한다. 이 이미지가 그 스크립트의 계약(build.env 가 DOCKERFILE·TARGET·
BUILD_ARGS·APP_VERSION 선언, verify.sh 가 VERIFY-OK 로 종료)만 지키면, 이미지
종류(OS 패키지 설치형 vs 소스 컴파일형)는 스크립트가 몰라도 된다 — 근거는
.claude/image-authoring.md 참고.
소스·버전 관리
| 항목 | 값 |
|---|---|
| 소스 | https://github.com/cloudnative-pg/cloudnative-pg.git |
| pinned commit | source.build.env 의 SOURCE_COMMIT (release-1.30 브랜치) |
| 빌더 | 공식 golang 이미지 (source.build.env 의 GO_BUILDER_TAG, go.mod 요구 버전과 일치) |
| 최종 베이스 | registry.suse.com/bci/bci-micro:15.7 — security-catalog 는 SUSE BCI 하나만 쓰기로 결정했다(ADR 미이관); 업스트림의 distroless 대신 여기 적용 |
빌더 스테이지(Go 컴파일)는 공식 golang 이미지를 그대로 쓴다 — 최종 이미지에 남는 것이
아니라 컴파일 산출물만 최종 스테이지로 넘어오므로 스캔·정책 대상이 아니다. bci-micro
는 SUSE BCI 중 가장 가벼운 변종이지만 bci-base 와 달리 nonroot(uid 65532) 계정이
미리 없어 source.Dockerfile 이 직접 만든다(/etc/passwd·/etc/group 에 추가).
SOURCE_COMMIT 은 자동 추적하지 않는다. cnpg-postgresql 의 PGDG 버전처럼 사람이
업스트림 release-1.30 브랜치(또는 그다음 패치 릴리스가 나오면 그 태그)를 보고
source.build.env 를 고쳐 PR 을 여는 것 자체가 갱신 트리거다.
권장 점검 주기: 카탈로그 게이트가 이 이미지의 차단 CVE 를 다시 보고할 때, 또는
업스트림이 v1.30.1(혹은 그 이상) 을 릴리스했을 때 — 릴리스가 나오면 그쪽으로 갈아타는
것(대응 우선순위 a)이 이 자체 빌드를 유지하는 것보다 항상 우선이다.
빌드
# 로컬 빌드 (push 없음)
IMAGE=cloudnative-pg BASE_OS=source bash scripts/build/build-hardened-image.sh /tmp/out
# 레지스트리에 push 까지 (현재 실제 배포 이미지도 이 네임스페이스에 있다)
IMAGE=cloudnative-pg BASE_OS=source REGISTRY=docker.io/wbsong111 \
bash scripts/build/build-hardened-image.sh /tmp/out
수행 순서: 빌드 → 기능 검증(verify.sh) → SBOM → 전 심각도 스캔 → 게이트 판정.
scan-sbom.sh 의 커버리지 자가진단(CoverageProbe)까지 포함한다 — doc/sbom-pipeline.md
참고. dip-catalog 로컬 빌드 실측(2026-08-03): 커버리지 ok, 실효 C/H 0/0, 게이트
PASS(localhost/... 태그, push 는 아직 안 함 — MEMORY.md 참고). verify.sh 는
manager version 출력에 pinned
commit 이 실제로 반영됐는지(ldflags 주입 확인), 이미지 Config.User 가
65532:65532(nonroot)인지, --help 가 정상 종료하는지를 확인한다 — 실제 컨트롤러
기동(k8s API 필요)은 이 스모크 테스트 범위 밖이며, dev 클러스터 배포 테스트
(.claude/deploy-test-procedure.md)가 담당한다.
파일 구성
| 파일 | 역할 |
|---|---|
source.Dockerfile |
빌드 정의 — 소스 컴파일(builder 스테이지) + SUSE BCI(bci-micro) 패키징(final 스테이지) |
source.build.env |
pinned commit·버전·빌더 이미지 태그. BUILD_ARGS 에 나열한 이름만 --build-arg 로 전달된다 |
verify.sh |
기능 검증. 호스트에서 bash 로 실행되며 직접 docker run --entrypoint /manager 를 호출한다(게스트 스크립트 주입 방식보다 상위 호환 — 최종 이미지에 셸이 없는 경우에도 그대로 동작한다) |
베이스 변종이 하나뿐이라 파일명이 source.* 로 고정돼 있다 — cnpg-postgresql 처럼
변종이 늘면 <variant>.Dockerfile/<variant>.build.env 로 분기한다.
태그
docker.io/wbsong111/cloudnative-pg:1.30.0-security-hardened-20260730
└ app ─┘└ 슬러그 ┘└ 하드닝 ┘└ 빌드일 ┘
이 태그는 security-catalog 프로젝트에서 이미 빌드·게이트 PASS·push 된 실제 이미지다.
dip-catalog 는 이를 그대로 재사용한다 — 재빌드·재푸시 여부는 MEMORY.md 참고.