SBOM 파이프라인 문서 정비 + 이미지 목록 열거 제거

## 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>
This commit is contained in:
wbsong111
2026-08-07 14:27:03 +09:00
parent 4e12e38293
commit 4f67f63f69
6 changed files with 198 additions and 87 deletions
+28 -11
View File
@@ -5,7 +5,7 @@
- 프로젝트 개요·설계 원칙 → [CLAUDE.md](CLAUDE.md)
- SBOM·CVE 게이트 메커니즘 → [doc/sbom-pipeline.md](doc/sbom-pipeline.md)
최종 갱신: 2026-08-03
최종 갱신: 2026-08-07
---
@@ -18,9 +18,17 @@
차단되는지 파악해야 한다. `gh workflow run helm-catalog-sbom --ref main`(또는 대상
브랜치)으로 전체 스캔 후 `cve-gate.md` 아티팩트를 확인한다.
**`doc/cve-exceptions.json` 이 비어 있다.** 첫 전체 스캔에서 차단 항목이 나오면 대응
우선순위(상위 태그 교체 → 베이스 OS 교체 → 자체 빌드 → 예외 승인)를 검토하고, 예외는
근거·만료일을 명시해 추가한다.
**`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 사본에 배포판별 센티널 패키지
@@ -48,11 +56,12 @@ etcd/1.1.12}/{custom-values,dip-values}.yaml` — etcd 는 `dip-values.yaml`에
`helm template`·`extract-helm-images.sh` 로 렌더링 결과까지 재확인했다.
`DOCKERHUB_USER`/`DOCKERHUB_TOKEN``paasup` 조직에 push 권한이 있음을 이번에
확인했다(기존 "미확인" 상태 해소). 최종 런타임 베이스 OS 정책은 security-catalog 의
SUSE BCI 고정 결정을 그대로 따랐(ADR 자체는 미이관, 아래 참고).
SUSE BCI 고정 결정을 그대로 따랐(ADR 자체는 미이관), 2026-08-07 keycloak 작업에서
이 레포의 정책으로 확정됐다(위 참고).
**남은 것: `SBOM_PIPELINE_IMAGE`(sbom.yml 이 쓰는 실행 컨테이너)는 이번 마이그레이션
대상이 아니다** — 여전히 `docker.io/wbsong111/sbom-pipeline:latest` 를 가리킨다.
이건 이미지 3종과 무관한 별개 결정(아래 미결 결정 참고).
이건 자체 빌드 이미지와 무관한 별개 결정(아래 미결 결정 참고).
**`doc/decisions/`·`doc/analysis/` 디렉토리 자체가 dip-catalog 에 없다.** 포팅된 3개
이미지의 README·values 코멘트가 `doc/decisions/000X-*.md`, `doc/analysis/*.md`,
@@ -73,11 +82,19 @@ requests/limits/storage 값을 근거로 표를 추가하는 별도 작업으로
않지만, `paasup` 네임스페이스로 이전할지는 별도 결정이 필요하다. **재빌드 + push +
Repo Variable `SBOM_PIPELINE_IMAGE` 갱신은 git 커밋으로 되지 않는 수동 작업**이다.
**`build-image.yml``REGISTRY_HOST``docker.io/paasup` 로 설정했다.** 로컬에서
`docker login docker.io` 로 로그인한 계정은 `docker.io/paasup` 에 push 권한이 있음을
위 3종 이미지 push 로 확인했다. **단, 이건 로컬 자격증명 확인일 뿐이다** — GitHub
Actions 시크릿(`DOCKERHUB_USER`/`DOCKERHUB_TOKEN`)이 같은 계정/권한인지는 별도 확인이
필요하다(`build-image.yml` workflow_dispatch 를 실제로 한 번 돌려봐야 안다).
**`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 오픈·병합 전 게이트 재확인·배포 검증은 사람의 몫이다.**
---