wbsong111
4f67f63f69
## doc/sbom-pipeline.md — 중복·모순 정리 (328 → 286줄) 같은 사실이 여러 절에 흩어져 있었고, 일부는 문서가 아니라 변경 이력이었다. - `SEVERITY` 를 전 심각도로 덮어써야 하는 이유가 환경변수 절·CI 절·요약 절 3곳에 있었다. 스크립트 절의 blockquote 하나로 합쳤다 — "게이트를 돌릴 거라면 전 심각도로 스캔해야 한다"가 핵심이고 나머지는 그 결과다. - Job Summary 1MB 제한이 CI 절과 결과 확인 절에 중복됐다. CI 절 하나로 합쳤다. - `--warn-only` 서술이 mermaid 라벨·CI 절·게이트 절·트리아지 절 4곳에 있었다. 게이트 절 하나로 합치고, `build-image.yml` 쪽은 이미 강제라는 대비를 함께 적었다. - 자체 빌드 트리거 표가 "PR 은 push 안 함"을 말하는데 바로 아래 불릿이 같은 말을 반복했다. 표는 그대로 두고 불릿은 **왜** 그런지(REGISTRY 미전달 → localhost 태그라 push 를 시도할 수조차 없다)만 남겼다. - "오해를 주던 단일 '총 소요'는 제거" 같은 변경 이력 서술을 걷어냈다. 문서는 현재 상태를 적는 곳이다. - "첫 전체 실행 결과(2026-07-08)" 절은 수치를 싣고 바로 아래에서 "현재 수치가 아니다"로 무효화하는 구조였다. 절 자체를 없애고, 거기서 유일하게 쓸모 있던 사실 (SBOM 생성 실패는 대부분 사설/미인증 레지스트리이거나 대용량 timeout)만 스크립트 절로 옮겼다. - "실행 이력(2026-08-04)" 절은 MEMORY.md 와 중복이라 제거했다. 거기서만 알 수 있던 사실(Actions 시크릿의 push 권한 확인)은 GitHub 설정 표에 반영했다. - `CVE_API_KEY` 가 본문에만 있고 GitHub 설정 표에 빠져 있어 추가했다. - 아키텍처 절 불릿이 mermaid 서브그래프 라벨과 같은 말을 하고 있어, "pull 을 ② 한 곳에 몰아둔 것이 핵심"이라는 결론 한 문장으로 줄였다. ## 이미지 목록을 문서에 박아두지 않는다 이미지는 계속 추가되므로 열거하면 추가할 때마다 낡는다. `images/` 디렉토리를 단일 출처로 삼고 CLAUDE.md·image-authoring.md·build-image.yml·sbom-pipeline.md 의 열거를 걷어냈다. keycloak README 의 베이스 OS 결정 근거도 "기존 3종" 대신 "먼저 들어온 이미지들"로 바꿨다 — 근거의 내용은 그대로다. ## 현황 서술 정정 - build-image.yml 주석이 "아직 도입된 자체 빌드 이미지가 없다(images/ 가 비어 있음)" 로 남아 있었다. 이 레포 CI 에서 빌드→검증→게이트→push→카탈로그 브랜치 push 까지 실제로 검증된 상태다. - MEMORY.md: cve-exceptions.json 첫 예외 등록, 베이스 OS 정책 확정, PR 자동 생성이 조직 정책으로 불가하다는 실측(run 30882785612)을 반영했다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
7.7 KiB
현재 상태 · 미결 결정
작업을 이어받을 때 여기서 시작한다. 지금 시점의 상태와 다음에 할 일만 담는다.
- 프로젝트 개요·설계 원칙 → CLAUDE.md
- SBOM·CVE 게이트 메커니즘 → doc/sbom-pipeline.md
최종 갱신: 2026-08-07
다음 작업
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-20260803docker.io/paasup/cnpg-postgresql:18.4-bci15.7-hardened-20260803docker.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).