2026년 3월, 오픈소스 패키지를 통해 내부 환경까지 침투할 수 있는 공급망 공격 사례가 보고되었습니다. 이번 공격에는 Trivy와 axios처럼 널리 사용되는 도구가 포함되었습니다. 해당 사례는 npm과 GitHub 기반 환경 전반에 영향을 줄 수 있는 것으로 보고되었습니다. 또한 의존성 구조를 통해 패키지가 포함되는 경우, 직접 사용하지 않은 라이브러리라도 영향을 받을 가능성이 있는 것으로 설명됩니다. 이번 콘텐츠에서는 해당 사례의 흐름과 함께 점검이 필요한 항목과 대응 방안을 정리합니다. 또한 공급망 공격 대응 방식 중 하나로 Chainguard의 접근 방식을 함께 다룹니다.
▪️어떤 공격이 있었나?
이번 공격은 기존 취약점 공격과 달리 패키지 자체를 변조하는 방식으로 진행되었습니다.
Trivy 사례에서는 계정이 탈취된 이후, 악성 코드가 포함된 버전이 정상 업데이트처럼 배포되었습니다. 기존과 동일한 경로로 설치가 이루어지기 때문에 개발자가 이를 구분하기 어렵습니다. 특히 3월 19일부터 22일 사이 Trivy 스캔을 실행한 환경에서는 해당 과정에서 사용된 인증정보가 외부로 노출되었을 가능성이 있습니다.
axios의 경우에는 특정 버전에 악성 런타임 의존성이 포함되었습니다. 이로 인해 패키지를 설치하는 과정에서 의도하지 않은 코드가 함께 실행될 수 있는 구조가 형성되었습니다. 공격은 단일 패키지에서 끝나지 않았습니다. 동일한 방식으로 LiteLLM, telnyx 등으로 확산되었고, 140개 이상의 npm 패키지로 이어지며 공격 범위가 확대되었습니다. 사용자는 정상적인 업데이트를 수행한 것으로 인식하지만, 실제로는 외부 코드가 내부 환경에서 실행되는 상황이 발생합니다.
▪️영향 범위를 판단하기 어려운 이유
이번 사례에서 영향 범위를 판단하기 어려운 이유는 의존성 구조에 있습니다. 현대 애플리케이션은 여러 개의 라이브러리를 함께 사용하는 구조입니다. 이 과정에서 개발자가 직접 사용하지 않은 패키지도 의존성에 포함될 수 있습니다.
예를 들어, 프로젝트에서 axios를 직접 사용하지 않더라도 다른 라이브러리를 통해 포함될 수 있습니다. 이 경우 개발자는 해당 패키지의 존재를 인지하지 못한 상태에서 취약 코드가 포함된 환경이 운영될 수 있습니다. 또한 이번 공격은 npm, PyPI, GitHub Actions 등 여러 생태계에 걸쳐 동시에 발생했습니다. 이는 특정 도구 문제가 아니라 동일한 방식의 공격이 다양한 환경에서 반복될 수 있음을 의미합니다. Trivy와 같은 도구가 CI/CD 환경에서 사용되는 경우, 공격은 인증정보 유출로 이어질 수 있습니다. 노출된 API 키나 토큰은 이후 다른 시스템 접근에 활용될 수 있습니다.
▪️점검이 필요한 환경
다음 조건에 해당하는 경우 점검이 필요합니다.
✔️ CI/CD 환경에서 Trivy 또는 유사한 도구를 사용한 이력이 있는 경우
✔️ npm 기반 프로젝트를 운영 중인 경우
✔️ axios 또는 관련 의존성이 포함된 경우
✔️ 의존성 구조를 정기적으로 확인하지 않는 경우
특히 CI/CD 환경은 외부 코드 실행이 포함되기 때문에 사용 이력과 실행 시점을 함께 확인하는 것이 중요합니다.
또한 Trivy를 3월 19일부터 22일 사이 실행한 경우에는 패키지 점검과 함께 인증정보 노출 여부까지 확인하는 것이 필요합니다.
▪️대응 방법
이번 사례에서는 단순한 패키지 업데이트만으로 대응이 충분하지 않을 수 있습니다.
먼저 현재 사용 중인 패키지와 버전을 확인해야 합니다. Trivy 실행 여부와 시점, axios 포함 여부를 함께 점검해야 합니다. 이후 CI/CD 환경의 인증정보를 점검해야 합니다. 토큰과 API 키는 재발급 여부를 검토하고, 불필요한 권한은 제거하는 것이 필요합니다.
또한 의존성 구조를 확인해야 합니다.
어떤 라이브러리가 어떤 경로로 포함되어 있는지 파악하지 않으면 실제 영향 범위를 판단하기 어렵습니다.
▪️Chainguard 기반 대응 방식
이번 사례에서는 배포된 패키지 자체가 변조된 것이 핵심입니다. 기존 방식에서는 외부 저장소에서 배포된 패키지를 그대로 사용하는 경우가 많습니다. 이 경우 배포 과정이 침해되면 동일한 문제가 반복될 수 있습니다.
Chainguard는 이러한 구조를 줄이기 위해 외부 배포물을 그대로 사용하는 대신 소스 코드 기반으로 아티팩트를 직접 빌드하는 방식을 사용합니다. 이 과정에서 패키지가 어떤 과정을 거쳐 생성되었는지 확인할 수 있으며, 검증되지 않은 의존성이 포함될 가능성을 줄일 수 있습니다. 또한 외부 배포 경로에 대한 의존도를 낮추기 때문에 유사한 방식의 공급망 공격에 대한 노출을 줄이는데 목적이 있습니다. 이러한 방식은 외부 배포 경로가 침해된 상황에서도 동일한 문제가 반복되는 것을 줄이기 위한 접근입니다.
💡참고: 대응 지원 프로그램💡
현재 Chainguard에서는 다음과 같은 지원 프로그램이 제공되고 있습니다.
▶ 12개월 무료 Trivy 이미지 (http://get.chainguard.dev/trivy-request)
▶ 3개월 무료 Chainguard Libraries 및 Actions → 2026년 5월 31일까지 제공 (http://get.chainguard.dev/libraries-and-actions-signup)
이번 사례는 특정 패키지 하나의 문제가 아니라, 패키지가 유입되는 경로 전체를 점검해야 하는 상황입니다. 특히 의존성 구조를 사용하는 환경에서는 직접 사용 여부와 관계없이 영향을 받을 수 있습니다. 현재 운영 중인 프로젝트에서 패키지 사용 이력과 의존성 구조를 확인하는 것이 필요합니다.
현재 사용 중인 개발 환경에 대해 점검이 필요하신 경우, 플래티어 IDT에서 관련 내용을 함께 검토해 드립니다.
👉 보안 점검 문의하기
