service-catalog/MEMORY.md

# 현재 상태 · 미결 결정

작업을 이어받을 때 여기서 시작한다. **지금 시점의 상태와 다음에 할 일**만 담는다.

- 프로젝트 개요·설계 원칙 → [CLAUDE.md](CLAUDE.md)
- SBOM·CVE 게이트 메커니즘 → [doc/sbom-pipeline.md](doc/sbom-pipeline.md)

최종 갱신: 2026-08-12

---

## 다음 작업

**apisix@2.16.0 전체가 게이트 PASS 로 완결됐다(2026-08-12).** `images/adc/` 신규 추가로
마지막 남은 이미지까지 해소 — 차단 55건(2026-08-12 초 기준) → **0건**. adc·
apisix-ingress-controller·apisix(paasup/apisix) 세 자체 빌드 이미지 전부 게이트
실효 CRITICAL/HIGH 0/0. apisix-ingress-controller·apisix 두 이미지는 사용자가 별도
테스트 클러스터에서 **배포 검증 완료**(2026-08-12) — adc 는 아직 미완료
(`.claude/deploy-test-procedure.md` 로 apisix-ingress-controller 와 함께 배포해
dump/diff/sync 백엔드 연동까지 확인 필요).

**adc — "태그 교체로 끝난 줄 알았는데 게이트 재검증하니 아니었다".** 0.27.1→0.29.0
태그 교체 후 `custom-values.yaml`에 "게이트 PASS 확인"이라고 적어뒀는데, 이건 벤더
등급만 본 결과였다 — 실제 `cve-gate.py`(max(벤더,NVD))로 재검증하니 glibc regex/
collating 스택오버플로 4건(CVE-2019-1010022/23, CVE-2018-20796, CVE-2019-9192,
전부 libc6, Debian "affected, 수정 없음" 영구 고정)이 실효 CRITICAL/HIGH 로 여전히
차단(FAIL). `images/adc/` 자체 빌드로 해소 — 업스트림 Dockerfile
(`libs/tools/src/docker/Dockerfile`)이 `node:lts-bookworm-slim` 빌더 +
`gcr.io/distroless/nodejs24-debian13` 최종인데, **빌더 스테이지는 그대로 두고 최종
베이스 한 줄만 SUSE BCI + `nodejs24`(zypper)로 교체** — apisix/
apisix-ingress-controller 자체 빌드보다 훨씬 단순한 유형(cnpg-postgresql 과 같은
"OS 패키지 재설치형", 빌드 시간 2분 이내). SUSE 글리브C 에 이 4건이 없음을 사전에
직접 SBOM·스캔으로 검증한 뒤 진행했다. 게이트 PASS(실효 C/H 0/0).
`docker.io/paasup/adc:0.29.0-security-hardened-20260812` 로 push·카탈로그 반영 완료.
**이 사례는 일반화할 교훈이 있다 — "벤더 릴리스 노트가 CVE 를 줄였다고 명시해도, 게이트
로 직접 재검증하기 전엔 PASS 로 단정하지 않는다"**(`sbom-cve-gate`/`cve-remediation`
skill 이 이미 강조하는 원칙이지만 이번에 실제로 걸렸다).

**apisix 자체 이미지도 SUSE BCI 자체 빌드로 교체 완료(2026-08-12).** `images/apisix/`
신규 — 기존엔 별도 프로젝트(`paasup/dataup` 레포 `experiment/apisix/apisix-plugin`)에서
`apache/apisix:3.17.0-debian`(이미 최신 태그) 위에 keycloak-authz 플러그인만 얹어
빌드했는데, 그 Debian 베이스 자체가 차단 26건이었다. 문제는 이게 vanilla OpenResty가
아니라 WASM(wasmtime)·mod_dubbo 등 15개 커스텀 모듈을 정적으로 얹은 "APISIX-Runtime"
이라, apiseven 의 빌드 파이프라인(`api7/apisix-build-tools`, 태그
`apisix-runtime/1.3.6`)이 Debian/RHEL 용으로만 배포하고 SUSE 용은 없다 — vanilla
OpenResty(openresty.org 가 SLES 공식 지원)로 축소하는 것도 검토했으나, WASM·dubbo
관련 기능이 필요하다는 판단으로 커스텀 모듈 전체를 소스에서 그대로 재현하는 쪽으로
갔다. 3단계(runtime: OpenSSL/zlib/PCRE+OpenResty+6개 모듈 컴파일 → apisix-app:
luarocks 로 APISIX 앱 설치 → final: SUSE BCI 로 산출물 이관+keycloak-authz 오버레이)
빌드, 실측 함정 다수 해결(zlib→OpenSSL 순서, lua-resty-saml 의 libxml2 2.12 시그니처
불일치를 gcc 래퍼로 우회, `ui/`(admin 대시보드) 부재 허용, SUSE 공유 라이브러리
soname 등 — 상세는 `images/apisix/README.md`). 실제 nginx 기동 + HTTP 요청 응답까지
확인하는 `verify.sh` 작성(초판에 curl 연결 실패를 "000" 문자열로 오판하는 버그가
있었음 — 수정 완료). 게이트 PASS(실효 C/H 0/0, 업스트림 26건에서 완전 해소).
`docker.io/paasup/apisix:3.17.0-security-hardened-20260811` 로 push·카탈로그 반영
완료. **배포 검증 완료(2026-08-12, 사용자가 별도 테스트 클러스터에서 확인).**

**apisix 카탈로그 CVE 조치 완료(2026-08-11).** `cve-remediation` skill(신설,
`.claude/skills/cve-remediation/SKILL.md`)의 결정 절차를 처음 실제 적용한 사례. 조치 전
차단 실효 CRITICAL/HIGH 165건(2.16.0 기준, 구버전 2.14.0 포함 시 331건) → 조치 후 55건.

- **`docker.io/bitnamilegacy/etcd:latest`(차단 65건) 완전 제거** — bitnami 가 무료
  레포를 동결한 레거시 미러라 `latest` 태그만 제공(bitnami/containers#83267), 태그
  교체로 해소 불가. `etcd.enabled: false` 로 기본값을 바꾸고 카탈로그 자체 `etcd` 차트
  (`manifests/helm/etcd/1.1.12`)를 `externalEtcd` 기본 대상으로 연결했다
  (`manifests/helm/apisix/2.16.0/custom-values.yaml`).
- **`ghcr.io/api7/adc` 를 최신 태그(0.27.1)로 교체** — 완전 해소는 아니고 34→29건으로
  부분 완화(같은 debian 12.14 베이스가 계속 쓰여 OS 패키지 CVE 잔존). 상위 태그가
  이미 최신이라 추가 레버는 자체 빌드뿐 — 아직 안 함.
- **`images/apisix-ingress-controller/` 신규 자체 빌드** — 이미 최신 태그(2.1.0)인데도
  차단 25건(21건이 정적 링크 Go 모듈: stdlib/x-net/x-text/grpc/otel — 태그 교체 불가,
  나머지 4건은 distroless 베이스 OS 패키지). `v2.1.0` 태그 코드는 그대로 두고 취약
  모듈만 `go get`+`go mod tidy` 로 강제 업그레이드, 베이스는 SUSE BCI(`bci-micro`)로
  교체 → 게이트 PASS(실효 C/H 0/0). `docker.io/paasup/apisix-ingress-controller:
  2.1.0-security-hardened-20260811` 로 push·카탈로그 반영 완료. **배포 검증은 아직
  안 함**(이 세션에 클러스터 없음) — `.claude/deploy-test-procedure.md` 로 필수 수행.
- **`scripts/build/patch-catalog-tag.py` 확장** — `TAG_BLOCK` 이 점 구분 중첩 경로(예:
  `ingress-controller.deployment.image`)를 지원하도록 바꿨다(기존엔 top-level 키만
  가능). apisix 서브차트 alias 때문에 필요해짐. 기존 이미지(단일 세그먼트 `image`)
  회귀 테스트로 동작 동일함 확인.
- **`manifests/helm/apisix/2.14.0` 삭제** — 사용자 지시. 자체 빌드가 앱 버전(2.0.1)까지
  같이 올리며 두 카탈로그 버전이 서로 다른 컨트롤러 버전을 요구하는 복잡도가 생겨서,
  구버전을 유지하는 대신 최신(2.16.0) 하나로 정리했다. `doc/catalog-stack-classification.md`
  갱신 완료.
- **남은 것**: `paasup/apisix:3.17.0-keycloak-authz`(Keycloak authz 플러그인 포함 커스텀
  빌드, 차단 26건, debian 12.14 OS 패키지) — 빌드 소스가 dip-catalog 밖의 별도 프로젝트
  (`dataup experiment/apisix/apisix-plugin`)에 있어 **이 레포에서 재빌드 불가**. 그
  프로젝트에서 베이스를 갱신해야 한다.

**CVE 게이트(`scripts/pipeline/cve-gate.py`)를 도입했다 — 아직 warn-only다.** `sbom.yml`
에 게이트 판정 스텝을 추가했지만 `--warn-only` 로 실행돼 실패해도 워크플로/PR 을 막지
않는다. **45+ 개 카탈로그 차트가 이 게이트로 한 번도 트리아지된 적이 없다** — 강제
게이트(`--warn-only` 제거)로 전환하려면 먼저 전체 카탈로그 스캔 1회로 몇 개 이미지가
차단되는지 파악해야 한다. `gh workflow run helm-catalog-sbom --ref main`(또는 대상
브랜치)으로 전체 스캔 후 `cve-gate.md` 아티팩트를 확인한다.

**`doc/cve-exceptions.json` 에 첫 예외가 들어갔다(2026-08-07, keycloak 자체 빌드).**
`CVE-2025-59250` — 트리비가 같은 mssql-jdbc jar 하나로 컴포넌트를 두 개 만들어
(`13.2.1.jre11` from pom.properties / `13.2.1` from 파일명) 접미사가 잘린 쪽이 취약
범위에 매칭된 **파싱 오탐**이다. 만료 2026-11-07. 이후 차단 항목이 나오면 같은 대응
우선순위(상위 태그 교체 → 베이스 OS 교체 → 자체 빌드 → 예외 승인)를 지킨다.

**keycloak 자체 빌드로 베이스 OS 정책이 확정됐다(2026-08-07).** SUSE BCI 로 통일하되
**버전은 이미지마다 실측해서 고른다** — BCI 16.0 이 나와 있지만 SLE_BCI 의
`java-21-openjdk-headless` 가 15.7 은 `21.0.12`, 16.0 은 `21.0.11` 이라 최신 베이스가
오히려 CVE 를 남긴다. 상세: `.claude/image-authoring.md` 원칙 2,
`images/keycloak/README.md`.

**커버리지 자가진단(`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`)을 `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`

카탈로그 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 자체는 미이관), 2026-08-07 keycloak 작업에서
이 레포의 정책으로 확정됐다(위 참고).

**남은 것: `SBOM_PIPELINE_IMAGE`(sbom.yml 이 쓰는 실행 컨테이너)는 이번 마이그레이션
대상이 아니다** — 여전히 `docker.io/wbsong111/sbom-pipeline:latest` 를 가리킨다.
이건 자체 빌드 이미지와 무관한 별개 결정(아래 미결 결정 참고).

**`doc/decisions/`·`doc/analysis/` 디렉토리 자체가 dip-catalog 에 없다.** 포팅된 3개
이미지의 README·values 코멘트가 `doc/decisions/000X-*.md`, `doc/analysis/*.md`,
`doc/image-selection.md`, `doc/cve-zero-pipeline.md`, `doc/architecture/build-pipeline.md`
를 근거로 계속 인용하지만 이 경로들은 dip-catalog 에 하나도 없다(security-catalog
프로젝트에만 있음). 당장 급한 건 아니지만, 이 상태로는 이 레포만 보는 사람이 자체 빌드
결정의 CVE 실측·비교 근거를 확인할 방법이 없다 — 각 README 에 이미 요약된 근거(CVE
번호·후보 비교표)를 압축한 로컬 stub ADR 작성을 검토한다.

**`doc/define-chart-resources.md` 에 신규 차트 3종(`cloudnative-pg`, `cnpg-cluster`,
`etcd`) 의 Small/Medium/Large 리소스 프로파일이 없다.** CLAUDE.md 의 "신규 차트 추가"
규칙(리소스 프로파일 필수)을 아직 못 지켰다 — custom-values.yaml 의 기존
requests/limits/storage 값을 근거로 표를 추가하는 별도 작업으로 처리한다.

**`SBOM_PIPELINE_IMAGE` 재빌드가 보류돼 있다.** 이 마이그레이션으로 빌드 컨텍스트 경로가
`doc/scripts/Dockerfile` → `scripts/pipeline/Dockerfile` 로 바뀌었다. Dockerfile 내용
자체는 안 바뀌었으므로 기존 `docker.io/wbsong111/sbom-pipeline:latest` 는 당장 깨지지
않지만, `paasup` 네임스페이스로 이전할지는 별도 결정이 필요하다. **재빌드 + push +
Repo Variable `SBOM_PIPELINE_IMAGE` 갱신은 git 커밋으로 되지 않는 수동 작업**이다.

**`build-image.yml` 의 `REGISTRY_HOST` 를 `docker.io/paasup` 로 설정했고, CI 에서
동작을 확인했다(2026-08-04).** `workflow_dispatch` 로 `etcd`·`cloudnative-pg` 를 돌려
레지스트리 로그인 → 빌드 → `verify.sh` → SBOM → 스캔 → 게이트 PASS → push → 카탈로그
브랜치 push 까지 전부 성공했다(`build/etcd-20260804060806`,
`build/cloudnative-pg-20260804063006` 브랜치 생성 + `helm-catalog-sbom` PR 스캔 통과).
**GitHub Actions 시크릿(`DOCKERHUB_USER`/`DOCKERHUB_TOKEN`)이 `docker.io/paasup` push
권한을 갖는다는 것도 이때 확인됐다** — 기존 "로컬 자격증명만 확인" 상태 해소.

**단, PR 자동 생성은 조직 정책으로 불가하다(실측 확정).** `GITHUB_TOKEN` 으로는 PR 을
만들 수 없다(run 30882785612, GraphQL: "GitHub Actions is not permitted to create or
approve pull requests"). 리포 설정으로 못 바꾸는 제약이라 `gh pr create` 호출을
워크플로에서 제거했고(`d449504`), 브랜치 push + Job Summary 의 compare 링크까지만
자동화한다. **PR 오픈·병합 전 게이트 재확인·배포 검증은 사람의 몫이다.**

---

## 미결 결정

### 게이트 강제력 전환 시점
"45+ 차트 미검증" 문제 해소 후 결정한다. branch protection(필수 상태 체크)도 게이트
강제와 짝을 이뤄야 의미가 있다 — 지금은 미설정.

### SBOM_PIPELINE_IMAGE 재빌드/네임스페이스 전환
결정 나면 `docker.io/paasup/sbom-pipeline:...` 로 빌드·push 하고 Repo Variable
`SBOM_PIPELINE_IMAGE` 를 갱신한다(수동, out-of-band).