TeamPCP가 보여준 오픈소스 공급망 공격의 새 기준

AI 생성 이미지

TeamPCP는 “악성 패키지를 올리는 공격자” 정도로 이해하면 부족합니다. 이 위협 행위자는 널리 쓰이는 오픈소스 도구와 CI/CD 파이프라인을 이용해 자격 증명을 훔치고, 그 권한으로 다음 공격을 확산시키는 공급망 공격자입니다.

핵심은 코드 한 줄의 취약점보다 더 넓습니다. 개발 조직이 신뢰하는 도구, 자동화된 배포 흐름, 저장소 권한, 패키지 레지스트리 토큰이 모두 공격 표면이 됩니다.

TeamPCP는 무엇을 노렸나

TeamPCP는 Trivy, KICS, LiteLLM 같은 널리 쓰이는 오픈소스 도구를 침해해 자격 증명 탈취형 악성코드를 배포한 것으로 알려졌습니다.¹ 공격 대상은 최종 사용자 PC에 그치지 않습니다. 빌드 서버, 개발자 장비, Kubernetes 환경, 패키지 배포 권한까지 이어집니다.

이 방식이 위험한 이유는 공격자가 “신뢰받는 경로”를 이용하기 때문입니다. 개발팀은 보안 스캐너, GitHub Actions, npm·PyPI 패키지를 자동으로 실행합니다. 원래는 빠른 개발과 배포를 위한 장점이지만, 공격자가 이 흐름에 올라타면 악성코드도 같은 속도로 퍼질 수 있습니다.

GitHub 침해와 관련해 TeamPCP가 BreachForums에서 GitHub 소스코드와 내부 조직 정보를 판매한다고 게시한 점도 같은 맥락에서 볼 수 있습니다. 이들의 관심은 단순한 파일 유출이 아니라, 다음 침투에 쓸 수 있는 권한과 내부 정보입니다.

공격의 중심에는 자격 증명이 있다

Okta는 TeamPCP가 2025년 말부터 고속 소프트웨어 배포 도구와 관행을 악성코드 전달 수단으로 전환했다고 설명합니다.² 특히 CI/CD 환경에서 패키지 레지스트리 토큰, 클라우드 자격 증명, SSH 키, Git 자격 증명, 개인 액세스 토큰을 수집한 것으로 나타났습니다.²

이 권한들은 단순한 비밀번호가 아닙니다. 패키지를 새로 배포하고, 클라우드 리소스에 접근하고, 저장소를 수정하고, 다른 시스템으로 이동할 수 있는 열쇠입니다. TeamPCP가 npm과 PyPI를 포함한 여러 패키지 생태계로 공격을 확산시킬 수 있었던 이유도 탈취한 자격 증명과 연결됩니다.¹

특히 주의해야 할 지점은 GitHub Actions의 pull_request_target 트리거입니다. 이 트리거는 포크에서 온 풀 리퀘스트라도 원본 저장소 컨텍스트에서 워크플로를 실행할 수 있습니다.² 설정이 부적절하면 외부 기여자의 코드가 내부 비밀값에 접근할 수 있는 구조가 됩니다.

TeamPCP는 Kubernetes 환경 내 자격 증명 수집과 횡적 이동 기법을 사용한 것으로도 설명됩니다.¹ 또한 오디오 스테가노그래피 같은 탐지 회피 수단이 보고됐고, TeamPCP와 연계된 자가 전파 웜은 CanisterWorm으로 알려져 있습니다.¹ 일부 작전에서는 민감 데이터 유출 과정에서 AES-256 암호화와 RSA-4096이 사용된 사례도 포함됩니다.¹

방어 기준은 “취약한 패키지 찾기”를 넘어야 한다

TeamPCP 사례가 보여주는 교훈은 분명합니다. 공급망 보안은 더 이상 “이 패키지에 알려진 취약점이 있는가”만 확인하는 문제가 아닙니다. 다음 질문까지 함께 봐야 합니다.

• 누가 배포 권한을 가지고 있는가

• CI/CD 파이프라인이 어떤 비밀값에 접근하는가

• 외부 기여자의 코드가 어느 권한으로 실행되는가

• 새 패키지 버전을 자동으로 받아도 되는가

• 토큰과 키가 탈취됐을 때 어디까지 확산될 수 있는가

실무적으로는 pull_request_target 사용을 신중히 제한하고, GitHub Actions 권한을 최소화해야 합니다. 토큰은 짧은 수명과 좁은 범위로 발급하고, 패키지 배포 권한과 클라우드 권한도 분리해야 합니다. 새 버전을 즉시 반영하지 않는 지연 정책, SBOM, 의존성 감사 역시 공급망 방어의 기본 요소가 됩니다.²

TeamPCP가 보여준 것은 오픈소스 자체가 약하다는 뜻이 아닙니다. 오히려 오픈소스와 자동화가 너무 빠르고 넓게 신뢰되기 때문에, 그 신뢰가 공격 경로가 될 수 있다는 점입니다.

속도를 포기하지 않으려면 신뢰도 자동으로 검증해야 합니다. CI/CD 권한, 비밀값 접근, 패키지 배포 흐름을 지속적으로 점검하는 것이 TeamPCP 이후의 현실적인 방어 기준입니다.

¹TeamPCP (Threat Actor)

²Defending against TeamPCP software supply chain attacks