3월의 Trivy 공급망 공격은 단순히 "취약점 스캐너 하나가 뚫렸다"는 사건이 아니었습니다. 공격자는 Trivy의 공식 바이너리와 GitHub Actions 태그를 오염시켜, 이를 쓰는 CI/CD 환경에서 클라우드 자격증명·깃허브 토큰·쿠버네티스 시크릿을 훔쳤고, 이후 Checkmarx KICS와 Bitwarden CLI까지 같은 흐름으로 확장했습니다.12
지금 이 사건이 중요한 이유는 분명합니다. 공격자들이 더 이상 앱 의존성만 노리지 않고, 그 의존성을 "검사하는 도구" 자체를 노리기 시작했기 때문입니다. 특히 Checkmarx와 Bitwarden 같은 보안 기업이 후속 표적이 된 것은 우연이라기보다, 보안 도구가 개발 파이프라인에서 가장 넓은 권한을 가진 소프트웨어이기 때문입니다.3
라이브러리보다 스캐너가 더 위험한 이유
일반적인 오픈소스 라이브러리는 대개 애플리케이션 프로세스 안에서 제한된 역할을 합니다. 반면 보안 스캐너, 린터, GitHub Action, CLI는 빌드 시점에 훨씬 넓은 접근권을 가집니다.
이번 Trivy 사례에서 악성 코드가 노린 것도 바로 그 지점이었습니다. 보고된 행위를 보면 환경 변수 덤프, AWS/GCP/Azure 자격증명 수집, 쿠버네티스 서비스어카운트 파일 탐색, 내부 설정 파일과 데이터베이스 연결 문자열 검색까지 수행했습니다.1 더 중요한 건, 이런 악성 행위 뒤에도 정상적인 Trivy 스캔이 계속 실행되어 운영자가 이상을 눈치채기 어려웠다는 점입니다.1
왜 Checkmarx와 Bitwarden이었을까요. 확인된 사실은 두 회사 모두 이 연쇄 캠페인의 후속 피해자였고, Bitwarden npm 패키지와 Checkmarx KICS 배포 경로에서 유사한 인프라와 수법이 관찰됐다는 점입니다.134 여기서 가능한 해석은 비교적 명확합니다. 보안 기업의 도구는 고객 환경 깊숙이 들어가 있고, 신뢰 수준이 높으며, 종종 조직 전체 리포지토리·시크릿·배포 채널과 연결돼 있습니다. 공격자 입장에서는 한 번의 침해로 더 많은 2차 피해를 만들 수 있는 "증폭기"입니다.3
즉, "우리는 이 도구를 CI에서만 쓴다"는 말은 안심 포인트가 아니라 경고 신호에 가깝습니다. CI야말로 비밀이 가장 많이 모여 있는 곳이기 때문입니다.
15분 안에 끝내는 파이프라인 폭발반경 점검
이번 사건에서 특히 뼈아픈 대목은 GitHub Action 태그 오염입니다. Trivy 쪽에서는 76개 이상의 버전 태그가 강제로 다른 커밋을 가리키도록 바뀌었고, 워크플로 파일을 수정하지 않아도 하위 사용자가 악성 코드를 실행하게 만들었습니다.12 "버전을 고정했다"고 생각한 팀도 사실은 mutable tag를 믿고 있었던 셈입니다.
여기서 바로 점검할 질문은 다섯 가지입니다.
첫째, 그 도구가 받는 토큰이 읽기 전용인지, 아니면 태그·릴리스·패키지 publish까지 가능한지입니다.
둘째, 외부 기여자의 PR이나 pull_request 계열 이벤트에서도 같은 권한으로 실행되는지입니다.
셋째, self-hosted runner에서 실행된다면 내부 네트워크나 메타데이터 엔드포인트까지 닿는지입니다.
넷째, 스캔 결과나 아티팩트가 사람 검토 없이 자동으로 릴리스 결정에 연결되는지입니다.
다섯째, 해당 스텝이 인터넷 아무 곳으로나 나갈 수 있는지입니다.
이 다섯 가지 중 두세 개만 "예"여도, 스캐너 침해는 품질 문제를 넘어 조직 침해로 이어질 수 있습니다. 이번 공격이 실제로 노린 것도 이런 과도한 연결성이었습니다.
"언젠가 신뢰 도구 하나는 배신한다"를 전제로 CI/CD 다시 짜기
현실적인 대응은 자동화를 버리는 게 아니라, 배신당해도 피해가 제한되게 설계하는 것입니다.
가장 먼저 바꿔야 할 것은 권한의 시간과 범위입니다. 장기 토큰 대신 짧게 살아있는 임시 자격증명을 쓰고, 스캔 스텝마다 별도 권한을 부여해야 합니다. Aqua도 사고 후 장기 토큰에서 전환하겠다고 밝혔습니다.2
둘째, 액션과 도구는 태그가 아니라 검증된 커밋 SHA나 이미지 digest로 고정해야 합니다. 다만 이것도 만능은 아닙니다. SHA 고정은 태그 오염엔 강하지만, 애초에 신뢰한 커밋 자체가 악성이면 막지 못합니다. 그래서 서명 검증, 배포 경로 감시, 이상 네트워크 행위 탐지가 함께 가야 합니다.
셋째, self-hosted runner를 "내부 서버의 다른 이름"처럼 쓰지 말아야 합니다. 메타데이터 서비스 차단, outbound allowlist, 작업 후 완전 초기화가 필요합니다. 이번 악성코드는 EC2/ECS 메타데이터와 쿠버네티스 시크릿까지 뒤졌습니다.1
넷째, 릴리스·태그 생성·패키지 publish 같은 행위는 별도 승인 단계 뒤로 빼는 편이 낫습니다. 속도는 조금 느려지지만, 스캐너 침해가 곧바로 배포 채널 장악으로 이어지는 것을 막을 수 있습니다. 이건 분명한 트레이드오프입니다. 그러나 지금 드러난 위험은 배포 속도보다 훨씬 비쌉니다.
이제 그만 측정해야 할 것들
이번 사건은 "버전 핀ning 했다", "서명된 아티팩트를 쓴다", "보안 스캐너를 넣었다" 같은 체크리스트가 실제 회복탄력성과 다를 수 있음을 보여줍니다.
더 나은 질문은 이런 것입니다.
우리 파이프라인의 각 스텝은 정말 최소 권한인가.
시크릿이 메모리와 환경 변수에 머무는 시간은 얼마나 짧은가.
신뢰 도구 하나가 악성으로 바뀌었을 때, 네트워크·권한·승인 체계가 피해를 국소화할 수 있는가.
그리고 침해 후 몇 시간 안에 어떤 자격증명을 전부 다시 세울 수 있는가.
Checkmarx와 Bitwarden이 표적이 된 이유를 한 문장으로 줄이면 이렇습니다. 공격자는 보안 회사를 "더 안전한 곳"이 아니라, 가장 많은 신뢰와 권한이 응축된 곳으로 본 것입니다.3 그래서 지금 이 사건을 가장 심각하게 봐야 하는 사람은 보안팀만이 아닙니다. GitHub Actions를 운영하는 플랫폼 팀, self-hosted runner를 붙여둔 인프라 팀, 그리고 보안 도구를 파이프라인의 루트 권한처럼 써 온 모든 개발 조직입니다.
참고
1Guidance for detecting, investigating, and defending against the Trivy supply chain compromise
2Update: Ongoing Investigation and Continued Remediation
3Why a recent supply-chain attack singled out security firms Checkmarx and Bitwarden
4Ongoing supply-chain attack 'explicitly targeting' security, dev tools
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.