Trivy로 컨테이너 취약점 스캔 CI 만들기: 실패 기준(Severity)과 예외 운영법

Trivy로 컨테이너 취약점 스캔 CI 만들기: 실패 기준(Severity)과 예외 운영법

취약점 스캔은 '0개'가 목표가 아니라, 팀이 운영 가능한 기준을 만드는 게 목표입니다.
Trivy를 CI에 붙이고, 실패 기준과 예외(allowlist) 운영을 어떻게 하면 덜 괴로운지 정리합니다.

이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.

왜 이게 어려운가(운영 관점)

운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).

따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.

실전 내용(바로 적용)

취약점 스캔은 '0개'가 목표가 아니라, 팀이 운영 가능한 기준을 만드는 게 목표입니다.
Trivy를 CI에 붙이고, 실패 기준과 예외(allowlist) 운영을 어떻게 하면 덜 괴로운지 정리합니다.

핵심 요약(결론부터)

• 기준(정책)을 먼저 정하고, 구현/도구는 그 다음에 선택한다
• 실패/예외/회귀를 운영 체크리스트로 막는다
• 공식 문서를 최종 근거로 삼고, 팀 문서로 재가공한다

현실적인 실패 기준

Critical/High만 차단하고 Medium은 리포트
베이스 이미지 교체 주기를 운영 룰로

예외 운영

예외는 만료일/사유/소유자 필수
무기한 예외는 기술 부채

CI 실행 예시

trivy image --severity CRITICAL,HIGH --exit-code 1 your-image:tag
trivy sbom your-image:tag --format cyclonedx

운영 체크리스트(바로 적용)

• 스캔 결과를 PR 코멘트/아티팩트로 남긴다
• 예외는 만료일을 강제한다
• 베이스 이미지 업데이트를 릴리스 루프에 넣는다

FAQ

Q. 취약점이 너무 많이 떠요
A. 대부분 베이스 이미지/OS 패키지에서 나옵니다. 애플리케이션 코드만 고쳐서는 줄지 않으니, 베이스 이미지 전략을 먼저 잡아야 합니다.

마무리: 다음 액션

• 팀의 기본값(정책)을 1페이지로 문서화한다
• 대표 시나리오 1개를 코드/설정 예시로 고정한다
• 배포 전후 지표(p95/p99, 오류율)를 비교해 효과를 확인한다

자주 하는 실수(사고 패턴)

• 증상만 보고 timeout/limit을 크게 늘려 원인을 숨긴다
• 프로브/스케일/리소스를 따로따로 튜닝해 전체 QoS가 흔들린다
• 변경 후 효과를 지표로 검증하지 않아 회귀가 반복된다
• 운영 자동화(CI/CD)에서 권한/보안 경계를 느슨하게 둔다

적용 순서(추천)

• 1) 지표로 증상을 고립한다(오류율/지연/재시도율/리소스)
• 2) 타임아웃을 레이어별로 정렬한다(client > proxy > server > db)
• 3) 스케일(파드/노드)과 워밍업(readiness)을 같이 설계한다
• 4) 변경은 작게/단계적으로 하고, 알람/롤백을 같이 준비한다
• 5) 운영 기준을 문서로 고정하고, 체크리스트로 반복 가능하게 만든다

검증/회귀 방지

• 재현: 스파이크/롤링업데이트/대용량 업다운로드 같은 시나리오를 고정
• 로그: upstream time, 종료 이벤트, 재시도 횟수 같은 필드를 고정
• 알람: OOMKilled, throttling, 5xx burst, p99 spike를 조기 경보로 운영

팀 합의 템플릿(복붙용)

# 장애 대응 템플릿(복붙용)
증상: (오류율/지연/시점/영향 범위)
가설: (타임아웃/리소스/종료/프록시/코드)
검증: (재현/로그/지표 링크)
조치: (설정 변경/배포/롤백)
재발 방지: (알람/체크리스트/문서)

FAQ

Q. 취약점이 너무 많이 떠요
A. 대부분 베이스 이미지/OS 패키지에서 나옵니다. 애플리케이션 코드만 고쳐서는 줄지 않으니, 베이스 이미지 전략을 먼저 잡아야 합니다.

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• Trivy
• CycloneDX