Trivy 공급망 침해: 보안 스캐너가 공격 벡터가 됐을 때

보안 도구가 뚫리면 벌어지는 일

2026년 3월, 오픈소스 보안 스캐너 Trivy가 공급망 공격(Supply Chain Attack)의 매개체가 되면서 1,000개 이상의 SaaS 환경이 피해를 입었다. 컨테이너 이미지와 코드 저장소의 취약점을 찾아내는 도구가, 그 도구를 신뢰하는 파이프라인 수천 개를 공격하는 통로가 된 것이다. "보안 도구도 공격 표면이 될 수 있다"는 불편한 사실을 다시 각인시킨 사건이다.

Trivy는 Aqua Security가 개발해 오픈소스로 공개한 컨테이너·코드 취약점 스캐너로, GitHub Stars 20,000개를 넘기며 업계 표준 스캐닝 도구 중 하나로 자리 잡았다. Docker Hub, GitHub Actions, Jenkins, GitLab CI 등 대부분의 주요 CI/CD 플랫폼이 Trivy를 기본 또는 권장 스캐너로 채택한다. 바로 이 광범위한 채택률이 공격자에게 매력적인 표적이 된 이유다 — Trivy에 취약점 하나를 만들면 이를 쓰는 수만 개 파이프라인에 동시에 접근할 가능성이 열린다.

Trivy가 갖고 있던 권한

Trivy는 컨테이너 이미지, 파일 시스템, Git 저장소, 클라우드 인프라에서 알려진 CVE를 스캔한다. OS 패키지 취약점(Alpine, Debian, RHEL 등), 애플리케이션 의존성 취약점(npm, pip, Go modules 등), IaC 설정 오류, 비밀 정보 노출(API 키, 인증서 등)을 탐지하는 것이 주요 기능이다.

문제는 CI/CD 파이프라인에서 Trivy가 실행되는 권한 수준이다. 컨테이너 이미지 분석을 위해 Docker 소켓에 접근하거나 프라이빗 레지스트리 크리덴셜을 쓰고, Git 저장소 스캔을 위해 코드 읽기 권한을 가지며, 클라우드 스캔을 위해 AWS/GCP/Azure 자격증명을 주입받는 경우도 있다. 이 권한들이 그대로 공격자의 목표가 됐다.

침해 경로

악성 플러그인/어댑터 주입. Trivy는 플러그인으로 기능을 확장할 수 있는데, 공격자들은 정상 플러그인으로 위장한 악성 패키지를 GitHub나 공개 패키지 레지스트리에 등록했다. 이름을 인기 있는 공식 플러그인과 유사하게 만들어(typosquatting) 자동화된 의존성 설치 과정에서 잘못 설치되도록 유도했다. 악성 플러그인은 정상적인 스캔 결과를 반환하면서 백그라운드에서 CI/CD 환경 변수(비밀 정보 포함)를 공격자의 C2 서버로 전송했다. 정상 스캔 결과가 나오기 때문에 탐지가 어려웠다.

CI/CD 파이프라인 내 실행 환경 탈취. 일부 공격은 Trivy 자체보다 그것이 실행되는 환경을 노렸다. GitHub Actions에서 Trivy를 실행하는 workflow 파일에 주입된 악성 코드가 GITHUB_TOKEN이나 클라우드 서비스 자격증명에 접근할 수 있었고, 특히 actions/checkout과 함께 쓰이는 패턴에서 Pull Request 트리거를 통한 권한 에스컬레이션이 발생했다.

취약한 OCI 레지스트리 연동 악용. Trivy는 취약점 데이터베이스를 OCI 아티팩트 형태로 캐싱하고 업데이트하는데, 공격자들은 DNS 스푸핑이나 중간자 공격으로 Trivy가 악성 취약점 DB를 다운로드하게 만들었다. 조작된 DB는 정상적인 취약점 정보를 담으면서 추가 페이로드를 실행하는 코드를 내장했다.

⤢✕

피해는 어떤 형태로 나타났나

1,000개 이상의 SaaS 환경이 피해를 입었다는 수치는 직접 확인된 사례만 집계한 것이다. 피해는 크게 세 유형으로 나뉜다.

가장 광범위했던 것은 크리덴셜 탈취다. AWS Access Key, GCP Service Account, Azure Service Principal, DockerHub 토큰 등이 유출됐고, 이 크리덴셜들은 다크웹에서 거래되거나 추가 공격에 직접 쓰였다. 두 번째는 컨테이너 이미지 조작이다. 탈취된 Docker 레지스트리 자격증명으로 프로덕션 배포용 이미지에 악성 코드가 삽입된 사례가 발견됐고, 이 경우 실제 서비스 환경에 악성 코드가 배포되는 2차 피해로 이어졌다. 세 번째는 소스코드 유출과 백도어 삽입이다. GitHub, GitLab 등 코드 저장소에 대한 읽기/쓰기 권한을 확보한 공격자가 소스코드를 다운로드하거나, 일부 사례에서는 저장소에 백도어 코드를 직접 커밋했다.

Aqua Security의 대응

Aqua Security는 침해 보고를 접수한 뒤 긴급 보안 권고를 발표했다. 공식 플러그인 목록을 GitHub 공식 저장소에 서명된 형태로 공개하고, 서명되지 않은 플러그인 설치를 기본값으로 막는 --skip-unsigned-plugins 플래그를 추가했다. 취약점 DB 업데이트 시 TLS 인증서 검증과 체크섬 확인을 강화하고, OCI 아티팩트의 Sigstore 서명 검증을 의무화하는 패치도 긴급 릴리스했다.

영향받는 버전은 0.45.0 이전 전체다. 패치 버전(0.45.1 이상)으로 즉시 업그레이드하고, Trivy가 쓰던 모든 자격증명을 교체하며, CI/CD 파이프라인 로그를 소급 감사하는 것이 권고 사항이다.

SolarWinds, Log4Shell, 그리고 Trivy

Trivy 사건은 2020년 SolarWinds 침해, 2021년 Log4Shell 취약점에 이은 공급망 보안 사고의 연장선에 있다. SolarWinds는 소프트웨어 업데이트 메커니즘이 공격 벡터가 된 사례였고, Log4Shell은 모든 Java 기반 시스템에 내장된 로깅 라이브러리의 취약점이었다. Trivy 사건은 보안 도구 자체가 공격 표면이 된 새로운 형태다.

공통점은 신뢰도가 높은 소프트웨어일수록 공격 표면의 가치가 커진다는 것이다. 아무도 의심하지 않는 도구일수록 악성 행위를 숨기기 쉽다. 보안 스캐너는 정의상 "신뢰받는" 도구이기 때문에 이런 유형의 공격에 특히 취약하다.

현대 DevSecOps 파이프라인에는 Trivy 외에도 Snyk, SonarQube, Semgrep, Checkov, Grype 같은 도구들이 통합돼 있다. 이 도구들 모두 높은 권한으로 실행되며 프라이빗 코드와 크리덴셜에 접근한다. 각 도구가 또 다른 잠재적 공격 표면이라는 점을 인식하는 보안 전략이 필요하다. SLSA(Supply-chain Levels for Software Artifacts)와 NIST SSDF(Secure Software Development Framework)가 이런 위험을 완화하기 위한 표준을 제시하지만, 조직 수준의 실제 구현은 아직 초기 단계다.

지금 해야 할 것과 이후에 해야 할 것

Trivy를 쓰는 조직이라면 즉시 취해야 할 조치가 있다. Trivy를 0.45.1 이상으로 업그레이드하고, 설치된 플러그인 목록을 확인해 공식 목록에 없는 것을 제거한다. CI/CD 파이프라인에서 Trivy가 쓰던 서비스 계정 자격증명을 교체하고, 이전 자격증명으로 발생한 API 호출 로그를 감사한다. --db-repository 플래그를 명시적으로 설정해 공식 DB 소스만 쓰도록 고정한다. GitHub Actions 사용자라면 워크플로우에서 aquasecurity/trivy-action을 버전 태그가 아닌 고정된 커밋 해시(SHA)로 참조하는 것이 권장된다. 태그는 재작성될 수 있지만 커밋 해시는 변경 불가능하다.

패치를 적용하는 것으로 끝날 문제는 아니다. SBOM(Software Bill of Materials)을 도입해 SPDX나 CycloneDX 표준으로 사용 중인 모든 오픈소스 도구와 의존성 목록을 관리하면, 새로운 취약점이 발견됐을 때 영향 범위를 바로 확인할 수 있다. 모든 외부 도구와 라이브러리를 정확한 버전 또는 해시로 고정하는 의존성 핀닝은 편리한 자동 업데이트가 예상치 못한 악성 변경을 들여오는 것을 막아준다. CI/CD 파이프라인의 각 단계가 필요한 최소한의 권한만 갖도록 재설계하는 최소 권한 원칙도 필요하다 — Trivy 스캔 단계라면 스캔 대상에 대한 읽기 권한만으로 충분하고, 배포 권한이나 프로덕션 크리덴셜은 애초에 불필요하다.

Trivy 공급망 침해는 보안을 강화하려고 도입한 도구가 새로운 공격 표면이 되는 역설을 보여준다. 오픈소스 생태계의 강점인 광범위한 채택과 신뢰가 동시에 공격자에게는 매력적인 표적이 된다는 사실은, 사용하는 모든 도구, 특히 보안 도구 자체에도 동일한 수준의 보안 검토를 적용하는 것이 DevSecOps의 기본이 돼야 한다는 것을 다시 확인시킨다.