3월 셋째 주, 슬랙에 @here가 울렸다. Aqua Security의 Trivy — 컨테이너 취약점 스캐너계의 사실상 표준 — 공식 릴리스에 악성코드가 심어졌다는 보고. CI 파이프라인에서 매일 수백 번 돌리는 바로 그 도구다.

타임라인

공격자는 이전 인시던트에서 완전히 정리되지 않은 접근 권한을 재활용했다. 그 자체가 이미 한 편의 포스트모템 감이다. 침투 후 악성 코드가 공식 릴리스에 주입됐고, Trivy가 CI 러너에서 실행되는 순간 아래 순서가 진행됐다:

  1. 러너 프로세스 목록 탐색

  2. 시크릿이 포함된 환경 변수 식별

  3. Base64 인코딩된 Python 페이로드 디코딩 및 실행

  4. 호스트 핑거프린팅 + 환경 변수 전체 덤프

AWS 키, Docker Hub 토큰, DB 비밀번호 — 러너에 올라와 있던 모든 시크릿이 공격자에게 전송됐을 가능성이 있다. Microsoft 보안팀이 3월 24일 탐지 및 대응 가이드를 공개할 정도로 파급력이 컸다.

여기서 핵심은 공격 기법의 정교함이 아니다. 환경 변수 읽고 외부로 보내는 건 스크립트 몇 줄이면 된다. 핵심은 신뢰받는 도구의 공식 릴리스가 공격 벡터가 됐다는 사실 그 자체다. 우리는 trivy를 파이프라인에 넣으면서 "보안을 강화하고 있다"고 생각했다. 현실은 반대였다.

왜 하필 CI 파이프라인인가

공격자 입장에서 CI/CD만큼 효율 좋은 타겟이 없다.

파이프라인은 코드 저장소, 시크릿 스토어, 배포 타겟에 동시에 접근 권한을 갖는다. 하나만 뚫으면 전부 딸려온다. 거기에 서드파티 플러그인과 액션이 수십 개씩 체이닝되어 있으니, 공급망의 어느 한 지점만 타협해도 전체가 무너진다. JetBrains가 올해 3월 발표한 CI/CD 플러그인 보안 리스크 분석도 같은 맥락이다 — 플러그인이 파이프라인 내부에 위치하는 순간, 파이프라인이 가진 모든 권한을 상속받는다.

2026년 기준 단일 CI/CD 파이프라인 침해의 평균 비용이 510만 달러다. 이건 랜섬웨어 평균 피해액과 비슷한 수준이다.

Self-hosted 러너가 특히 위험한 이유

GitHub-hosted 러너는 작업 끝나면 사라진다. Self-hosted 러너는? 대부분 persistent하게 돌아간다.

한번 악성 워크플로우가 실행되면 공격자는 RUNNER_ALLOW_RUNASROOT=1 설정으로 루트 권한을 탈취하고, 러너 프로세스에 상주하는 백도어를 심고, RUNNER_TRACKING_ID 조작으로 탐지를 우회한다. Sysdig 분석 리포트에 따르면 공격자들은 self-hosted 러너를 아예 C2 채널로 활용하고 있다. 작년 말 Shai-Hulud 웜은 28,000개 이상의 저장소를 감염시키며 이 기법을 대규모로 시연했다.

pull_request_target 트리거를 쓰는 워크플로우가 외부 PR의 코드를 체크아웃해서 self-hosted 러너에서 실행한다면? 공격자가 PR 하나만 올리면 끝이다.

에페메럴 러너, 뻔해도 답이다

"에페메럴 러너 쓰세요"는 이제 지겨울 수 있다. 근데 뻔한 답이 계속 나오는 데는 이유가 있다.

컨테이너나 VM이 단일 작업을 위해 생성되고, 끝나면 즉시 파괴된다. 공격자가 백도어를 심어도 다음 잡에선 깨끗한 환경이 올라온다. 2026년 현재 보안 수준이 높은 조직의 85%가 이미 전환했다.

에페메럴이 당장 어렵다면 최소한 이건 확인하자:

  • 러너 인벤토리 감사 — 지금 돌고 있는 self-hosted 러너 몇 개인지, 누가 등록했는지 파악되는가?

  • 시크릿 노출 범위 최소화 — 환경 변수에 시크릿 전부 때려넣지 말고, 필요한 스텝에만 주입

  • 서드파티 액션 해시 고정 — actions/checkout@v4 말고 actions/checkout@<commit-sha>

  • SBOM + SLSA 적용 — 빌드 아티팩트 출처를 증명할 수 있는 체계

Datadog DevSecOps 2026 리포트의 핵심 문장이 정곡을 찌른다 — "보안을 추가하는 게 아니라, 보안이 기본인 시스템을 설계하는 것."

되돌아보면

Trivy 사건의 진짜 교훈은 "보안 도구도 뚫릴 수 있다"가 아니다. 그건 누구나 안다. 진짜 질문은 — 보안 도구가 뚫렸을 때 피해를 제한할 수 있는 구조였느냐다. 러너가 가진 권한이 필요 최소한이었느냐. 시크릿이 필요 없는 스텝에도 노출되어 있진 않았느냐.

파이프라인 보안은 도구 문제가 아니라 아키텍처 문제다. 에페메럴 러너, 최소 권한 원칙, 해시 고정. 복잡한 거 하나도 없다. 안 하고 있을 뿐이다.