🧨 오픈소스도 안전지대는 아니다 – ‘로컬 패치 감염’이라는 새로운 위협

최근 오픈소스 생태계를 겨냥한 새로운 유형의 소프트웨어 공급망 공격이 발견되었습니다. 이 공격은 단순히 악성 패키지를 유포하는 수준을 넘어, 사용자의 로컬 환경에 이미 설치되어 있는 정상적인 소프트웨어 파일을 조작하는 방식으로 진행됩니다.

이른바 ‘독성 패치(Poisoned Patch)’ 기법으로 불리는 이 공격은, 패키지를 설치한 시점부터 사용자도 모르게 정상 라이브러리 내부 파일을 교체하여 악성 기능을 삽입합니다. 가장 큰 문제는, 이 악성 패키지를 삭제하더라도 이미 감염된 파일은 원복되지 않는다는 점입니다.

---

🧪 실제 사례: 인기 이더리움 라이브러리를 겨냥한 공격

• 공격자는 ethers-provider2라는 이름의 악성 npm 패키지를 유포했습니다.
• 이 패키지는 설치되자마자 로컬 시스템 내에 존재하는 ethers 라이브러리의 핵심 파일을 찾아, 이를 역방향 셸(reverse shell) 기능이 포함된 악성 코드로 교체합니다.
• 공격자가 원격에서 피해자의 시스템을 제어할 수 있게 되며, 정상 라이브러리를 통한 공격이기에 탐지도 어렵습니다.
• 더 큰 문제는, 사용자가 ethers-provider2를 제거해도 감염된 라이브러리는 그대로 남아 있다는 점입니다.

---

⚠️ 기존 공급망 공격과 무엇이 다른가?

구분기존 패키지 감염독성 패치 방식

감염 위치	패키지 자체	로컬에 이미 설치된 타 소프트웨어
탐지 난이도	비교적 탐지 가능	탐지 어려움
제거 방법	패키지 삭제로 해결	로컬 파일 복구 필요

---

🛡️ 개발자를 위한 보안 권고 사항

1. 의존성 설치 전 검증
   • 최근 업데이트된 패키지라도 반드시 공식성, 다운로드 수, 커뮤니티 피드백 등을 확인해야 합니다.
2. 로컬 파일 무결성 점검
   • 의심스러운 동작이나 이상 트래픽이 감지되면, 주요 라이브러리 파일의 변경 여부를 확인하고 재설치하는 것이 필요합니다.
3. 자동화된 보안 도구 도입 검토
   • 로컬 환경 내 변경 파일을 추적하고 위험 요소를 사전에 탐지하는 기능이 중요해지고 있습니다.
4. 사내 개발 정책 강화
   • 외부 패키지 검증, 내부 레지스트리 운영 등 개발 과정에서의 보안 정책을 재정비할 시점입니다.

---

이제는 ‘패키지를 설치했는가?’보다 **‘설치된 패키지가 무엇을 바꿨는가?’**를 살펴보는 것이 공급망 보안의 핵심이 되었습니다.
단 한 번의 설치로 인해, 전체 프로젝트가 감염될 수 있는 시대. 개발자와 보안 담당자 모두가 경계해야 할 시점입니다.