공급망 공격이 다시 한번 소프트웨어 생태계를 뒤흔들었다. 이번 사건의 주인공은 보안 스캐너로 널리 사용되던 Trivy와 이를 신뢰했던 LiteLLM이었다. 도대체 어떤 일이 벌어졌기에, 보안을 지키는 도구가 오히려 공격의 통로가 된 걸까? 그리고 이 사건은 우리가 소프트웨어 개발에서 간과하고 있던 어떤 진실을 드러내고 있을까?
공격의 시작은 Trivy의 Git 태그를 조작하는 것에서부터였다. 공격자들은 2024년 3월 19일, trivy-action 저장소의 태그를 임의로 변경해 악성 버전을 배포했다. 문제는 여기서 그치지 않았다. Trivy를 의존성으로 사용하던 LiteLLM이 이 악성 버전을 자동으로 내려받으면서, 공격은 연쇄적으로 확산되었다. 마치 도미노처럼, 한 번의 작은 조작이 거대한 보안 사고로 이어진 셈이다.
이 사건에서 주목할 점은 공격의 정교함이다. 단순히 패키지를 위조하는 데 그치지 않고, 보안 도구 자체를 악용했다는 점에서 공격자들은 소프트웨어 개발 프로세스의 취약점을 정확히 파악하고 있었다. Trivy는 컨테이너 이미지나 코드베이스의 보안 취약점을 검사하는 도구로, 개발자들이 신뢰하는 대표적인 보안 솔루션 중 하나였다. 그런 도구가 공격의 매개체가 되었다는 사실은, 우리가 얼마나 맹목적으로 도구를 신뢰하고 있었는지를 보여준다.
공급망 공격은 이제 더 이상 새로운 개념이 아니다. 하지만 이번 사건은 그 패턴이 진화하고 있음을 여실히 드러냈다. 과거의 공격이 주로 패키지 저장소를 직접 타깃으로 했다면, 이제는 개발 워크플로우의 핵심 도구를 노리는 방식으로 변모하고 있다. 특히 CI/CD 파이프라인에 통합된 보안 도구를 악용하는 방식은, 공격자가 개발 프로세스의 ‘내부’에서부터 시스템을 장악할 수 있음을 의미한다. 이는 단순한 취약점 악용을 넘어, 개발 문화 자체를 공격 대상으로 삼는 새로운 위협이다.
보안 도구가 보안의 구멍이 될 때, 우리는 무엇을 믿을 수 있을까?
이 사건은 또 다른 중요한 교훈을 남긴다. 바로 ‘신뢰의 전이’ 문제다. 개발자들은 특정 도구가 안전하다고 믿으면, 그 도구를 통해 설치되는 다른 패키지나 의존성까지도 무비판적으로 신뢰하는 경향이 있다. 하지만 이번 사건에서 보듯, 한 번의 타협이 전체 시스템을 위험에 빠뜨릴 수 있다. 이는 마치 은행의 금고를 지키는 경비원이 도둑의 공범이 되는 것과 다를 바 없다.
그렇다면 우리는 어떻게 대응해야 할까? 먼저, 의존성 관리의 중요성을 재확인해야 한다. 단순히 최신 버전을 사용하는 것만으로는 부족하다. 의존성의 출처를 검증하고, 가능한 한 최소한의 권한으로 실행되도록 제한하는 등의 조치가 필요하다. 또한, 보안 도구 자체의 무결성을 확인하는 메커니즘이 필수적이다. 예를 들어, 디지털 서명을 통해 패키지의 진위 여부를 검증하거나, 다중 검증 시스템을 도입하는 등의 방법이 고려될 수 있다.
더 나아가, 이 사건은 소프트웨어 개발 문화의 근본적인 변화를 요구한다. 지금까지 우리는 기능과 속도에만 집중해왔지만, 이제는 보안과 신뢰성을 동등한 우선순위로 올려놓아야 한다. 특히 오픈소스 생태계에서는 더 많은 투명성과 책임 분배가 필요하다. 누구나 기여할 수 있는 오픈소스의 장점은 동시에 그 취약점이 될 수 있음을 잊지 말아야 한다.
공급망 공격은 이제 더 이상 ‘만약’의 문제가 아니다. 언제든 우리 코드에 스며들 수 있는 현실적인 위협이다. Trivy와 LiteLLM의 사례는 우리에게 경각심을 일깨워주지만, 동시에 더 나은 보안 문화를 만들어가는 계기가 되어야 한다. 보이지 않는 손이 우리의 코드를 조작하기 전에, 우리가 먼저 그 손을 잡아야 할 때다.
자세한 내용은 원문에서 확인할 수 있다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
