컨테이너 보안 도구 Trivy의 공급망이 일시적으로 침해당했다 — 우리가 알아야 할 것들

무슨 일이 있었나

컨테이너 이미지와 인프라의 취약점을 스캔하는 오픈소스 보안 도구 Trivy의 생태계 공급망이 일시적으로 침해당한 사실이 공개되었습니다. Aqua Security가 운영하는 Trivy는 CI/CD 파이프라인에서 컨테이너 보안 검사를 수행하는 사실상의 표준 도구 중 하나로, 많은 기업과 오픈소스 프로젝트가 의존하고 있습니다. 보안 도구 자체가 공급망 공격의 대상이 되었다는 점에서 이번 사건의 의미는 상당합니다.

공급망 공격(Supply Chain Attack)이란, 소프트웨어의 개발·빌드·배포 과정 중 어느 한 단계에 악의적인 코드를 삽입하는 공격 방식입니다. 최종 사용자는 신뢰하는 출처에서 소프트웨어를 받았다고 생각하지만, 실제로는 변조된 버전을 사용하게 됩니다. 2020년의 SolarWinds 사태, 2024년의 xz-utils 백도어 사건 등이 대표적인 사례입니다.

침해의 기술적 세부 사항

GitHub Security Advisory(GHSA-69fq-xp46-6x23)에 따르면, 이번 침해는 Trivy 자체의 핵심 코드베이스가 아니라 Trivy 생태계를 구성하는 주변 구성요소에서 발생했습니다. 공급망 공격의 전형적인 패턴대로, 공격자는 직접적인 메인 저장소보다는 의존성 체인의 상대적으로 덜 감시되는 부분을 노렸습니다.

이러한 공격이 위험한 이유는 Trivy의 사용 패턴에 있습니다. Trivy는 대부분 CI/CD 파이프라인에서 자동으로 실행됩니다. GitHub Actions, GitLab CI, Jenkins 등에서 컨테이너 이미지를 빌드할 때마다 Trivy가 호출되어 취약점을 검사하는 구조입니다. 만약 침해된 버전의 Trivy 구성요소가 파이프라인에 들어갔다면, 빌드 환경의 시크릿, 환경 변수, 심지어 빌드 아티팩트 자체에 접근할 수 있는 권한을 공격자에게 제공할 수 있었을 것입니다.

다행히 Aqua Security 팀은 이 침해를 신속하게 감지하고 대응했으며, "briefly compromised"라는 표현에서 알 수 있듯이 침해 기간이 짧았습니다. 그러나 해당 기간 동안 영향을 받았을 수 있는 사용자들은 자신의 환경을 점검할 필요가 있습니다.

반복되는 공급망 공격, 왜 계속되는가

최근 몇 년간 소프트웨어 공급망 공격은 빈도와 정교함 모두에서 급격히 증가하고 있습니다. 2024년 초에는 xz-utils 라이브러리에 백도어가 삽입된 사건이 발생했는데, 공격자가 수년에 걸쳐 오픈소스 메인테이너의 신뢰를 얻은 뒤 악성 코드를 삽입한 매우 정교한 사례였습니다. npm, PyPI 같은 패키지 레지스트리에서도 타이포스쿼팅(인기 패키지와 비슷한 이름의 악성 패키지 등록)이나 의존성 혼동(dependency confusion) 공격이 꾸준히 보고되고 있습니다.

이번 Trivy 사건이 특히 아이러니한 것은, 보안 도구 자체가 공격 대상이 되었다는 점입니다. 보안 스캐너는 일반적으로 높은 권한으로 실행되며, 코드베이스와 인프라에 대한 광범위한 접근 권한을 갖습니다. 따라서 보안 도구의 공급망을 침해하면 공격자 입장에서는 하나의 도구를 통해 수많은 조직의 내부 환경에 접근할 수 있는 레버리지를 얻게 됩니다.

비슷한 맥락에서 Codecov(코드 커버리지 도구)가 2021년에 공급망 공격을 당한 사례가 있습니다. 당시 Codecov의 Bash Uploader 스크립트가 변조되어, 이를 CI에서 사용하던 수많은 기업의 환경 변수와 시크릿이 유출되었습니다. 보안 및 DevOps 도구는 높은 신뢰도로 파이프라인에 통합되기 때문에, 공격자에게는 매우 매력적인 타겟입니다.

한국 개발자가 당장 확인해야 할 것들

이번 사건을 계기로 몇 가지 실무적인 점검 사항을 정리해보겠습니다.

첫째, Trivy 사용 환경 점검입니다. 현재 CI/CD 파이프라인에서 Trivy를 사용하고 있다면, 사용 중인 버전과 설치 방식을 확인하세요. GitHub Advisory에서 영향 범위를 확인하고, 필요하다면 업데이트를 진행해야 합니다. 특히 Trivy를 Docker 이미지로 사용하는 경우, 이미지 다이제스트를 고정(pin)하는 방식이 태그 기반보다 안전합니다.

둘째, CI/CD 파이프라인의 의존성 관리를 재점검하세요. GitHub Actions의 uses 필드에서 @main이나 @latest 같은 유동적인 참조 대신 커밋 해시를 고정하는 것이 좋습니다. 이는 Trivy뿐 아니라 모든 CI 도구에 적용되는 원칙입니다.

셋째, SLSA(Supply-chain Levels for Software Artifacts) 프레임워크에 관심을 가져보세요. Google이 주도하는 이 프레임워크는 소프트웨어 공급망의 무결성을 보장하기 위한 단계적 보안 수준을 정의합니다. 서명된 빌드(signed builds), 재현 가능한 빌드(reproducible builds), 소스 출처 증명(provenance attestation) 등의 개념을 실무에 도입하는 것이 점점 더 중요해지고 있습니다.

마무리

보안 도구조차 공급망 공격에서 자유롭지 않다는 것이 이번 사건의 핵심 교훈입니다. 신뢰는 검증 위에 세워져야 하며, "보안 도구니까 안전하겠지"라는 가정은 위험합니다. 여러분의 CI/CD 파이프라인에서 외부 도구의 의존성을 얼마나 엄격하게 관리하고 계신가요? 버전 고정, 서명 검증, 최소 권한 원칙 중 실무에서 가장 실천하기 어려운 것은 무엇인지 이야기해봤으면 합니다.