의존성·이미지 취약점 검사

CI가 evo-dispatch 배포 이미지의 알려진 취약점(HIGH·CRITICAL)을 Trivy로 찾고 보고서를 남긴다. 지금은 파이프라인을 막지 않고 알리기만 한다. 통과 기준(차단 조건)은 보고서를 몇 번 본 뒤 사람이 정한다(§4). 방식은 evo-service(#171)와 같다.

1. 무엇을 검사하나

대상	방법	보고서
evo-dispatch 이미지	backend_build가 만든 jar로 Dockerfile.release를 빌드해(게시하지 않음) 이미지 검사 — 기반 이미지(eclipse-temurin:25-jre)의 OS 패키지와 jar 안 Java 라이브러리	reports/trivy-evo-dispatch.txt

• 보고서 끝의 --- 검사한 대상 --- 목록이 실제로 본 대상(OS 패키지, jar 안 Java 라이브러리)이다. 취약점이 0건이어도 이 목록에 Java (jar)가 있으면 그 라이브러리까지 검사한 것이다.
• reports/summary.txt에 보고서별 HIGH h, CRITICAL c 요약이 있다. 검사기를 실행하지 못한 보고서는 결과 없음이다.
• job은 vuln_scan(stage release)이고 보고서는 파이프라인 아티팩트(30일 보관)로 받는다.

2. 언제 도나

상황	동작
develop·main push	항상
MR	의존성·Dockerfile·검사 스크립트·CI 설정이 바뀐 경우에만(backend/**/*.kts, backend/gradle.properties, Dockerfile.release, scripts/security/**, .gitlab-ci.yml)
예약 파이프라인(주 1회)	코드가 바뀌지 않아도 새로 공개된 취약점을 잡는다. 예약 파이프라인은 배포·분석 job(dev_image·deploy_dev·sonarqube_analysis)을 돌리지 않는다

• 예약: GitLab 빌드 → 파이프라인 일정. 대상 브랜치 develop, 주기 0 3 * * 1(매주 월요일 03:00), 시간대 Seoul(기본값이 UTC라 지정하지 않으면 같은 식이 낮에 돈다). 다른 프로젝트와 시각을 나눠 개발 러너가 한꺼번에 막히지 않게 한다(요청 d0f9e375).
• 검사기(TRIVY_IMAGE, 기본 aquasec/trivy:0.57.1)나 취약점 DB를 받을 수 없으면 보고서에 결과 없음을 적고 job은 실패하지 않는다. 폐쇄망은 미러 이미지·DB를 준비해 TRIVY_IMAGE를 바꾼다.

3. 보고서 읽기와 조치

• 표의 Library·Installed Version·Fixed Version으로 무엇을 올려야 하는지 안다. Fixed Version이 비어 있으면 아직 고쳐진 버전이 없다 — 기반 이미지가 갱신될 때까지 기다리거나 그 패키지를 이미지에서 뺄 수 있는지 본다.
• 조치는 Issue로 한다: Java 라이브러리는 Spring Boot·Spring AI 버전 또는 Gradle 의존성, OS 패키지는 기반 이미지 태그 갱신.
• Trivy가 보고한 심각도와 실제 위험은 다를 수 있다(그 코드 경로를 쓰지 않는 경우). 판단 근거를 Issue에 적는다.

4. 통과 기준(차단 조건) 정하기

1. 몇 주 동안 보고서를 모아 어떤 항목이 반복되는지 본다.
2. 고칠 수 있는 항목은 Issue로 처리하고, 고칠 수 없는 항목(상위 수정 대기)은 예외 목록(.trivyignore)에 이유와 함께 둔다.
3. 사람이 기준(예: 수정 가능한 CRITICAL이 있으면 실패)을 정하면 scripts/security/의 검사 스크립트에 종료 코드 규칙을 넣고 vuln_scan을 차단으로 바꾼다. 그 전에는 차단하지 않는다.

5. 로컬에서 돌리기

sh scripts/security/test-scan.sh                                # 스크립트 시험(도커 대역, 도커 없이)
sh scripts/security/scan-image.sh <이미지:태그> trivy-image.txt   # 이미지 검사

검사기 이미지를 받을 수 있는 환경과 Docker가 필요하다.