당근·토스가 말한 공급망 보안 해법, 개발자 주의력 말고 ‘진입로 자동 통제’

• 공급망 보안 얘기가 이제 ‘개발자 여러분 조심하세요’ 수준을 완전히 넘어섬
  • 파이썬 공식 저장소(PyPI)에는 하루 900개가 넘는 신규 패키지가 계속 올라옴
  • 최근 1년 사이 파이썬 생태계에서 새로 보고된 멀웨어만 2800개를 넘었음
  • 당근 발표자는 대규모 자동화 도구를 동원한 무차별 유포가 일상화됐고, 개발자 개인의 주의력에 기대는 방식은 한계가 왔다고 봄

• 당근은 사내에 레지스트리 프록시(Registry Proxy)를 두는 방식으로 대응하고 있음

  • 개발자 클라이언트마다 따로 통제하는 대신, 모두가 공통으로 바라보는 패키지 레지스트리를 만들고 거기에 보안 정책을 거는 구조임
  • 특정 패키지가 배포된 뒤 일정 시간이 지나기 전에는 접근을 막는 쿨다운(Cooldown) 정책도 가동 중임
  • 악성 패키지는 생애주기가 짧은 경우가 많아서, 새 패키지를 바로 들여오지 않는 것만으로도 내부 감염 리스크를 줄일 수 있음

• 당근이 짚은 또 다른 현실적인 문제는 버전 관리임

  • 기존 위협의 50~60%는 단순한 버전 락킹 부재에서 비롯된다고 설명함
  • 결국 목표는 개발자가 매번 패키지 하나하나를 의심하지 않아도, 중앙 정책 안에서 안전하게 라이브러리를 쓰게 만드는 것임
  • 이건 보안팀만의 이슈가 아니라 빌드, 배포, 의존성 관리 전체의 운영 방식 문제에 가까움

• 토스 쪽 발표는 MLOps 환경이 다음 공격 타깃이 되고 있다는 얘기였음

  • 일반 소프트웨어 패키지에 대한 공급망 방어는 어느 정도 성숙해졌지만, 공격자는 투자 대비 수익(ROI)이 좋은 약한 지점을 찾음
  • 그 약한 지점으로 모델 파일, 학습 아티팩트, 직렬화 포맷이 오가는 머신러닝 운영(MLOps) 환경이 떠오르고 있다는 진단임

• 특히 Pickle 같은 직렬화 포맷은 구조적으로 위험함

  • Pickle은 역직렬화 과정 자체만으로 임의 코드가 실행될 수 있는 맹점을 갖고 있음
  • 안전한 데이터 전용 포맷을 도입해도 끝이 아님. 커스텀 아키텍처 구동을 위해 함께 들어가는 파이썬 스크립트 실행 권한을 악용하는 변종 공격도 나온다고 함
  • 즉 ‘모델 파일만 받았는데 코드가 실행되는’ 식의 사고가 충분히 현실적인 위협이라는 얘기임

• 토스는 쿠버네티스(Kubernetes) 환경에 자체 아티팩트 방화벽을 올려 대응하고 있음

  • 이 방화벽은 하루 6만건 이상의 패키지를 스캔함
  • 보안 정책이 개발 속도를 막지 않도록 HTTP 캐시 스펙을 활용해, 개발자에게 에러를 터뜨리는 대신 유해 버전만 보이지 않게 숨기는 접근을 구현함
  • 글로벌 플랫폼의 정적 스캐너(SAST)는 우회 가능성이 있어서, 자체 검증을 통과한 청정 모델만 사내 저장소에 적재하는 체계가 필요하다는 입장임

• 당근과 토스 사례의 공통점은 외부 반입 경로를 회사 인프라의 통제 지점으로 본다는 것임

  • 오픈소스 패키지와 머신러닝 아티팩트는 취약점이 터지는 원리는 다르지만, 둘 다 ‘밖에서 들어온 무언가’를 내부 개발 환경이 신뢰하면서 문제가 생김
  • 그래서 전용 프록시와 방화벽을 사내망 진입 지점에 세우고, 정책을 자동화하는 중앙 통제형 아키텍처가 현실적인 대안으로 제시됨
  • 한국 개발팀 입장에서도 바로 참고할 만한 포인트가 있음. 의존성 보안은 교육 자료 하나 배포해서 끝나는 게 아니라, 패키지 레지스트리·빌드 파이프라인·모델 저장소 설계에 박아 넣어야 함

---

기술 맥락

• 당근이 Registry Proxy를 고른 이유는 개발자 PC마다 보안 설정을 맞추는 방식이 규모를 못 버티기 때문이에요. 모두가 지나가는 패키지 관문을 하나 만들면, PyPI에서 들어오는 의존성에 쿨다운이나 차단 정책을 공통으로 적용할 수 있거든요.

• Cooldown Policy는 꽤 단순하지만 효과적인 선택이에요. 새로 올라온 패키지를 바로 허용하지 않으면, 짧게 퍼지고 사라지는 악성 패키지의 타이밍 공격을 피할 가능성이 커져요. 하루 900개 넘게 패키지가 올라오는 환경에서는 사람이 하나씩 보는 것보다 이런 시간 기반 정책이 더 현실적이에요.

• 토스의 아티팩트 방화벽은 MLOps 쪽에서 같은 문제를 푸는 장치예요. 모델 파일이나 학습 아티팩트도 외부에서 들어오는 실행 가능한 물건처럼 봐야 하기 때문에, 쿠버네티스 환경 안에 검사 지점을 두고 하루 6만건 이상을 스캔하는 구조를 만든 거예요.

• Pickle 문제가 까다로운 이유는 파일을 읽는 행위가 사실상 코드 실행으로 이어질 수 있어서예요. 안전한 포맷을 쓰더라도 커스텀 모델 아키텍처 때문에 파이썬 스크립트가 같이 따라오면, 공격자는 그 실행 권한을 이용해 스캐너를 우회할 수 있어요.

• 두 사례 모두 보안 정책을 개발 흐름에 억지로 끼워 넣기보다, 개발자가 원래 쓰는 저장소와 캐시 경로에 통제를 심는 쪽에 가까워요. 그래서 개발 속도를 크게 망치지 않으면서도 외부 반입 경로를 줄이는 게 핵심이에요.