TTESays

Trivy가 보여준 ‘미완의 대응’과 공급망 보안의 착각

Donghwi Shin

Published: 08:00, 25 Mar 2026 (Updated: 18:43, 25 Mar 2026)

Trivy Supply Chain Attack(by TTE)

💡

Editor Pick
- Trivy 사건은 두번의 공격이 아닌, 하나의 미완 대응에 따른 연속 공격
- 공급망 공격의 본질은 코드가 아닌 신뢰 대상의 문제
- 보안은 신뢰 후 검증이 아닌 신뢰를 제거하는 방향으로 전환

보안 사고는 대개 하나의 사건으로 기록된다. 언제 발생했고, 어떤 취약점이 이용되었으며, 어떤 피해가 있었는지로 정리되고, 그 사건은 일정 시점에서 종료된 것으로 정리된다. 그러나 Trivy 사건은 이러한 관점 자체가 얼마나 위험한 단순화인지 보여준다. 이 사건은 단일 침해가 아닌, 시간차를 두고 이어진 하나의 연속된 공격 흐름이었기 때문이다. 2026년 2월 말 발생한 1차 사고와 3월 19일 발생한 공급망 공격은 분리된 사건이라기 보다는 동일한 구조 안에서 이어진 결과이다. 결국 이 사건의 본질을 이해하고 보다 나은 방향으로 진전을 가져오기 위해 “어떻게 침해되었는가”를 묻기 보다, “침해 이후 무엇이 제대로 이루어지지 않았는가”라는 질문이 중요하다.

권한 모델이 무너질 때, 취약점은 필요 없다

1차 사고는 GitHub Actions의 pull_request_target 설정에서 시작되었다. 이 트리거는 외부 Pull Request를 기반으로 워크플로를 실행하면서도 내부 저장소의 비밀 정보에 접근할 수 있는 권한을 유지한다는 특성을 가진다. 이는 자동화 편의를 위해 설계된 구조지만, 외부 입력이 충분히 검증되지 않은 상태에서 실행될 경우, 내부 환경으로 외부 코드가 유입되는 경로가 된다.

실제 공격에서는 과도한 권한이 부여된 GITHUB_TOKEN과 결합되면서 이 구조가 결정적인 취약점으로 작동했다. 공격자는 단순한 PR 요청만으로 GitHub 호스팅 러너에서 임의 코드 실행 권한을 확보했고, 그 과정에서 특권 개인 액세스 토큰(PAT)을 탈취했다. 이는 단순한 취약점 악용이라기 보다, 신뢰를 전제로 설계된 권한 모델이 공격 표면으로 전환된 사례다.

❗

"소프트웨어 ‘취약점’이 아닌 ‘기능’을 무기화하다"의 내용과 연관지어 사고를 확장할 수 있다고 판단

to be continued sigange — Photo by Reuben Juarez / Unsplash

사고는 끝나지 않는다 : 대응이 실패할 때 공격은 지속된다

Trivy 사건의 전환점은 1차 침해 이후 발생했다. Aqua Security는 침해 사실을 인지한 뒤 비밀번호와 토큰을 교체했지만, 이 과정은 보안적으로 완결된 형태, 즉 원자적(Atomic)으로 이루어지지 않았다. 원자적으로 대응이 이루어 지지 않았다는 것은 기존 접근이 완전히 차단되기 전에 새로운 자격 증명이 생성되고 배포되었음을 의미한다.

❗

해외 매체에서 대응이 "Atomic"하게 이루어지지 않았다 표현하고 있다. 이는 대응에 있어 더 이상 쪼갤 수 없는 하나의 단위로 구분지어 모든 단위 절차가 완전 무결한 상태가 되도록 대응을 완료해야 한다는 의미이다.

공격자는 이미 시스템 내부에 있었으며, 그 위치는 단순 외부 관찰자가 아닌 내부 상태를 확인할 수 있는 수준이었다. 그 결과 공격자는 기존 권한을 유지한 채 새로운 토큰 생성 과정을 관찰하거나 가로챌 수 있었고, 일부 경우에는 새로운 자격 증명까지 확보할 수 있었다. 방어자는 권한을 회수했다고 판단했지만, 실제로는 공격자가 사용할 수 있는 권한의 범위를 확장시키는 결과를 초래했다.

보안 대응이 실패한다는 것은 단순히 “완전히 막지 못했다”는 의미가 아니다. 그것은 공격의 흐름을 끊지 못하고, 오히려 다음 단계를 준비할 시간을 제공했다는 의미이다. 결국 사고는 종료되지 않고, 구조적으로 연장 또는 확장된다.

a close up of a street sign on the ground — Photo by Richard Bell / Unsplash

두 번째 공격은 새로운 공격이 아니다

3월 19일 발생한 공급망 공격은 표면적으로 보면 새로운 사건처럼 보인다. 날짜도 다르고, 공격 방식도 크고 더욱 노골적이며, 피해 범위 역시 2월 말의 1차 사고와는 비교하기 어려울 정도로 넓어 보인다. 실제로 많은 조직은 이런 경우 첫 번째 사고를 “초기 침해”, 두 번째 사고를 “본격적인 공급망 공격”으로 분리해 이해하려는 경향이 있다. 그러나 Trivy 사례에서는 이러한 구분이 사건의 실체를 오히려 흐린다. 이 공격은 새로운 공격이라기보다, 1차 사고에서 확보한 권한과 잔류 접근을 바탕으로 실행된 다음 단계의 공격으로 보는 편이 더 정확하다.

이 부분이 중요한 이유는, 두 번째 공격을 독립된 사건으로 보는 순간 방어의 실패가 단지 “한 번 더 발생한 사고”처럼 축소되기 때문이다. 그러나 실제 구조는 다르다. 1차 사고에서 공격자는 pull_request_target의 권한 구조를 악용해 특권 개인 액세스 토큰(PAT)을 탈취했고, 이후 대응 과정에서도 그 접근이 완전히 제거되지 않았다. 자격 증명 교체가 원자적으로 이루어지지 않았다는 것은 단순히 절차가 다소 미흡했다는 의미가 아니다. 그것은 공격자가 이미 내부에 남아 있는 상태에서 방어자가 시스템을 복구하려 했고, 그 과정에서 공격자의 잔류 권한을 완전히 차단하지 못했다는 뜻이다. 결국 3월 19일의 공격은 새로운 침투의 결과가 아닌, 제거되지 않은 권한이 충분한 시간과 기회를 얻었을 때 어떤 규모의 공격으로 발전할 수 있는지를 보여준 것이다.

실제로 두 번째 공격의 실행 방식도 연속성을 강하게 시사한다. 공격자는 새롭게 취약점을 탐색하거나 다른 진입점을 확보하는 대신, 이미 확보한 권한을 이용해 aquasecurity/trivy-action 저장소의 태그를 직접 조작했다. 전체 77개 태그 가운데 76개가 악성 커밋으로 다시 연결되었고, 이 과정은 단순한 훼손이 아닌 매우 정교한 위장과 함께 이루어졌다. 공격자는 기존 작성자 이름과 타임스탬프, 커밋 메시지를 최대한 유지하여 저장소 이력상으로는 정상 릴리스처럼 보이게 만들었다. 이 공격은 “다시 들어온 공격자”의 행동이라기보다, 이미 안에 들어와 있던 공격자가 신뢰 체계를 자신에게 유리한 방식으로 재배치한 행동에 가깝다.

여기서 주목해야 할 점은, 두 번째 공격이 기술적으로 더 정교해서 위험한 것이 아닌, 첫 번째 실패가 구조적으로 축적된 결과라는 사실이다. 많은 조직은 사고 대응을 “접근 차단”과 “비밀번호 변경” 수준에서 끝낸다. 하지만 공격자가 이미 자동화 계정, 릴리스 경로, 토큰, 워크플로, 태그 체계까지 이해한 상태라면, 그 뒤에 일어나는 공격은 단순 재침입 수준을 넘어 인프라 운영 논리 전체를 악용하는 단계로 진입한다. Trivy 사건에서 두 번째 공격은 바로 그 지점을 보여준다. 공격자는 더 이상 몰래 숨어 있을 필요가 없었다. 이미 확보한 권한을 기반으로, 사용자의 배포 습관과 Git 태그에 대한 신뢰, CI/CD의 자동 실행 구조를 역이용해 자신이 원하는 코드가 대규모로 실행되도록 만들 수 있었다. 이때 공격의 본질은 저장소 훼손보다는 배포 체계의 정상 동작을 공격 수단으로 바꾸는 것이었다.

그래서 이 두 번째 공격은 첫 번째보다 더 크지만, 더 놀라운 사건은 아니다. 오히려 1차 사고가 충분히 종결되지 않았을 때 어떤 일이 필연적으로 뒤따르는지를 보여주는 장면에 가깝다. 모든 공격자는 단순 접근을 원하기 보다는 지속 가능한 권한과 신뢰 경로에 대한 통제권을 원한다. 3월 19일 일어난 일련의 행위는 공격자가 목적을 실현했을 때, 나타날 수 있는 현상을 보여준 것이다. 이런 의미에서 Trivy 사건은 두 번의 사고가 아닌 초기 침해, 불완전한 대응, 잔류 권한 유지, 신뢰 경로 장악, 대규모 악성 배포로 이어지는 하나의 공격 흐름으로 읽어야 한다. 그렇게 보지 않으면 우리는 2차 피해의 규모만 보고 놀라게 될 뿐, 왜 그것이 가능했는지에 대한 더 근본적인 질문에는 도달하지 못한다.

핵심은 분명하다. 두 번째 공격은 첫 번째 공격 이후에 발생한 사건이 아닌, 첫 번째 공격이 끝나지 않았기 때문에 가능했던 사건이다. 그리고 바로 그 지점에서 Trivy 사례는 모든 조직에 불편한 질문을 남긴다. 우리는 사고를 “발생”과 “조치”의 문제로만 이해하고 있는가, 아니면 공격자가 남긴 잔류 권한과 신뢰 체계의 훼손까지 포함해 공격의 전체 수명주기를 이해하고 보고 있는가. Trivy의 3월 19일은 단지 더 큰 공격의 날짜가 아니다. 그것은 2월 말의 침해가 실제로는 끝난 적이 없었다는 사실이 드러난 날짜다.

gray asphalt road in between green trees during daytime — Photo by Clay Banks / Unsplash

보안 도구가 공격 인프라가 되는 순간

이번 Trivy 사건이 특히 불편한 이유는, 공격자가 단순히 널리 쓰이는 오픈소스 액션 하나를 오염시켰기 때문만은 아니다. 더 본질적인 문제는, 그 오염된 대상이 하필이면 보안을 검증하기 위해 실행되는 도구였다는 점에 있다. 일반적인 빌드 도구나 유틸리티가 침해되는 경우에도 물론 위험은 크다. 그러나 보안 스캐너는 그 성격상 더 높은 수준의 신뢰를 전제로 파이프라인 안으로 들어온다. 조직은 Trivy를 실행할 때 그것을 외부 코드로 대하기보다, 취약점 점검과 정책 검사라는 보안 목적을 수행하는 ‘정당한 내부 행위자’처럼 취급한다. 이 신뢰의 비대칭성이 바로 이번 공격의 핵심 조건이었다.

실제로 CI/CD 환경에서 보안 스캐너는 대개 배포 직전 또는 이미지 생성 직후의 민감한 단계에서 실행된다. 이 시점의 러너에는 이미 다양한 정보가 적재되어 있다. GitHub Actions 비밀값, 클라우드 제공자 자격 증명, 컨테이너 레지스트리 로그인 정보, 쿠버네티스 토큰, 서명 키, 배포용 SSH 키, 때로는 데이터베이스 접속 정보까지 메모리나 환경 변수, 임시 파일 형태로 존재한다. Trivy 사건에서 삽입된 악성 코드는 바로 이 구조를 정면으로 노렸다. 단순히 환경 변수 몇 개를 읽는 수준을 넘어 프로세스 메모리와 파일 시스템 전체를 수색하는 방식으로 비밀값을 수집하도록 설계되었다. 업로드된 자료에 따르면 공격 코드는 /proc/{PID}/mem을 직접 읽어 실행 중인 프로세스 메모리에서 GitHub Actions의 비밀 정보를 추출하려 했고, 동시에 AWS, GCP, Azure 자격 증명, SSH 키, 쿠버네티스 관련 토큰, 데이터베이스 암호, 암호화폐 지갑 키와 같은 민감 정보를 광범위하게 탐색했다.

이 지점에서 중요한 것은, 공격자가 단순히 “Trivy를 변조했다”는 사실이 아니다. 더 중요한 것은 그 변조가 보안 스캔이라는 정상 동작의 앞부분에 삽입되었다는 점이다. 악성 코드는 entrypoint.sh 초반부에 약 100~200줄 규모로 주입되어, 실제 스캔이 시작되기 전에 먼저 실행되도록 구성되었다. 그 뒤에는 원래의 보안 스캔 로직이 계속 수행되며, 최종 로그 역시 정상적인 검사 결과처럼 출력된다. 이 구조는 악성 행위를 숨기기 위한 단순 위장으로 치부하기 보단 보안 도구의 존재 자체를 역이용하는 설계로 바라봐야 한다. 방어자는 보안 강화를 위해 스캐너를 실행했지만, 공격자는 바로 그 행위를 민감 정보 수집과 외부 유출의 최적 타이밍으로 활용한 것이다.

또 하나 주목해야 할 부분은 유출 방식의 이중화다. 공격 코드는 수집한 데이터를 AES-256-CBC 방식으로 암호화한 뒤, 공격자가 제어하는 유사 도메인으로 전송하도록 구성되었다. 만약 외부 전송 경로가 네트워크 정책이나 탐지 시스템에 의해 막힐 경우를 대비해, 탈취한 토큰을 이용해 피해자의 GitHub 계정 내부에 tpcp-docs라는 공개 저장소를 생성하고 그곳에 데이터를 업로드하는 백업 유출 경로까지 설계했다.이는 단순한 정보 탈취기로 바라보기 보단 네트워크 차단과 탐지 가능성까지 고려한 진화된 악성 코드로 바라봐야 한다. 공격자는 보안 도구를 변조한 것에서 멈추지 않고, 그 도구가 실행되는 환경의 특성과 대응 시나리오까지 계산한 뒤 다중 경로 유출 체계를 삽입했다.

더 본질적으로 보면, 이 사건은 “보안 도구”라는 범주가 왜 보다 위험한지 보여준다. 일반 도구는 실행되기 전에 어느 정도 의심받을 수 있다. 그러나 보안 도구는 조직 내부에서 의심의 대상이라기 보다는 신뢰의 근거로 작동한다. 로그에 ‘스캔 완료’가 남고, 취약점 보고서가 생성되며, 정책 검사가 통과되면, 사람들은 그 실행 자체를 안전의 증거로 받아들이기 쉽다. Trivy 사건은 바로 이 심리적, 운영적 특성을 이용했다. 감염 사실은 숨겨지고, 정상 결과는 출력되며, 사용자는 오히려 안심한다. 그 순간 공격은 성공하는 것을 넘어 정상 운영으로 위장한 채 지속될 수 있는 상태에 들어간다.

이번 사건은 단순히 “보안 스캐너도 뚫릴 수 있다”는 교훈으로 정리되어서는 부족하다. 더 정확한 교훈은 보안 도구는 조직이 가장 높은 수준의 신뢰를 부여하는 코드이며, 그렇기 때문에 한 번 오염되면 일반 애플리케이션보다 훨씬 깊숙하게 시스템 안으로 침투할 수 있다는 것을 이해해야 한다. 또 한가지 이번 사고에서 중요한 점은 취약점을 탐지하는 프로그램과 같은 보안 도구는 자격 증명이 밀집된 환경에서 합법적으로 실행되는 고권한 코드 조각으로 바라봐야 한다는 것이다. Trivy 사례는 이 사실을 극단적으로 보여준다. 보안을 위해 들여온 코드가 공격 인프라로 바뀌는 순간, 우리는 더 이상 “도구를 실행하고 있는 것”이 아닌, 공격자에게 우리 인프라 내부에서 합법적으로 움직일 기회를 제공하고 있는 것이다.

brown wooden dock near body of water under cloudy sky during daytime — Photo by Zuzana Ruttkay / Unsplash

공급망 공격을 잘못 이해하고 있다는 문제

Trivy 사건이 남기는 또 다른 불편함은, 많은 조직이 여전히 공급망 공격을 너무 단순한 방식으로 이해하고 있다는 점에 있다. 공급망 공격이라는 말을 들으면 사람들은 대개 악성 패키지, 오염된 라이브러리, 위조된 업데이트 파일, 혹은 외부 의존성의 취약성을 먼저 떠올린다. 물론 그것들도 공급망 공격의 일부다. 그러나 이런 이해는 공격의 실체를 지나치게 “외부 코드의 문제”로만 축소한다. 그렇게 되면 대응 역시 자연스럽게 외부 패키지 검증, SBOM 구축, 버전 관리 강화, 알려진 취약점 점검 같은 방향으로만 수렴한다. 이 조치들이 무의미한 것은 아니지만, Trivy 사례는 그것만으로는 핵심을 놓친다는 사실을 보여준다.

이번 사건에서 공격자는 많은 사용자가 이미 신뢰하고 있던 공식 저장소, 공식 태그, 공식 보안 도구의 배포 경로를 그대로 사용했다. 겉보기에는 아무것도 바뀌지 않았다. 사용자는 같은 저장소를 참조했고, 같은 버전 문자열을 사용했으며, 같은 CI/CD 워크플로를 실행했다. 그러나 실제로 바뀐 것은 그 참조가 가리키는 대상이었다. 공격자는 코드를 새로 들여오는 대신, 기존 신뢰 경로가 연결되는 목적지를 바꾸었다. 이 차이는 매우 중요하다. 왜냐하면 이번 공급망 공격의 핵심은 "무엇이 들어왔는가"보다 "무엇을 신뢰하는가"에 있기 때문이다.

우리는 공급망 공격은 외부에서 유입되는 침입의 문제로 이해하려 한다. 외부에서 악성 코드가 들어오고, 내부 시스템이 그것을 받아 실행하는 그림을 전제로 생각한다. 하지만 Trivy 사건은 내부에서 이미 정상으로 간주되던 배포 구조, 태그 체계, 자동 실행 메커니즘, 그리고 보안 도구에 대한 신뢰가 공격 수단으로 전환되었다. 다시 말해 이번 사건은 공급망 공격이 단순히 “위험한 외부 요소를 걸러내는 문제”가 아닌, 조직 내부가 정상이라고 간주하는 연결 구조 자체를 어떻게 방어할 것인가의 문제임을 드러낸다.

이 오해가 반복되는 이유는 공급망이라는 말을 너무 단어 그대로 이해하기 때문이다. 많은 경우 공급망은 공급업체, 오픈소스 패키지, 업데이트 서버, 서드파티 서비스처럼 조직 외부에 있는 대상들의 집합으로 보기 때분이다. 그러나 현대 소프트웨어 공급망은 그렇게 단순하지 않다. 공급망은 단지 누가 코드를 만들었는가의 문제라기 보다는, 코드가 어떤 권한으로 빌드되고, 어떤 참조를 따라가 가져오며, 어떤 자동화 절차를 거쳐 배포되고, 어떤 키와 토큰에 의해 신뢰를 부여받는가를 포함하는 운영 구조 전체로 인식해야 한다. 이 관점에서 보면 Trivy 사건은 외부 공급망의 오염이라기보다, 공급망을 구성하는 내부 신뢰 구조의 붕괴에 가깝다. 공격자는 본인이 원하는 소프트웨어를 납품한 것 이상의 효과를 위해 납품된 것으로 간주되는 경로를 장악한 것이기 때문이다.

그래서 공급망 공격을 “패키지 오염” 정도로만 이해하면, 가장 중요한 문제를 놓치게 된다. 예를 들어 많은 조직은 버전 고정(Version Pinning)을 하면 공급망 위험이 줄어든다고 생각한다. 그러나 Trivy 사례는 태그 기반의 버전 고정이 어떻게 무력화될 수 있는지를 보여준다. @v0.34.2처럼 보이는 표현은 사용자에게 안정성과 불변성을 암시하지만, Git 태그는 본질적으로 권한을 가진 자가 다른 커밋으로 다시 가리키게 만들 수 있는 포인터다. 즉 사용자는 고정했다고 믿었지만, 실제로는 고정된 이름을 신뢰하고 있었을 뿐 고정된 대상 자체를 검증한 것은 아니었다. 이 차이는 사소해 보이지만, 공급망 공격의 성패를 가르는 핵심이다. 공격자는 바로 이 틈, 이름과 실체 사이의 간극을 파고든다.

또 하나의 오해는 공급망 공격을 단발성 오염 사건처럼 바라보는 습관이다. 이런 시선은 악성 패키지가 한 번 올라왔고, 그것을 제거하면 사건이 끝난다고 생각하도록 한다. 하지만 Trivy 사건은 공급망 공격이 훨씬 더 장기적이고 구조적인 공격일 수 있음을 보여준다. 2월 말의 1차 사고에서 공격자는 초기 접근만 확보한 것을 넘어 공격자는 이후 릴리스와 배포 경로를 통제할 수 있는 기반을 손에 넣었다. 그리고 3월 19일의 태그 변조 공격은 그 기반이 실제 운영 환경 전체를 겨냥하는 방식으로 전개되었다. 즉 공급망 공격을 더 이상 “오염된 코드가 유입되었다”는 사건으로 바라보기 보다는 신뢰를 부여하는 권한과 경로가 장악된 상태에서 공격자가 원하는 시점에 원하는 방식으로 악성 행위를 유통할 수 있게 되는 상태가 되었다고 바라봐야 한다. 이런 상태에서는 악성 패키지 하나를 지우는 식의 대응으로는 충분하지 않다. 문제는 단지 코드 한 조각이 아닌 유통 구조 그 자체이기 때문이다.

이 사건은 또한 보안 실무가 공급망 공격을 얼마나 “탐지 가능한 이벤트” 중심으로 이해하고 있는지도 돌아보게 만든다. 많은 방어 체계는 알려진 IOC, 악성 해시, 비정상 네트워크 연결, 혹은 신규 패키지 등록 같은 눈에 띄는 변화를 찾는 데 익숙하다. 그러나 Trivy 사례에서는 기존 저장소, 기존 태그, 기존 워크플로, 기존 보안 도구가 그대로 유지된 것처럼 보였다. 다시 말해 공격은 이상 징후를 만드는 대신, 정상성을 흉내 내는 방식으로 수행되었다. 이것은 공급망 공격의 난점을 잘 보여준다. 현대의 공급망 공격은 무언가 낯선 것을 들여오는 방식보다, 우리가 이미 안전하다고 믿는 것을 계속 안전해 보이게 만드는 방식으로 더 성공적으로 작동한다. 그래서 공급망 공격을 단순히 외부 코드 필터링의 문제로 다루는 조직은, 가장 결정적인 공격 장면을 놓치기 쉽다.

결국 Trivy 사건이 던지는 교훈은 단순하지 않다. 공급망 공격은 더 이상 “외부 라이브러리 조심하자” 수준의 경고가 아니다. 그것은 우리가 코드, 버전, 태그, 빌드, 배포, 서명, 자격 증명, 자동화 계정에 부여해온 신뢰가 어떤 구조로 연결되어 있는지를 다시 묻는 문제다. 그리고 무엇이 안전한가를 묻는 것보다, 무엇이 안전하다고 간주되는가를 묻는 쪽이 더 중요해진 시대다. Trivy 사례는 바로 그 지점을 선명하게 보여준다. 공급망 공격의 실체는 우리가 정상이라고 믿는 경로 안에, 그리고 그 정상성을 떠받치고 있는 신뢰 모델 안에 있다.

우리가 다시 물어야 할 질문

Trivy 사건을 통해 드러난 구조는 명확하다. 침해사고는 취약점으로만 이루어지지 않고 권한 구조 등 다양한 약한 고리를 파고들며, 사고는 침해로 끝나지 않고 대응 실패를 통해 확장된다. 그리고 공급망 공격은 코드의 문제를 넘어 신뢰 모델의 문제라는 점이다. 이제 남는 질문은 단순하지 않다. 우리는 여전히 태그를 신뢰할 것인지, CI/CD의 자동 실행 구조를 그대로 유지할 것인지, 자격 증명을 교체하는 것만으로 충분하다고 믿을 것인지 다시 생각해야 한다. 그리고 그보다 더 근본적으로, 우리는 여전히 ‘신뢰’를 전제로 시스템을 설계하고 있는 것은 아닌지 돌아볼 필요가 있다. Trivy 사건은 분명하게 말한다. 공격은 끝난 적이 없다. 우리가 그것을 끝났다고 믿었을 뿐이다. 🆃🆃🅔