service-catalog/.claude/skills/cve-remediation/SKILL.md

name, description

name	description
cve-remediation	게이트가 카탈로그 이미지에서 차단 CVE(CRITICAL/HIGH)를 잡았을 때 무료 치환(태그·이미지 좌표 교체)으로 끝낼지 hardened-containers 자체 빌드로 이관할지 예외 승인할지 판단할 때 사용한다. "이 CVE 어떻게 없애", "차단 CVE 뭐부터 해야 해", "자체 빌드 가야 하나 예외 가야 하나", "게이트 실패 다음 스텝" 같은 요청이 해당한다. sbom-cve-gate 로 게이트를 해석하는 것과 hardened-containers 레포에서 자체 빌드를 실행하는 것 사이의 결정 단계만 담당하며 둘의 절차는 복제하지 않는다.

차단 CVE 대응 절차

이 레포는 이미지를 빌드하지 않는다. 자체 빌드는 전부 별도 레포 hardened-containers로 이관됐다(그 레포의 docs/image-authoring/README.md가 단일 출처). 유일한 예외는 apisix의 keycloak-authz 커스텀 플러그인 오버레이 — 이것도 dip-catalog가 뭔가를 빌드하는 게 아니라 이미 다른 곳에서 private으로 빌드된 이미지의 태그를 찾아 반영하는 것뿐이다(catalog/image-map/README.md 참고). 그래서 이 skill이 하는 일은 "빌드 없이 끝나는가, 아니면 hardened-containers로 넘겨야 하는가" 를 가르는 것까지다 — 실제로 어떻게 빌드할지(reinstall vs 재컴파일, 베이스 OS 선택 등) 는 hardened-containers의 docs/image-authoring/README.md 체크리스트가 이미 갖고 있으므로 여기서 중복하지 않는다.

이 skill 은 실행하지 않는다 — 레버를 판단해 실행 skill로 넘긴다. 게이트 실행/해석은 sbom-cve-gate, 자체 빌드는 별도 레포 hardened-containers(그 레포의 docs/image-authoring/README.md가 단일 출처), 배포 검증은 deploy-test-procedure.md가 단일 출처다 — 여기 반복 안 한다.

흐름

1. sbom-cve-gate로 게이트 결과부터 본다. CoverageProbe가 none이면 레버 선택 전에 그것부터 해소한다 — 데이터 없는 0건은 판단 근거가 아니다.

2. 차단 CVE를 컴포넌트 단위로 나눈다. "N건"이 성격 다른 여러 그룹(OS 패키지 vs 앱이 번들/pin한 라이브러리)일 수 있고 그룹마다 레버가 다를 수 있다 — keycloak은 17건이 OS rpm 5건 + Quarkus BOM pin jar 12건으로 갈렸다.

3. 레버를 고르기 전에 "이 컴포넌트가 필요하긴 한가"를 먼저 묻는다. 차트 기본값으로 켜져 있을 뿐 우리가 쓰지 않는 컴포넌트가 차단의 큰 몫을 만들고 있을 수 있다 — argo-cd 는 configs.cm.oidc.config 로 Keycloak 에 직접 붙는데 차트 기본값 dex.enabled: true 때문에 쓰이지도 않는 파드가 떠서 혼자 차단 57건(전체의 58%)을 만들고 있었다. 한 줄로 끝났다. 가장 값싼 레버이고, 아래 표에는 없다.

4. 그룹별로 위부터 먼저 맞는 것을 쓴다. 레버는 실질적으로 셋뿐이다 — "베이스 OS 교체"라는 이름의 독립된 레버는 없다. 이 저장소의 "베이스 교체" 이력을 전부 찾아보면 예외 없이 hardened-containers 자체 빌드 커밋이다(argocd·keycloak· cnpg-postgresql/etcd·apisix 등) — 다른 배포판의 backport를 실제로 쓰려면 그 배포판 위에 앱을 다시 얹어야 하므로 그 자체가 이미 자체 빌드다. 진짜로 빌드 없이 끝나는 유일한 "좌표 교체"는 관리가 끊긴 벤더 이미지(bitnamilegacy/* 등)를 다른 활성 유지 벤더의 기존 이미지로 포인터만 바꾸는 경우뿐이다 — 아래 표 1번 줄에 포함시켰다.

   조건	레버
   최신 상위 태그가 이미 고쳤다 / 관리가 끊긴 벤더 이미지를 다른 활성 벤더의 기존 이미지로 바꾸면 된다	무료 치환 — 카탈로그 values만 바꾸고 재게이트, 빌드 없음
   그 외 전부 — 베이스가 distroless/scratch라 정적 링크 바이너리(Go 모듈 등)에 CVE가 있다 / 앱이 번들·직접 pin한 라이브러리(jar 등)에 CVE가 있다 / 다른 배포판의 backport를 쓰려면 결국 우리가 다시 빌드해야 한다	hardened-containers로 이관 — 이 레포는 여기서 손을 뗀다
   컴포넌트가 중복/오탐 의심	5번 검증 후 예외, 아니면 hardened-containers로 이관

5. 예외는 검증 후에만 — "위험이 낮아 보인다"는 근거가 아니다. InstalledVersion이 FixedVersion 이상인지, 같은 파일이 SBOM에서 컴포넌트 두 개로 잡히지 않는지(PkgPath 비교) 확인한다. 실례: keycloak CVE-2025-59250(mssql-jdbc jar 하나가 두 컴포넌트로 잡혀 잘린 쪽만 매칭된 오탐). 근거·만료일은 doc/cve-exceptions.json.

6. 자체 빌드는 별도 레포 hardened-containers에서 한다 — 그 레포의 docs/image-authoring/README.md가 절차 단일 출처다. 재빌드는 그 레포가 rescan.yml로 매일 자율 수행한다 — dip-catalog는 트리거하지 않는다. sbom.yml이 배포 중인 자체 빌드 이미지의 CVE 드리프트를 다른 카탈로그 이미지와 동일하게 보고만 한다. 무료 치환(태그·이미지 좌표 교체)은 카탈로그 values만 바꾸고 재게이트한다 — 별도 스크립트 없음.

7. 수정 후 반드시 재게이트하고 PASS라도 배포 검증까지 끝나야 종료다 — 1회로 끝난다고 가정하지 않는다(keycloak은 1차 수정 후 재스캔에서 micrometer 2건이 새로 잡혔다).

8. 착지는 브랜치 push까지다 — 조직 정책상 GITHUB_TOKEN으로 PR을 못 연다. 사람이 PR을 열고, 판단 근거는 PR 설명 + MEMORY.md에 남긴다.

참고

• 레버 실행: sbom-cve-gate · 자체 빌드는 별도 레포 hardened-containers
• 함정: pitfalls.md · 미결 사항: MEMORY.md