wbsong111
a9720af69b
etcd·cloudnative-pg·apisix-ingress-controller 가 GO_BUILDER_TAG=1.26.5-trixie 에 핀돼 있어 새로 공개된 stdlib 차단 CVE 8건에 걸린다. 전부 Go 1.26.6 에서 고쳐졌다. 소스는 하나도 안 바꿨다 — CVE 데이터가 갱신됐을 뿐이다. 자체 빌드 이미지는 이렇게 가만히 있어도 게이트를 벗어난다는 것이 이번 사례의 요지다. 발견 경위 -------- PR #34(문서 전용)가 images/** 를 건드려 검증 빌드가 돌면서 드러났다. 오늘 날짜로 재빌드하니 etcd·cloudnative-pg 가 각각 실효 0/8 로 FAIL 했고, 기능 검증(verify.sh)은 둘 다 VERIFY-OK 였다 — 게이트만 실패했다. 대조군으로 어제 1.26.6 으로 올린 argocd 는 같은 실행에서 PASS 했다. 값은 손으로 고르지 않았다 ------------------------ python3 scripts/build/suggest-go-upgrades.py --reports <trivy-reports> → GO_BUILDER_TAG=1.26.6-trixie / 모듈 업그레이드 제안 없음(stdlib 전용) FixedVersion 의 `1.25.13, 1.26.6, 1.27.0-rc.3` 은 브랜치별 대안이라 최대값을 고르면 프리릴리스를 정식 버전으로 오독한다. 스크립트가 그 규칙을 처리한다. apisix-ingress-controller 는 이번 검증 빌드 대상이 아니었다 -------------------------------------------------------- PR #34 가 이 이미지 파일을 건드리지 않아 매트릭스에서 빠졌을 뿐, 같은 툴체인 핀이다. trivy 는 바이너리에 박힌 Go 버전으로 stdlib 을 판정하므로 1.26.5 로 빌드한 Go 바이너리는 예외 없이 해당된다. 이 PR 의 검증 빌드가 셋 다 돌려 확인한다. 각 build.env 주석에 "이 값은 go.mod 최소 요구가 아니라 stdlib 차단 CVE 를 해소하는 지점으로 정한다" 를 적어뒀다 — 다음 사람이 go.mod 만 보고 되돌리지 않게 하기 위함이다. Refs #35 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
etcd — 자체 빌드
etcd 서버/etcdctl/etcdutl 바이너리를 업스트림 소스에서 직접 컴파일한다.
manifests/helm/etcd/1.1.12/custom-values.yaml 의 image.repository/image.tag 가
이 산출물을 가리킨다.
security-catalog 프로젝트에서 포팅했다. 채택 결정과 받아들인 비용은 ADR 0004, 이 차트를 고른 이유는 ADR 0003, 게이트·SBOM 파이프라인은 doc/sbom-pipeline.md, 신규 자체 빌드 이미지 추가 절차 전반은 .claude/image-authoring.md 가 갖는다. 아래 CVE 번호는 자체 빌드에 착수한 시점의 근거다 — 현재 수치는 게이트가 낸다.
자체 빌드는 대응 우선순위 3번이다. 상위 태그 교체·베이스 OS 교체로 목표를 만족할 수 있으면 그 쪽을 쓴다. 자체 빌드는 업스트림 서명·provenance·SBOM attestation 을 잃고 재빌드 책임을 지는 선택이다.
왜 자체 빌드하나 — 그리고 왜 cloudnative-pg 와 같은 방법인가
업스트림 quay.io/coreos/etcd:v3.7.1 은 실효 HIGH 1건(CVE-2026-56852,
golang.org/x/text — 깨진 UTF-8 입력에 대한 norm.Iter 무한루프 DoS)으로 차단된다.
상위 태그가 없다(2026-07-31 확인, 최신 릴리스가 여전히 v3.7.1이고 release-3.7
브랜치도 아직 이 CVE 를 백포트하지 않았다). 업스트림 배포 이미지 베이스가
gcr.io/distroless/static-debian12(OS 패키지 사실상 0개)라 베이스 OS 를 바꾸는 것만
으로는 고쳐지지 않는다 — CVE 는 바이너리에 정적 링크된 Go 모듈 버전이 원인이다.
자체 빌드(소스 컴파일)만 유효한 대응이다.
이는 cloudnative-pg 오퍼레이터 자체 빌드와 완전히 같은 유형의 문제(같은
CVE-2026-56852)이고 대응도 같다 — 오케스트레이션은 동일한
scripts/build/build-hardened-image.sh
하나를 공유한다.
소스·버전 관리
| 항목 | 값 |
|---|---|
| 소스 | https://github.com/etcd-io/etcd.git |
| pinned commit | source.build.env 의 SOURCE_COMMIT — v3.7.1 태그가 가리키는 실제 커밋 |
| 빌더 | 공식 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 이미지를 그대로 쓴다 — 최종 이미지에 남는 것이
아니라 컴파일 산출물만 최종 스테이지로 넘어오므로 스캔·정책 대상이 아니다.
업스트림과 다른 부분은 딱 하나다 — golang.org/x/text 를 워크스페이스 전역
go.work replace 한 줄로 0.39.0 이상으로 강제 업그레이드한다(각 서브모듈의
go.mod 를 개별로 고치지 않는다). 그 외 빌드 절차(server/etcdutl/etcdctl 세
바이너리를 각각 컴파일, CGO_ENABLED=0 정적 링크)는 업스트림
scripts/build_lib.sh 의 etcd_build() 를 그대로 재현한다.
SOURCE_COMMIT 은 자동 추적하지 않는다. cloudnative-pg 와 동일하게 사람이
업스트림 release-3.7 브랜치(또는 그다음 패치 릴리스가 나오면 그 태그)를 보고
source.build.env 를 고쳐 PR 을 여는 것 자체가 갱신 트리거다.
권장 점검 주기: 카탈로그 게이트가 이 이미지의 차단 CVE 를 다시 보고할 때, 또는
업스트림이 v3.7.2(혹은 그 이상, x/text 백포트 포함)를 릴리스했을 때 — 릴리스가
나오면 그쪽으로 갈아타는 것(대응 우선순위 a)이 이 자체 빌드를 유지하는 것보다 항상
우선이다.
빌드
# 로컬 빌드 (push 없음)
IMAGE=etcd BASE_OS=source bash scripts/build/build-hardened-image.sh /tmp/out
# 레지스트리에 push 까지 (현재 실제 배포 이미지도 이 네임스페이스에 있다)
IMAGE=etcd BASE_OS=source REGISTRY=docker.io/wbsong111 \
bash scripts/build/build-hardened-image.sh /tmp/out
수행 순서: 빌드 → 기능 검증(verify.sh) → SBOM → 전 심각도 스캔 → 게이트 판정.
verify.sh 는 etcd/etcdctl/etcdutl 이 PATH 에 있는지, etcd --version 출력에
pinned commit 이 실제로 반영됐는지(ldflags 주입 확인), 단일 노드로 기동해 etcdctl
put/get 왕복이 실제로 동작하는지를 확인한다 — 다중 노드 쿼럼·TLS 등은 이 스모크 테스트
범위 밖이며, dev 클러스터 배포 테스트(.claude/deploy-test-procedure.md,
scripts/deploy-test/deploy-test-etcd.sh)가 담당한다.
파일 구성
| 파일 | 역할 |
|---|---|
source.Dockerfile |
빌드 정의 — 소스 컴파일(builder 스테이지) + SUSE BCI(bci-micro) 패키징(final 스테이지) |
source.build.env |
pinned commit·버전·빌더 이미지 태그. BUILD_ARGS 에 나열한 이름만 --build-arg 로 전달된다 |
verify.sh |
기능 검증. 호스트에서 bash 로 실행되며 docker run --entrypoint sh 로 게스트 셸 스크립트를 주입한다(bci-micro 는 bash·coreutils 가 있다 — cnpg-postgresql/verify.sh 와 같은 패턴, cloudnative-pg 의 셸 없는 distroless 와는 다르다) |
베이스 변종이 하나뿐이라 파일명이 source.* 로 고정돼 있다.
태그
docker.io/wbsong111/etcd:3.7.1-security-hardened-20260731
└ app ┘└ 슬러그 ┘└ 하드닝 ┘└ 빌드일 ┘
이 태그는 security-catalog 프로젝트에서 이미 빌드·게이트 PASS·push 된 실제 이미지다.
dip-catalog 는 이를 그대로 재사용한다 — 재빌드·재푸시 여부는 MEMORY.md 참고.