사용자 데이터 분석을 돕는 오픈소스 CLI 패키지 element-data가 공급망 공격에 휘말려 사용자 자격증명이 탈취된 정황이 나왔다. Ars Technica에 따르면, 위협 행위자는 개발자 계정의 서명 키와 민감 정보에 접근할 수 있게 해주는 취약점을 악용해 악성 버전(0.23.3)을 배포했으며, 이 패키지는 파이썬 패키지 인덱스(Python Package Index)와 Docker 이미지 계정에 게시되었다. 문제의 버전은 약 12시간 후 삭제됐지만, 개발팀은 0.23.3을 설치했거나 해당 Docker 이미지를 실행한 사용자는 “이미 노출되었을 수 있다”고 경고했다.
공격 경로: 개발자 워크플로 취약점으로 서명 키 확보
이번 사건의 핵심은 단순히 패키지 하나가 변조된 수준을 넘어, 패키지 서명 키 등 배포에 직접 연결되는 민감 정보에 공격자가 접근했다는 점이다. Ars Technica 보도에 따르면, 공격자는 element-data 개발팀이 운영하던 GitHub Actions(깃허브 자동화 워크플로) 내 취약점을 악용해 개발자 계정에 침투했다. 특히 공격자는 악성 코드를 포함한 풀리퀘스트(PR)를 올리는 방식으로, 개발자 계정 내부에서 실행될 수 있는 배시 스크립트를 트리거해 민감 데이터를 수집했다.
수집된 정보에는 사용자 프로필, 데이터웨어하우스(warehouse) 자격증명, 클라우드 공급자 키, API 토큰, SSH 키 등이 포함됐다고 개발팀은 밝혔다. 이후 공격자는 계정 토큰과 서명 키를 활용해, 정식 패키지와 거의 구분되지 않는 악성 element-data 버전을 게시할 수 있었다. 이 구조는 오픈소스 저장소에서 “빌드·배포 자동화”가 널리 쓰이는 현실을 감안할 때, 단일 의존성 위협을 넘어 더 큰 연쇄 위험을 보여준다.
악성 버전의 범위: 0.23.3 및 특정 Docker 이미지 영향
Ars Technica에 따르면, 악성 패키지는 버전 태그 기준으로 0.23.3이었고, 개발자 계정의 PyPI 및 Docker 이미지 채널에 올라갔다. 해당 버전이 “실제로 설치된 환경을 훑어” 민감 데이터를 찾아내는 방식으로 동작했으며, 문제의 패키지는 약 12시간 뒤인 토요일 삭제됐다.
다만 개발팀은 Elementary Cloud와 Elementary dbt 패키지를 비롯한 다른 CLI 버전은 영향을 받지 않았다고 밝혔다. 그럼에도 불구하고, 악성 패키지가 실행된 환경에서 접근 가능한 모든 자격증명이 노출될 수 있으므로 사용자는 스스로 침해 여부를 점검해야 한다는 입장이다.
개발팀의 대응과 사용자 지침: 설치 확인, 파일·캐시 점검, 자격증명 교체
개발팀은 악성 코드 유포 사실을 제3자 이슈 리포트로 인지했으며, 그로부터 약 3시간 안에 패키지를 제거했다고 전했다. 또한 악성 코드가 접근했을 가능성이 있는 자격증명은 모두 순환(로테이션)했고, GitHub Actions의 취약 지점을 수정한 뒤 다른 워크플로 전반에 대한 감사(audit)도 진행하고 있다고 밝혔다.
사용자에게는 즉각적인 조치가 권고됐다. Ars Technica가 전한 개발팀의 체크리스트는 다음과 같다. 먼저 pip show elementary-data | grep Version으로 로컬 설치 버전을 확인해, 만약 0.23.3이라면 삭제 후 안전 버전인 0.23.4로 교체해야 한다. 이어 요구사항 파일(requirements)과 잠금 파일(lockfiles)에서 elementary-data==0.23.4처럼 버전을 명시해 고정하는 것이 권장된다.
또한 캐시 파일을 삭제해 악성 잔여물을 줄이고, 패키지가 남길 수 있는 마커 파일 존재 여부도 점검하라고 했다. 운영체제별 경로는 macOS/리눅스의 /tmp/.trinny-security-update, 윈도우의 %TEMP%\\.trinny-security-update로 제시됐다. 더 중요한 부분은 자격증명 교체다. 개발팀은 dbt 프로필, 데이터웨어하우스 자격증명, 클라우드 키, API 토큰, SSH 키, 그리고 .env 파일에 포함된 내용 등 “악성 패키지가 실행된 환경에서 접근 가능한 것”을 전부 로테이션해야 한다고 강조했다. 특히 CI/CD 러너는 실행 시점에 다양한 시크릿이 마운트되는 경우가 많아 노출 위험이 더 높다고 덧붙였다.
오픈소스 공급망 공격이 반복되는 이유…“자동화 워크플로가 취약점이 되기 쉽다”
이번 사건은 최근 10여 년간 오픈소스 저장소를 겨냥한 공급망 공격이 늘어나는 흐름과 닿아 있다. 악성 패키지가 사용자 환경으로 침투한 뒤, 그 결과로 기업 내부 자격증명이나 후속 시스템까지 연쇄적으로 타격하는 전형적인 구조가 반복되고 있다는 지적이 나온다.
Ars Technica는 보안 분야에서 오래 활동한 HD Moore(런제로(runZero) CEO)의 언급도 전했다. Moore는 “공개 저장소를 가진 오픈소스 프로젝트는 사용자 제작 워크플로(예: GitHub Actions)에 취약점이 숨어 있을 가능성이 크다”는 취지로 설명하며, 이를 완전히 배제하기가 어렵다고 말했다. 이번 사건 역시 바로 그 지점—자동화 워크플로가 배포·서명으로 이어지는 연결고리—가 공격자에게 활용될 수 있음을 보여준다.
무엇을 더 지켜봐야 하나
당장 필요한 것은 element-data 0.23.3 설치 여부 및 해당 Docker 이미지 실행 이력 점검이다. 기업과 개발자 팀은 “이미 로테이션했는지”를 단순히 확인하는 데 그치지 않고, 자격증명 사용 흔적이나 비정상 접근 로그까지 함께 조회해야 한다. 개발팀은 관련 지표(IOCs)를 추가로 제공하고 있으며, 사용자들은 보안팀과 협업해 잠재적 무단 사용 여부를 탐색해야 한다고 권고했다.
또한 오픈소스 유지보수자 입장에서는 GitHub Actions를 포함한 배포 파이프라인 전체에 대한 보안 점검이 핵심 과제로 부상할 전망이다. 특히 서명 키 접근, 토큰 권한 범위, 취약한 자동화 단계의 존재 여부가 다음 공격의 출발점이 될 수 있기 때문이다. 향후 추가 보고나 보안 공지에서 “유사 취약점이 다른 저장소/패키지에도 있었는지”가 드러날지 주목된다.
댓글