자체 빌드 드리프트 스캔·재빌드 트리거를 제거하고 CI 파이프라인을 정리한다

hardened-containers가 이미 rescan.yml로 매일 자율 재스캔·재빌드하고, sbom.yml이
custom-values.yaml 기준으로 자체 빌드 이미지를 다른 카탈로그 이미지와 동일하게
스캔하고 있어 self-build-drift-check.yml의 트리거·전용 스캔이 순수 중복이었다
(SECURITY_IMAGES_DISPATCH_TOKEN도 등록된 적 없어 트리거 스텝은 항상 실패하던
죽은 코드). check-rebuild-needed.py가 더하던 fixable/no-fix 구분도 cve-gate.py
리포트에 이미 있어 흡수할 필요 없이 삭제했다. 근거는 ADR 0005.

곁들여 CI 위생 문제(trivy DB 캐시 없음, concurrency 없음, catalog-tag-update.yml의
브랜치 누적)를 함께 고치고, hardened-containers의 docs/image-authoring.md가
docs/image-authoring/ 로 분할된 것을 반영해 관련 링크를 정정했다.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
wbsong111
2026-08-26 09:48:48 +09:00
parent 9e5b6633db
commit f5b8e4b91f
20 changed files with 339 additions and 452 deletions
+10 -9
View File
@@ -32,9 +32,9 @@ dip-catalog/
│ └── status.md # 구현 현황
├── scripts/
│ ├── pipeline/ # SBOM 생성 + CVE 스캔 + 게이트 판정 (sbom.yml/cve-edge-post.yml 이 쓴다)
│ ├── build/ # 자체 빌드 이미지 축의 카탈로그 쪽 절반 — 드리프트 탐지
│ │ # (check-rebuild-needed.py) + 발행 태그 반영
│ │ # (apply-published-tags.py). 빌드 자체는 hardened-containers 레포
│ ├── build/ # 자체 빌드 이미지 축의 카탈로그 쪽 절반 — 발행 태그 반영
│ │ # (apply-published-tags.py). CVE 스캔은 sbom.yml 이 다른
│ │ # 카탈로그 이미지와 동일하게 하고, 빌드 자체는 hardened-containers 레포
│ └── deploy-test/ # 배포 검증 스크립트 + fixtures (helm/kubectl 실행 전담)
├── catalog/
│ └── image-map/<image>.env # 자체 빌드 이미지 → 차트·필드 매핑 (목록은 이 디렉토리가 단일 출처)
@@ -154,7 +154,7 @@ python3 agent/update_catalog/skills/helm_diff/scripts/run.py \
| [sbom-cve-gate](.claude/skills/sbom-cve-gate/SKILL.md) | SBOM 생성·CVE 스캔·게이트 판정 실행 및 결과 해석 (`scripts/pipeline`) |
자체 빌드 하드닝 이미지 추가·변경은 이 레포의 일이 아니다 — 별도 레포 `hardened-containers`
에서 하고, 그 레포의 `docs/image-authoring.md`가 단일 출처다(이관 배경:
에서 하고, 그 레포의 `docs/image-authoring/README.md`가 단일 출처다(이관 배경:
[doc/migrations/](doc/migrations/)).
각 Skill 은 절차 본문을 복제하지 않고 권위 있는 문서(`doc/sbom-pipeline.md` 등)를
@@ -175,7 +175,7 @@ python3 agent/update_catalog/skills/helm_diff/scripts/run.py \
| 축 | 질문 | 실행 위치 | 워크플로(이 레포) | 게이트 | 단일 출처 |
|----|------|----------|------------------|--------|----------|
| **차트 카탈로그** | 우리가 배포하는 이미지에 무엇이 있는가 | 이 레포 | `sbom.yml`<br>`cve-edge-post.yml` | warn-only<br>**호출 안 함** | [doc/sbom-pipeline.md](doc/sbom-pipeline.md) |
| **자체 빌드** | 그 이미지를 어떻게 만드는가 | 별도 레포 `hardened-containers` | `self-build-drift-check.yml`(탐지·트리거)<br>`catalog-tag-update.yml`(반영) | **강제**(그 레포 소유) | 그 레포의 `docs/image-authoring.md` |
| **자체 빌드** | 그 이미지를 어떻게 만드는가 | 별도 레포 `hardened-containers` | `catalog-tag-update.yml`(반영) | **강제**(그 레포 소유) | 그 레포의 `docs/image-authoring/README.md` |
- **차트 축은 warn-only 다** — 게이트가 실패해도 CI/PR 을 막지 않는다. 카탈로그 차트 전체가
이 게이트로 트리아지된 적이 없다. **자체 빌드 축의 게이트는 이미 강제다**(단, 그 게이트는
@@ -186,10 +186,10 @@ python3 agent/update_catalog/skills/helm_diff/scripts/run.py \
레버 판단은 [cve-remediation](.claude/skills/cve-remediation/SKILL.md) skill 이 갖는다.
실행은 `hardened-containers` 레포에서 `workflow_dispatch` 로만 한다.
- **이 레포는 "무엇을 배포 중인가"만 안다.** 어느 이미지를 자체 빌드하고 있는지는
`catalog/image-map/` 이 단일 출처다. `scripts/build/check-rebuild-needed.py`(주간
`self-build-drift-check.yml`)가 배포 중인 이미지를 직접 스캔해 재빌드 대상을 판단하고,
필요하면 `hardened-containers` 의 `build-image.yml` 을 트리거만 한다 — 핀을 무엇으로
올릴지는 그 레포가 판단한다.
`catalog/image-map/` 이 단일 출처다. 배포 중인 자체 빌드 이미지의 CVE 드리프트는
`sbom.yml` 이 다른 카탈로그 이미지와 동일하게 스캔·보고한다 — 재빌드 여부·시점은
전적으로 `hardened-containers` 의 자체 `rescan.yml` 이 매일 자율 결정한다. 이 레포는
트리거하지 않는다(ADR [0005](doc/decisions/0005-self-build-drift-check-removed.md)).
- **카탈로그 반영은 pull 방식이다.** `hardened-containers` 는 이 카탈로그를 모른다 — 게이트
PASS + push 성공 시 자기 레포의 `published.json` 만 갱신한다. `catalog-tag-update.yml`
이 그 파일을 public raw URL 로 읽어가 `custom-values.yaml`/`dip-values.yaml` 을 패치한다.
@@ -261,3 +261,4 @@ python3 agent/update_catalog/skills/helm_diff/scripts/run.py \
| [agent/update_catalog/docs/decisions/001-agentic-first.md](agent/update_catalog/docs/decisions/001-agentic-first.md) | 파이프라인 오케스트레이션 건너뛰기 결정 배경 |
| [agent/update_catalog/docs/status.md](agent/update_catalog/docs/status.md) | 구현 현황 상세 |
| [doc/sbom-pipeline.md](doc/sbom-pipeline.md) | SBOM 생성·CVE 스캔·게이트 파이프라인 상세 |
| [doc/architecture.md](doc/architecture.md) | `.github/workflows/` 4개 워크플로의 트리거 조건·잡 흐름도 (CI 파이프라인 아키텍처) |