소프트웨어 공급망 보안 사고 사례와 대응 방안 1편ㅣ2026년 Trivy 공급망 공격 분석

취약점을 찾기 위해 도입한 보안 도구가 오히려 자격증명을 훔치는 공격 도구로 바뀐다면 어떻게 될까요?

2026년 2월 말 시작돼 3월 본격화된 Trivy 공급망 공격은 오늘날 소프트웨어 공급망의 핵심 위험을 보여준 대표 사례입니다. 공격자는 최종 사용자를 직접 공격하는 대신, 많은 개발 조직이 신뢰하는 오픈소스 보안 스캐너의 개발·배포 경로를 침해했습니다. 이후 정상적인 버전 태그와 배포 채널을 악용해 악성코드가 실행되도록 하고 CI/CD 환경에서 탈취한 자격증명을 발판으로 피해를 다른 개발 도구와 패키지 생태계까지 확산시켰습니다.

이번 글에서는 복잡해진 소프트웨어 공급망의 위험을 살펴보고, 2026년 Trivy 공격이 어떻게 이어졌는지와 이 사고가 남긴 주요 보안 교훈을 정리합니다.

1. 오픈소스·AI·자동화가 넓힌 소프트웨어 공급망

🧑‍💻 오픈소스와 AI 활용으로 복잡해진 개발 환경

오늘날 하나의 소프트웨어는 조직이 직접 작성한 코드만으로 완성되지 않습니다. 오픈소스 라이브러리와 프레임워크, 제3자 소프트웨어, 패키지 저장소, IDE 확장 프로그램, GitHub Actions와 같은 CI/CD 도구, 컨테이너 이미지 등 다양한 구성요소와 개발 도구가 연결돼 하나의 제품을 만듭니다.

생성형 AI를 활용한 개발도 빠르게 늘고 있지만 AI 생성 코드 자체가 곧 위험한 것은 아닙니다. 다만 생성 과정에서 코드와 의존성의 출처, 유지보수 상태, 라이선스와 보안성을 개발자가 놓치기 쉬우므로 실제 적용 전 별도의 검증이 필요합니다.

🚨 신뢰된 개발·배포 경로를 노리는 소프트웨어 공급망 공격

소프트웨어 공급망 공격은 보안 체계가 잘 구축된 최종 기업을 직접 공격하기보다, 상대적으로 관리가 취약한 오픈소스 프로젝트나 개발 협력사, 배포 계정과 자동화 도구를 먼저 침해하는 방식으로 무게중심이 이동하고 있습니다. 공격자가 기업이 신뢰하는 구성요소나 배포 경로를 장악하면 정상적인 개발·배포 과정을 이용해 여러 조직으로 피해를 확산시킬 수 있기 때문입니다.

특히 CI/CD 자동화 과정에서는 외부 도구가 저장소와 패키지 배포 계정, 클라우드 환경에 접근할 수 있는 권한을 사용합니다. 따라서 공격자가 널리 사용되는 개발 도구나 배포 계정을 장악하면 해당 도구를 사용하는 여러 조직의 개발 환경으로 피해를 빠르게 확산시킬 수 있습니다.

공급망 공격의 핵심은 바로 이 ‘신뢰의 전이’에 있습니다. 정상 프로젝트, 익숙한 버전명, 공식 배포 채널이라는 이유만으로 구성요소를 신뢰하면, 한 번의 침해가 이를 사용하는 여러 조직의 개발자 PC와 빌드 서버, 클라우드 환경으로 동시에 확산될 수 있습니다.

2. 2026년 Trivy 공급망 공격: 보안 도구가 공격 도구가 되다

Trivy는 소스 저장소와 컨테이너 이미지, 클라우드 네이티브 환경의 취약점 등을 점검하는 오픈소스 보안 스캐너입니다. 많은 조직이 Trivy를 CI/CD 파이프라인에 연결해 빌드와 배포 과정에서 자동으로 실행해 왔습니다.

2026년 3월, 공격자는 Trivy의 개발·배포 자격증명을 악용해 공식 배포 경로를 침해했습니다. 악성 Trivy v0.69.4 릴리스를 배포하고, aquasecurity/trivy-action의 기존 버전 태그 77개 중 76개와 aquasecurity/setup-trivy의 태그 7개를 악성 커밋으로 변경했습니다. 이어 3월 22일에는 별도로 탈취한 Docker Hub 자격증명을 이용해 악성 컨테이너 이미지 v0.69.5와 v0.69.6도 게시했습니다.

이 사고에는 CVE-2026-33634가 부여됐습니다. CVE 발급기관(CNA) 기준 CVSS v4.0 점수는 9.4(Critical)이며, 미국 CISA는 3월 26일 실제 악용된 취약점 목록인 KEV 카탈로그에 이를 추가했습니다.

Trivy 공격은 어떻게 이어졌나

공격 과정은 다음과 같이 정리할 수 있습니다.

악성코드는 환경변수뿐 아니라 Runner.Worker 프로세스 메모리와 파일시스템을 탐색해 SSH 키, GitHub·npm·PyPI 토큰, AWS·GCP·Azure 자격증명, Kubernetes 설정, 데이터베이스 인증정보와 .env 파일 등을 수집했습니다. 수집한 정보는 암호화해 공격자 인프라로 전송했으며, 전송에 실패하면 피해자의 GitHub 계정에 tpcp-docs라는 공개 저장소를 만들어 탈취 정보를 업로드하는 우회 방식도 사용했습니다.

KISA는 이후 탈취된 토큰을 기반으로 npm 패키지, PyPI의 LiteLLM·Telnyx, OpenVSX 확장 프로그램, KICS·AST GitHub Actions 등 여러 생태계로 악성코드가 확산됐다고 설명했습니다. LiteLLM 측도 자사 CI/CD 보안 점검에 사용된 Trivy에서 침해가 시작된 것으로 추정된다고 밝혔습니다. 다만 개별 후속 침해 사이의 구체적인 인과관계는 각 프로젝트의 공개 조사 결과에 따라 구분해 해석할 필요가 있습니다.

3. Trivy 사고가 남긴 네 가지 보안 교훈

1️⃣ CVE 점검만으로는 신뢰된 배포물의 변조까지 확인할 수 없다

일반적인 취약점 관리는 구성요소에서 알려진 CVE를 찾고 안전한 버전으로 업데이트하는 데 집중합니다. 그러나 Trivy 사고의 핵심은 기존 코드에 존재하던 취약 함수가 아니라, 공격자가 배포 권한과 자동화 과정을 악용해 정상 프로젝트의 릴리스에 악성코드를 삽입했다는 점입니다.

따라서 ‘알려진 취약점이 없는 버전’이라는 사실만으로 배포물을 신뢰해서는 안 됩니다. 어떤 저장소와 빌드 과정에서 생성됐는지, 서명과 해시가 유효한지, 배포 이후 태그나 파일이 변경되지 않았는지까지 검증해야 합니다.

2️⃣ 버전 태그는 고정된 식별자가 아닐 수 있다

v1, latest, 0.34.0과 같은 태그는 동일한 이름을 유지한 채 다른 커밋이나 이미지로 변경될 수 있습니다. Trivy 공격에서는 이 특성을 악용해 사용자가 기존과 같은 태그를 호출해도 악성 코드가 실행되도록 만들었습니다.

외부 GitHub Action은 가능한 한 검증된 전체 커밋 SHA로 고정하고, 컨테이너 이미지는 다이제스트로 참조해야 합니다. 상위 Action만 고정해도 그 Action이 내부에서 변경 가능한 다른 Action이나 설치 도구를 호출하면 위험이 남으므로, 연결된 의존관계 전체를 확인해야 합니다.

3️⃣ 애플리케이션 SBOM만으로는 개발 도구의 사각지대가 남는다

SBOM은 제품에 포함된 직접·간접 구성요소와 버전을 파악하는 데 매우 유용합니다. 그러나 일반적인 애플리케이션 SBOM에는 빌드 과정에서만 실행되는 GitHub Actions, IDE 확장 프로그램, 릴리스 스크립트와 외부 보안 도구가 포함되지 않을 수 있습니다.

공급망 사고의 영향 범위를 빠르게 판단하려면 제품 구성요소의 SBOM과 함께 CI/CD 워크플로, 외부 Action, 플러그인, 빌드 이미지와 패키지 저장소의 사용 위치를 별도 자산으로 관리해야 합니다.

4️⃣ 하나의 과도한 권한이 연쇄 피해를 만든다

보안 스캐너는 저장소와 컨테이너, 클라우드 환경을 점검하기 위해 넓은 접근 권한을 부여받기 쉽습니다. 공격자는 이 권한을 이용해 최초 프로젝트를 넘어 다른 저장소와 패키지 배포 계정, 클라우드 환경으로 이동했습니다.

특히 장기간 유효한 토큰을 여러 서비스에서 함께 사용하거나, 점검과 빌드, 배포 권한을 하나의 계정에 집중하면 피해 범위가 커집니다. 공급망 사고 대응은 악성 버전을 삭제하는 데서 끝나지 않으며, 해당 파이프라인에서 접근할 수 있었던 모든 자격증명을 노출된 것으로 간주해 폐기·교체하고 추가 변조 여부를 확인해야 합니다.

4. Trivy 사용 이력이 있다면 우선 확인할 사항

Trivy 사고에 노출됐을 가능성이 있는 조직은 예방 대책을 논의하기 전에 실제 실행 이력과 침해 범위를 먼저 확인해야 합니다.

✔️ 영향 버전과 실행 시간을 확인합니다.

Trivy v0.69.4, 당시 latest 태그, trivy-action·setup-trivy 실행 이력과 캐시를 점검합니다. 3월 22~23일 Docker Hub에서 v0.69.5·v0.69.6 또는 latest 이미지를 가져온 기록도 확인해야 합니다. 정확한 노출 시간과 안전 버전은 최신 공식 보안 권고를 기준으로 판단합니다.

✔️ 파이프라인의 모든 시크릿을 노출된 것으로 간주합니다.

GitHub PAT, 패키지 배포 토큰, SSH 키, 클라우드 자격증명, Kubernetes 토큰과 데이터베이스 비밀번호를 동시에 폐기하고 교체합니다. 단순 재발급에 그치지 않고 교체 전후의 비정상 사용 이력도 확인합니다.

✔️ 유출 및 지속성 지표를 헌팅합니다.

tpcp-docs 저장소 생성 여부, 비정상적인 릴리스·태그 변경, KISA가 안내한 pgmon·sysmon 서비스와 관련 파일, C2 통신 흔적을 점검합니다.

✔️ 신뢰할 수 있는 환경에서 다시 빌드합니다.

오염 가능성이 있는 러너와 캐시를 격리·초기화하고, 검증된 소스와 서명·해시를 기준으로 산출물을 다시 생성합니다. 이후 공격자가 탈취한 권한으로 추가 패키지나 컨테이너를 배포하지 않았는지 전체 배포 이력을 검토합니다.

[참고문헌]
1. 취약점 찾으려다 암호 다 털렸다… ‘Trivy’ 오염 사태 비상 / 보안뉴스 / https://www.boannews.com/news/articleView.html?idxno=142760
2. 개발도구 공급망을 통한 연쇄적 사이버 공격주의 권고 / KISA 보호나라 / https://www.krcert.or.kr/kr/bbs/view.do?searchCnd=&bbsId=B0000133&searchWrd=&menuNo=205020&pageIndex=1&categoryCode=&nttId=72014