wbsong111
f1d10a1d09
2026-08-11 apisix 작업에서 만들어 실제로 적용한 skill 인데 커밋되지 않은 채 로컬에만 있었다. MEMORY.md 와 CLAUDE.md 가 .claude/skills/cve-remediation/SKILL.md 를 가리키므로 레포만 보는 사람에게는 깨진 링크였다. CLAUDE.md 의 skill 표에도 같은 이유로 빠져 있던 줄을 넣는다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.2 KiB
name, description
| name | description |
|---|---|
| cve-remediation | 게이트가 카탈로그 이미지에서 차단 CVE(CRITICAL/HIGH)를 잡았을 때 태그 교체·베이스 OS 교체·자체 빌드·예외 승인 중 어느 레버를 쓸지 판단할 때 사용한다. "이 CVE 어떻게 없애", "차단 CVE 뭐부터 해야 해", "자체 빌드 가야 하나 예외 가야 하나", "게이트 실패 다음 스텝" 같은 요청이 해당한다. sbom-cve-gate·self-build-image 사이 결정 단계만 담당하며 둘의 절차는 복제하지 않는다. |
차단 CVE 대응 절차
이 skill 은 실행하지 않는다 — 레버를 판단해 실행 skill로 넘긴다. 게이트 실행/해석은
sbom-cve-gate, 자체 빌드는 self-build-image, 배포 검증은
deploy-test-procedure.md가 단일 출처다 — 여기 반복 안 한다.
흐름
-
sbom-cve-gate로 게이트 결과부터 본다.CoverageProbe가none이면 레버 선택 전에 그것부터 해소한다 — 데이터 없는 0건은 판단 근거가 아니다. -
차단 CVE를 컴포넌트 단위로 나눈다. "N건"이 성격 다른 여러 그룹(OS 패키지 vs 앱이 번들/pin한 라이브러리)일 수 있고 그룹마다 레버가 다를 수 있다 — keycloak은 17건이 OS rpm 5건 + Quarkus BOM pin jar 12건으로 갈렸다.
-
그룹별로 위부터 먼저 맞는 것을 쓴다:
조건 레버 최신 상위 태그가 이미 고쳤다 태그 교체 베이스가 distroless/scratch, CVE가 정적 링크 바이너리(Go 모듈 등)에 있다 베이스 OS 교체 불가 → 자체 빌드 앱이 번들·직접 pin한 라이브러리(jar 등)에 있다(OS 패키지 아님) 태그·베이스 OS 둘 다 무효 → 자체 빌드(overlay/재컴파일) 다른 배포판이 backport로 이미 고쳤다 베이스 OS 교체 컴포넌트가 중복/오탐 의심 4번 검증 후 예외, 아니면 자체 빌드 -
예외는 검증 후에만 — "위험이 낮아 보인다"는 근거가 아니다. InstalledVersion이 FixedVersion 이상인지, 같은 파일이 SBOM에서 컴포넌트 두 개로 잡히지 않는지(PkgPath 비교) 확인한다. 실례: keycloak
CVE-2025-59250(mssql-jdbc jar 하나가 두 컴포넌트로 잡혀 잘린 쪽만 매칭된 오탐). 근거·만료일은doc/cve-exceptions.json. -
자체 빌드는
self-build-image+ image-authoring.md로, 태그/베이스 OS 교체는 카탈로그 values만 바꾸고 재게이트한다 — 별도 스크립트 없음. -
수정 후 반드시 재게이트하고 PASS라도 배포 검증까지 끝나야 종료다 — 1회로 끝난다고 가정하지 않는다(keycloak은 1차 수정 후 재스캔에서 micrometer 2건이 새로 잡혔다).
-
착지는 브랜치 push까지다 — 조직 정책상
GITHUB_TOKEN으로 PR을 못 연다. 사람이 PR을 열고, 판단 근거는 PR 설명 +MEMORY.md에 남긴다.
참고
- 레버 실행: sbom-cve-gate · self-build-image
- 함정: pitfalls.md · 미결 사항: MEMORY.md