당근, 파이썬 공급망 공격에 쿨다운 정책 도입!
LiteLLM 공급망 공격(Supply Chain Attack) 발생으로 파이썬 패키지 보안의 중요성이 대두됨에 따라, 당근은 사내 PyPI 프록시(PyPI Proxy)에 쿨다운 정책 도입
쿨다운 정책은 패키지 업로드 후 일정 기간 설치를 지연시켜 악성 패키지(Malicious Package) 유입을 차단하는 방식
PEP 503(HTML 기반)과 PEP 691(JSON 기반) API를 함께 활용하여 쿨다운 기간 내 업로드된 패키지를 필터링
CentralDogma를 통해 쿨다운 정책을 동적으로 관리하며, 예외 처리(Exception Handling)를 위한 exclude 목록 지원
PyTorch Lightning 공격 사례를 통해 쿨다운 정책의 실효성을 확인하고, 오픈소스 생태계(Open Source Ecosystem) 보안 강화의 중요성을 강조
공급망 공격(Supply Chain Attack)의 이해
본문에서 언급된 LiteLLM 공급망 공격은 악성 코드(Malicious Code)가 삽입된 패키지가 PyPI에 배포되면서 발생했다. 공격자는 Trivy 크리덴셜 탈취(Credential Theft)를 통해 공식 CI/CD 파이프라인을 우회하여 악성 패키지를 업로드했다. 해당 패키지는 환경 변수, SSH 키, 클라우드 크리덴셜 탈취를 시도했다. 이처럼 공급망 공격은 오픈소스 생태계(Open Source Ecosystem)를 악용하여 광범위한 피해를 유발할 수 있다.
쿨다운 정책(Cooldown Policy)의 기술적 구현
당근은 쿨다운 정책 구현을 위해 사내 PyPI 프록시를 활용했다. PEP 503(HTML 기반) API를 통해 패키지 목록을 요청받고, PEP 691(JSON 기반) API를 통해 각 파일의 업로드 시간을 확인하여 쿨다운 기간 내 업로드된 파일을 필터링한다. 프록시는 CodeArtifact용 인증 헤더를 추가하여 요청을 전달하고, AWS 토큰 갱신(Token Renewal)을 백그라운드 데몬 스레드로 처리한다. 이러한 구조를 통해 사용자는 별도의 설정 없이 쿨다운 정책의 혜택을 누릴 수 있다.
PEP 503과 PEP 691의 상호 작용
쿨다운 정책 구현 과정에서 PEP 503과 PEP 691의 차이점이 핵심적인 문제로 부각되었다. PEP 503은 HTML 기반으로, 패키지 업로드 시간을 제공하지 않아 쿨다운 적용이 어려웠다. 반면, PEP 691은 JSON 형식으로, 각 파일의 업로드 시간을 포함하여 쿨다운 기준을 정확하게 계산할 수 있게 해준다. 당근은 두 가지 스펙을 함께 활용(Hybrid Approach)하여, 클라이언트에는 PEP 503 HTML 응답을 제공하고, 쿨다운 필터링은 PEP 691 JSON API를 통해 수행하는 방식을 채택했다.
CentralDogma를 활용한 동적 제어
당근은 쿨다운 정책을 CentralDogma를 통해 동적으로 관리한다. 이를 통해 서버 재배포 없이 쿨다운 활성화/비활성화, 적용 일수 조정, 특정 패키지 예외 처리가 가능하다. 특히, exclude 목록(Exclude List)을 통해 사내 라이브러리나 신뢰도 높은 패키지는 쿨다운 적용에서 제외하여, 긴급 업데이트의 지연을 방지한다. 이러한 유연성은 쿨다운 정책의 실용성을 높이고, 운영 효율성을 향상시킨다.
쿨다운 정책의 한계와 추가적인 보안 조치
쿨다운 정책은 공급망 공격에 대한 중요한 방어 레이어이지만, 몇 가지 한계가 존재한다. 보안 패치 지연(Security Patch Delay) 가능성이 있으며, 쿨다운 이전에 업로드된 악성 패키지는 차단할 수 없다. 따라서, 당근은 쿨다운 정책과 더불어 의존성 감사 도구(Dependency Audit Tool)를 병행하여, 잠재적인 위협에 대한 다각적인 방어 체계를 구축한다. 쿨다운 정책은 '무엇을 설치할지'와 더불어 '언제 설치할지'를 고민하는 중요한 첫걸음이다.
