Trivy 생태계 공급망 공격: 악성 릴리즈 배포 및 GitHub Actions 태그 탈취 사건
Trivy ecosystem supply chain briefly compromised
TL;DR Highlight
오픈소스 취약점 스캐너 Trivy가 2026년 3월 19일 공급망 공격으로 악성 바이너리 및 자격증명 탈취 악성코드로 변조된 GitHub Actions 태그 76개를 배포했다.
Who Should Read
CI/CD 파이프라인에서 Trivy를 사용해 컨테이너 이미지나 코드를 취약점 스캔하는 DevSecOps 엔지니어나 백엔드 개발자. 특히 GitHub Actions에서 aquasecurity/trivy-action 또는 aquasecurity/setup-trivy를 사용하는 팀.
Core Mechanics
- 2026년 3월 19일, 공격자가 탈취한 자격증명(크리덴셜)을 이용해 Trivy v0.69.4 악성 릴리즈를 공식 배포 채널(GitHub, Deb, RPM, GHCR, ECR Public, Docker Hub)에 업로드했다. 이 버전을 설치하면 자격증명 탈취 악성코드에 감염된다.
- GitHub Actions 레포지토리인 aquasecurity/trivy-action의 태그 77개 중 76개가 악성 커밋으로 강제 덮어씌워졌고(force-push), aquasecurity/setup-trivy의 태그 7개 전부도 교체됐다. 태그를 핀닝 없이 사용하는 워크플로우는 모두 악성코드를 실행하게 됐다.
- 노출 시간은 컴포넌트마다 달랐다. trivy v0.69.4 바이너리/이미지는 약 3시간(UTC 18:22~21:42), trivy-action 태그는 약 12시간(UTC 17:43~다음날 05:40), setup-trivy 태그는 약 4시간(UTC 17:43~21:44) 동안 악성 상태였다.
- v0.69.3 이전 버전은 안전하다. v0.69.3은 2026년 3월 3일에 활성화된 GitHub의 immutable releases(릴리즈 변경 불가) 기능으로 보호되어 변조가 불가능했고, 악성 코드는 Trivy의 main 브랜치에는 커밋되지 않았다.
- 안전한 사용 방법으로는 다이제스트(digest)로 컨테이너 이미지를 참조하거나, 소스코드에서 직접 빌드하거나, Homebrew 공식 formula(brew install trivy)를 사용하는 경우가 있다. 공식 Homebrew formula는 소스에서 직접 빌드하므로 영향받지 않았다.
- 이번 공격은 이전에 발생한 Trivy 보안 사고(Socket.dev 보고서: 무단 AI 에이전트 실행 코드 관련)와 연결된 것으로 분석된다. 첫 번째 침해 이후 자격증명 교체(rotation)가 원자적으로(모든 서비스에서 동시에) 이루어지지 않았고, 공격자가 잔류하여 두 번째 공격을 감행한 것으로 보인다.
- 패치된 버전은 trivy v0.69.3(다운그레이드), trivy-action v0.35.0, setup-trivy v0.2.6이다. 해당 버전으로 업그레이드하거나 다운그레이드해야 하며, 노출 시간대에 실행된 워크플로우 로그를 확인해 자격증명 유출 여부를 점검해야 한다.
Evidence
- '공급망 공격(supply chain attack)'이라는 용어 사용에 대해 커뮤니티에서 비판이 나왔다. 이번 사건은 외부 의존성이 아니라 Aqua Security가 직접 관리하는 자체 인프라가 침해된 것이므로, '공급망 공격'이라는 표현은 책임을 희석시키려는 뉘앙스가 있다는 지적이다. 실제로는 Trivy를 사용하는 모든 사람이 피해자이고, 공격 대상은 Trivy 자체였다.
- 이번 공격이 '일시적(briefly)'이었다는 표현에도 이의가 제기됐다. 이전 침해 사고와의 연속성을 고려하면 공격자가 두 사건 사이에도 지속적으로 내부에 잔류(persist)했을 가능성이 높다는 분석이다. 실제로 Socket.dev의 연구에 따르면 이 공격은 이전 무단 AI 에이전트 실행 사건과 연결되어 있으며, 첫 번째 침해 후 원자적 자격증명 교체가 이루어지지 않은 것이 두 번째 공격의 빌미가 됐다.
- GitHub Actions에서 태그 대신 SHA 해시로 액션을 고정(pin)하는 방법이 핵심 방어 수단으로 다시 주목받았다. 태그는 언제든 다른 커밋으로 덮어씌울 수 있기 때문에 보안상 신뢰할 수 없으며, 'actions/checkout@v4' 대신 'actions/checkout@<full-sha>'처럼 사용해야 한다는 의견이 강조됐다.
- 커뮤니티에서는 '보안 도구 자체가 최고의 공격 타겟'이라는 아이러니가 반복적으로 언급됐다. 취약점을 스캔하는 도구가 오히려 공급망 전체를 침해하는 단일 접근점이 된다는 구조적 문제를 지적한 것이다. '취약점 스캐너가 곧 취약점이 됐다'는 표현이 가장 많은 공감을 얻었다.
- 자격증명을 여러 서비스에 걸쳐 동시에 교체(atomic rotation)하는 것이 현실적으로 어렵다는 현실적 문제도 토론됐다. 여러 서비스, 머신, 사용자에 걸친 크리덴셜을 동시에 무효화하려면 어떻게 해야 하는가라는 질문에 대한 명확한 답이 없다는 점이 지적됐고, 이것이 이번 사고의 근본 원인 중 하나로 분석됐다.
How to Apply
- GitHub Actions에서 aquasecurity/trivy-action이나 aquasecurity/setup-trivy를 사용 중이라면 즉시 버전을 trivy-action@v0.35.0, setup-trivy@v0.2.6 이상으로 업데이트하고, 태그 대신 전체 SHA 해시로 고정(pin)하도록 워크플로우를 수정해야 한다. 예: `uses: aquasecurity/trivy-action@<full-commit-sha>`
- 노출 시간대(UTC 2026-03-19 17:43 ~ 2026-03-20 05:40)에 Trivy를 실행했다면 해당 워크플로우가 접근했던 모든 시크릿(AWS 키, GitHub 토큰, 레지스트리 패스워드 등)을 즉시 교체해야 한다. 특히 trivy-action은 약 12시간 동안 악성 상태였으므로 이 시간대의 CI 로그를 반드시 점검해야 한다.
- 컨테이너 이미지를 Trivy로 스캔하는 경우, 이미지를 태그가 아닌 다이제스트(digest)로 참조하면 이런 태그 교체 공격에 대응할 수 있다. 예를 들어 `aquasecurity/trivy:latest` 대신 `aquasecurity/trivy@sha256:<digest>`로 사용하면 이미지가 변조되더라도 다른 이미지가 실행되지 않는다.
- 보안 사고 발생 후 자격증명을 교체할 때는 모든 서비스(GitHub, Docker Hub, AWS ECR, npm 등)에서 동시에 교체하는 절차를 미리 문서화하고 자동화해두어야 한다. 이번 사고는 첫 번째 침해 이후 원자적 교체가 이루어지지 않아 공격자가 잔류하면서 두 번째 공격으로 이어진 사례로, 인시던트 대응 플레이북에 이 항목을 반드시 포함해야 한다.
Code Example
# 안전하지 않은 방식 (태그 사용 - 공격에 취약)
- uses: aquasecurity/trivy-action@master
- uses: aquasecurity/trivy-action@v0.34.0
# 안전한 방식 1: 패치된 버전 태그 사용
- uses: aquasecurity/trivy-action@v0.35.0
# 안전한 방식 2: SHA 해시로 고정 (가장 권장)
# 먼저 커밋 SHA 확인: https://github.com/aquasecurity/trivy-action/commits/main
- uses: aquasecurity/trivy-action@<full-commit-sha>
# 컨테이너 이미지 다이제스트로 참조 (태그 교체 공격 방어)
# 태그 사용 (취약)
docker pull aquasecurity/trivy:0.69.4
# 다이제스트 사용 (안전)
docker pull aquasecurity/trivy@sha256:<digest>
# 설치된 trivy 버전 확인
trivy --version
# output: Version: 0.69.4 -> 이 경우 즉시 교체 필요
# output: Version: 0.69.3 -> 안전Terminology
관련 논문
LLM이 TLA+로 실제 시스템을 제대로 모델링할 수 있을까? — SysMoBench 벤치마크
LLM이 TLA+ 명세를 작성할 때 문법은 잘 통과하지만 실제 시스템과의 동작 일치도(conformance)는 46% 수준에 그친다는 걸 체계적으로 검증한 벤치마크 연구로, AI 기반 형식 검증의 현실적 한계를 보여준다.
Natural Language Autoencoders: Claude의 내부 활성화를 자연어 텍스트로 변환하는 기법
Anthropic이 LLM 내부의 숫자 벡터(활성화값)를 직접 읽을 수 있는 자연어로 변환하는 NLA 기법을 공개했다. AI가 실제로 무슨 생각을 하는지 해석하는 interpretability 연구의 새로운 진전이다.
ProgramBench: LLM이 프로그램을 처음부터 다시 만들 수 있을까?
LLM이 FFmpeg, SQLite, PHP 인터프리터 같은 실제 소프트웨어를 문서만 보고 처음부터 재구현할 수 있는지 측정하는 새 벤치마크로, 최고 모델도 전체 태스크의 3%만 95% 이상 통과하는 수준에 그쳤다.
MOSAIC-Bench:코딩 에이전트의 Compositional Vulnerability 유도 측정
티켓 3장으로 쪼개면 Claude/GPT도 보안 취약점 코드를 53~86% 확률로 그냥 짜준다.
LLM의 거절(Refusal) 동작은 단 하나의 방향(Direction)으로 제어된다
13개의 오픈소스 채팅 모델을 분석했더니, 모델이 유해한 요청을 거절하는 동작이 내부 활성화 공간에서 단 하나의 1차원 벡터 방향으로 인코딩되어 있었다. 이 방향을 제거하면 안전 파인튜닝이 사실상 무력화되므로, 현재 안전 학습 방식이 얼마나 취약한지 보여준다.
LLM의 구조화된 출력(Structured Output)을 테스트하는 새 벤치마크 SOB 공개
스키마 준수 여부만 보던 기존 벤치마크의 한계를 넘어, 실제 값의 정확도까지 7가지 지표로 평가하는 Structured Output Benchmark(SOB)가 공개됐다. 인보이스 파싱, 의료 기록 추출처럼 JSON 출력의 정확성이 중요한 프로덕션 시스템에서 어떤 모델을 써야 할지 판단하는 데 직접적으로 참고할 수 있다.