Trivy vs Grype, 컨테이너 스캐너 뭘 쓸까

Trivy vs Grype, 컨테이너 스캐너 뭘 쓸까

CI 파이프라인에 컨테이너 이미지 스캐너를 하나 박아 넣어야 하는 상황이 최근에 또 왔다. 사내에서 새 서비스 하나 띄우는데 보안팀에서 "이미지 CVE 스캔 결과 붙여주세요"라는 요구를 걸었다. 예전에는 그냥 Trivy 박고 끝이었는데, 이번엔 좀 다르게 접근해봤다.

솔직히 말하면 요즘 Grype가 꽤 좋아졌다. 최근 몇 달 사이 EPSS 통합, KEV 카탈로그 반영, 컴포지트 리스크 스코어 같은 게 붙으면서 "이거 진짜 실무에 쓸만한데?" 싶은 느낌이 확실히 있다. 그래서 이번 기회에 두 스캐너를 나란히 놓고 우리 파이프라인에 뭘 넣을지 다시 판단했다.

두 도구의 성격이 다르다

같은 카테고리로 묶어서 비교하기엔 사실 두 도구가 지향점이 좀 다르다.

Trivy는 "다 해주는 애"다. 이미지 CVE 스캔은 기본이고, IaC 파일 misconfig 검출, 시크릿 스캔, 라이선스 검사까지 한 바이너리로 다 된다. Kubernetes 클러스터 상태도 스캔한다. Aqua Security가 만들었고, 데이터소스도 넓게 긁어온다. 우리 팀에서는 예전부터 Terraform 파일 검사 + 이미지 스캔을 Trivy 하나로 통일해서 쓰던 이유가 이거였다.

Grype는 반대다. "CVE 매칭 하나만 확실히"라는 컨셉. 스캐너로서는 딱 그 일만 한다. 대신 그 일 하나를 정말 정교하게 한다. SBOM은 Syft가 만들고 Grype는 그걸 받아서 스캔하는 구조라서, 파이프라인을 좀 더 모듈하게 짤 수 있다. Anchore가 만들었고 데이터베이스도 자기들이 큐레이션한다.

이 성격 차이가 뭘 의미하냐면, "우리 팀이 스캐너에서 뭘 기대하는가"가 선택 기준이 된다는 얘기다. 만능 스위스 아미 나이프가 필요한지, 아니면 잘 벼려진 칼 하나가 필요한지.

속도는 사실 별 차이 없다

블로그들 돌아다니다 보면 "Grype가 30~40% 빠르다"는 얘기가 자주 나오는데, 실무에서 이 숫자에 너무 의미 부여할 필요는 없다고 본다. 500MB 짜리 이미지 첫 스캔 기준으로 Trivy가 8초, Grype가 9초 나오는 경우도 있고, 두번째 스캔부터는 캐시 때문에 둘 다 훨씬 빨라진다.

CI 러너에서 스캔이 파이프라인 전체의 병목이 되는 케이스는 별로 없다. 이미지 빌드가 3분, 배포가 5분 걸리는데 스캔이 1초 빠른 게 무슨 의미가 있나. 단, 한 파이프라인 안에서 이미지를 수십, 수백 개 스캔하는 상황이면 그때는 진짜 초 단위 차이가 누적된다. 우리 팀은 그런 상황이 아니었다.

그래서 속도는 판단 기준에서 뺐다.

리스크 점수에서 Grype가 앞서 있다

가장 큰 차이라고 느낀 부분이 여기다. Trivy는 여전히 CVSS 기반의 LOW/MEDIUM/HIGH/CRITICAL 필터링에 무게가 실려 있다. "이 CVE의 CVSS가 7.5니까 HIGH"라는 식이다. 물론 EPSS 점수도 최근에 노출해주긴 하는데, 필터링/우선순위 로직의 기본은 여전히 severity 중심이다.

Grype는 다르다. 각 파인딩에 0.0~10.0 사이의 컴포지트 리스크 스코어를 붙여주는데, 이게 CVSS + EPSS(30일 익스플로잇 확률) + KEV(실제 익스플로잇된 목록) 세 가지를 조합한 값이다. 즉 "CVSS는 높은데 EPSS는 낮고 KEV에도 없는" 케이스가 자동으로 뒤로 밀린다. 반대로 "CVSS 6.5인데 KEV 카탈로그에 있는" 케이스는 확 앞으로 튀어나온다.

이게 왜 중요하냐면, 실제 대응 우선순위가 그렇게 정해지기 때문이다. CVSS만 보면 스캔 결과에 CRITICAL이 300개 나오고 팀 전체가 마비된다. 실제로 익스플로잇 가능성이 있는 몇 개만 골라내는 게 진짜 일이다. 이 필터링을 스캐너가 어느 정도 대신해주면, 보안팀-개발팀 간 커뮤니케이션 비용이 확 줄어든다.

노이즈 vs 커버리지의 트레이드오프

디텍션 자체는 둘 다 정확하다. 큰 CVE는 둘 다 잡는다.

다만 세부 경향은 다르다. Grype는 Anchore가 정규화한 DB 하나에 의존하니까 false positive가 상대적으로 적다는 평이 많다. 대신 데이터 소스가 좁으면 놓치는 게 생길 수도 있다. Trivy는 여러 소스를 broad하게 긁어와서 커버리지가 넓지만, 대신 애매한 파인딩이나 재현 어려운 CVE도 같이 올라오는 경우가 있다.

우리 팀에서 실제 이미지 3개(nginx alpine, python:3.11-slim, 자체 Go 이미지) 놓고 돌려봤다. Trivy가 파인딩 개수는 좀 더 많이 잡았는데, 그 중 대략 15~20% 정도는 "이거 우리 큔드빠이스에 영향 없는 게 확실한데?" 싶은 것들이었다. Grype는 결과가 좀 더 정돈된 느낌이었고, 각 파인딩 옆에 리스크 스코어가 붙어 있어서 우선순위 잡기 편했다.

이건 진짜 트레이드오프다. 노이즈를 감수하고 넓게 볼 것이냐, 좀 좁더라도 시그널 위주로 볼 것이냐.

SBOM 파이프라인 관점에서 볼 때

요즘은 SBOM 얘기가 빠질 수 없다. 컴플라이언스 요구사항으로 들어오는 경우도 많다.

Trivy는 SBOM 생성과 스캔을 한 도구에서 다 한다. trivy image --format cyclonedx 하면 CycloneDX SBOM 나오고, 그거 그대로 다시 스캔에 넣을 수도 있다. 심플하다.

Grype + Syft는 두 단계다. Syft로 SBOM 만들고, Grype로 그 SBOM 스캔. 언뜻 더 복잡해 보이는데, 실제로는 이 분리가 유리한 경우가 있다. 예를 들어 SBOM은 아티팩트 저장소에 한 번만 저장해두고, 나중에 새 CVE가 나올 때마다 저장된 SBOM만 다시 스캔하는 식으로 파이프라인을 짤 수 있다. 이미지를 다시 pull하고 언패킹할 필요가 없다. 이거 대규모 환경에서는 꽤 큰 차이다.

그리고 Syft가 만든 SBOM은 다른 스캐너에도 넣을 수 있고, Grype는 Syft가 아닌 다른 도구가 만든 SBOM도 받는다. 툴체인이 lock-in되지 않는다는 장점이 있다.

그래서 뭘 골랐냐

우리 팀은 결국 이렇게 정리했다.

메인 파이프라인의 이미지 스캔은 Grype로 갔다. 이유는 리스크 스코어 기반 우선순위. 매주 나오는 CVE 리포트에서 "이 중 실제로 봐야 하는 게 뭐냐"를 정하는 데 EPSS/KEV 정보가 확실히 도움이 됐다. 개발팀에 "이거 지금 당장 패치해야 합니다"라고 말할 때 근거가 더 구체적이다.

IaC misconfig 스캔이랑 시크릿 스캔은 Trivy를 계속 쓴다. Grype는 이걸 안 한다. 그리고 Terraform 파일 검사에서 Trivy는 검증된 정책이 이미 많이 있어서 굳이 다른 걸 찾을 필요가 없다.

SBOM은 Syft로 만들어서 아티팩트 저장소에 별도 저장하고, 새 CVE 나올 때마다 Grype로 재스캔한다. 이미지를 매번 다시 pull하지 않아도 되니까 리스캔 비용이 확 줄었다.

즉 우리는 Grype + Syft를 메인, Trivy를 보조로 쓰는 하이브리드 구성으로 갔다. 하나만 골라야 한다면? 팀에 별도 보안 담당자가 없고 파이프라인을 심플하게 유지하고 싶다면 Trivy 하나로 통일하는 게 편하다. 반대로 우선순위 판단이 계속 이슈였고 SBOM 파이프라인을 제대로 짜고 싶다면 Grype + Syft 조합이 낫다.

열린 결론

솔직히 이 판단은 아직 검증 중이다. 3개월 정도 돌려보고 다시 리뷰하기로 팀 내부에서 얘기가 됐다. 리스크 스코어가 실제 대응 우선순위와 얼마나 일치하는지, false negative가 눈에 띄게 늘어나진 않는지 좀 더 봐야 한다.

혹시 두 스캐너 다 써보시고 다른 관점 있으신 분, 아니면 다른 조합(예: 상용 스캐너와 오픈소스 병행) 쓰시는 분 있으면 어떤 기준으로 선택했는지 궁금하다. 스캐너는 결국 팀의 대응 프로세스랑 붙어야 의미 있는 도구라서, 각 팀마다 정답이 다르지 않을까 싶다.

태그

DevSecOps, Trivy, Grype, 컨테이너보안, SBOM, CVE, 보안스캐너