보안 취약점을 찾아주는 도구가 스스로 취약점이 된다면, 우리는 무엇을 믿어야 하는가.

Aqua Security가 개발한 오픈소스 컨테이너 보안 스캐너 Trivy의 생태계가 공급망 공격에 일시적으로 침해당했다. Hacker News에 공유된 보고에 따르면, Trivy가 의존하는 패키지 일부가 변조되면서 이 도구를 통합한 CI/CD 파이프라인 전체가 잠재적 위험에 노출됐다. 사건은 비교적 신속하게 수습됐다. 그러나 남겨진 질문의 무게는 가볍지 않다.

의존성 체인 한 고리가 무너지다

Trivy는 컨테이너 이미지, 파일시스템, Git 리포지토리의 보안 취약점을 스캔하는 도구다. GitHub 스타 수 2만 5천 개를 넘기며 클라우드 네이티브 생태계에서 사실상 표준 스캐너로 자리잡았다. 기업 환경에서는 GitHub Actions나 GitLab CI에 Trivy를 통합해 컨테이너 빌드마다 자동으로 취약점을 점검하는 방식이 보편적이다.

문제는 Trivy 자체가 아니라 그 주변부에서 터졌다. Trivy가 참조하는 외부 패키지―구체적으로는 취약점 데이터베이스 또는 플러그인 체인의 일부―가 변조된 것이다. 공격자는 이 의존성 경로를 파고들어 악성 코드를 삽입할 수 있는 창구를 확보했다.

탐지에서 수습까지, 72시간의 긴박한 기록

Hacker News 스레드에 공유된 정보를 종합하면 사건 경과는 다음과 같다.

커뮤니티 기여자들이 Trivy 관련 패키지의 비정상적 변경을 먼저 포착했다. 체크섬 불일치, 예상치 못한 코드 경로 추가 등 전형적인 공급망 침해 징후였다. 보고가 올라오자 Aqua Security는 신속하게 대응에 나섰다. 변조된 패키지를 격리하고 정상 버전으로 복구하는 작업이 이어졌다.

침해 기간은 비교적 짧았다. "briefly compromised"라는 표현이 붙은 이유다. 하지만 그 짧은 틈 사이에 해당 패키지를 내려받아 빌드에 포함시킨 사용자가 얼마나 되는지는 정확히 파악되지 않았다. 오픈소스 패키지 특성상 다운로드 경로가 분산돼 있어 영향 범위를 완전히 추적하기 어렵다는 점이 사태를 더 복잡하게 만든다.

보안 도구가 뚫릴 때, 방어선 전체가 흔들린다

이 사건이 통상적인 패키지 변조 사고와 결정적으로 다른 지점이 있다. 침해 대상이 '보안 도구'라는 사실이다.

일반적인 라이브러리가 뚫리면 해당 라이브러리를 사용하는 애플리케이션이 위험해진다. 보안 스캐너가 뚫리면 차원이 달라진다. 스캐너는 CI/CD 파이프라인에서 높은 권한으로 실행된다. 컨테이너 이미지 전체를 읽고, 파일시스템을 순회하며, 때로는 네트워크에 접근해 취약점 데이터베이스를 갱신한다. 공격자 입장에서 이보다 매력적인 표적은 드물다.

Hacker News의 한 사용자가 핵심을 짚었다. "우리는 보안 도구를 신뢰 경계 안에 무조건 넣는다. 그 도구의 공급망까지 검증하는 조직은 거의 없다." 대부분의 기업은 Trivy 같은 스캐너를 파이프라인에 추가하면서 도구 자체의 무결성은 검증하지 않는다. 보안 도구니까 안전하리라는 암묵적 전제가 깔려 있기 때문이다.

SolarWinds에서 Trivy까지, 반복되는 공급망의 구조적 균열

이 사건은 고립된 사례가 아니다. 2020년 SolarWinds 사태 이후 공급망 공격은 사이버 보안의 핵심 화두로 부상했다. 2021년 Codecov 배시 업로더 변조, 2022년 ctx·phpass 패키지 사건, 2024년 XZ Utils 백도어까지―패턴은 놀라울 만큼 일관적이다. 널리 쓰이지만 관리 인력이 부족한 오픈소스 프로젝트의 의존성 체인을 노린다.

Trivy 건은 여기서 한 단계 더 나아간다. 공격 대상이 보안 인프라 자체라는 점에서 신뢰 모델의 근본적 허점을 드러낸다. SBOM(소프트웨어 자재 명세서) 생성, 서명 검증, SLSA 프레임워크 같은 공급망 보안 메커니즘이 활발히 논의되고 있지만, 실제 적용률은 여전히 낮다.

도구를 어디까지 의심할 것인가―방어자의 딜레마

현실적인 질문이 남는다. 보안 도구의 공급망까지 검증하려면 비용과 복잡성이 급격히 늘어난다. 모든 의존성의 체크섬을 고정하고, 빌드 재현성을 확보하며, 업데이트마다 코드 리뷰를 수행하는 것이 이론적으로는 옳다. 하지만 빠르게 변하는 취약점 데이터베이스를 실시간으로 갱신해야 하는 스캐너의 본질과 충돌한다. 데이터베이스 업데이트를 늦추면 새로운 CVE를 놓치고, 빠르게 반영하면 변조 위험이 커진다. 양쪽 모두 대가가 따른다.

Sigstore 같은 서명 인프라 프로젝트가 이 간극을 메우려 시도하고 있다. 패키지 게시자의 신원을 투명하게 기록하고 검증 가능한 서명을 남기는 방식이다. 다만 생태계 전반에 보급되기까지는 시간이 필요하다.

지금 당장 점검해야 할 세 가지

Trivy 공급망 침해는 빠르게 수습됐고, 실제 피해 규모는 제한적인 것으로 알려졌다. 그러나 이 사건이 전하는 메시지는 분명하다. 보안 도구라고 해서 공급망 공격의 예외가 아니며, 오히려 높은 권한을 가진 보안 도구일수록 더 매력적인 공격 표면이 된다.

조직이 지금 즉시 점검해야 할 항목은 세 가지다. 첫째, CI/CD 파이프라인에서 실행되는 보안 도구의 버전과 해시를 고정하고 있는가. 둘째, 해당 도구의 의존성 업데이트 경로를 모니터링하고 있는가. 셋째, 보안 도구 자체를 신뢰 경계 밖에서 검증하는 절차가 마련돼 있는가.

감시자를 감시하는 체계가 없다면, 성벽 위의 보초가 적군으로 바뀌어도 아무도 알아채지 못한다.