GitHub에서 스타 수가 많은 유명 패키지를 설치하려다 이름이 비슷한 가짜를 골라 타이포스쿼팅을 당했다면 환경변수나 API 키가 털릴 위험이 크다. 공격자는 설치 스크립트로 시스템 권한을 얻고, 로컬 환경의 .env 파일이나 클라우드 설정을 외부 서버로 곧바로 보낸다.
GitHub 타이포스쿼팅 및 공급망 공격의 기술적 메커니즘
타이포스쿼팅은 패키지 매니저로 라이브러리를 설치할 때 생기는 단순 오타를 노리는 사회 공학 기법이다. 가령 개발자가 npm install requests를 쳐야 할 곳에 npm install requesst라고 잘못 입력하면, 공격자가 미리 심어둔 악성 패키지가 깔린다. 스타나 다운로드 수가 많으면 안전하다고 믿는 개발자가 많지만, 공격자는 정교하게 위조한 저장소로 시각적으로 똑같은 환경을 만들어 사용자를 속인다.
공급망 공격의 본질은 신뢰 사슬을 끊는 데 있다. 개발자가 믿는 오픈소스 생태계 패키지 매니저(npm, PyPI, RubyGems 등)를 공격 경로로 쓰기 때문에 일반 방화벽이나 백신으로는 잡아내기 어렵다. 최신 패키지는 설치할 때 preinstall이나 postinstall 스크립트를 돌릴 수 있는데, 공격자는 이때 리버스 쉘을 만들거나 시스템 민감 정보를 훔치는 코드를 넣는다.
이 공격은 코드 실행으로 끝나지 않고 개발자 로컬 환경의 설정 파일을 샅샅이 뒤진다. .bashrc, .zshrc 같은 쉘 설정 파일뿐만 아니라 프로젝트 루트의 .env 파일에 있는 AWS Access Key, Database Password, Stripe API Key 등을 스캔해 공격자의 C2(Command and Control) 서버로 보낸다. API 키가 한 번 털리면 공격자는 클라우드 인프라에 무단으로 들어와 데이터를 지우거나 비싼 자원을 써서 암호화폐를 채굴하는 등 치명적인 피해를 준다.
가짜 오픈소스 저장소 구별을 위한 3가지 핵심 신호
쓸만한 라이브러리와 타이포스쿼팅된 가짜를 구별하려면 스타 수만 보고 판단해서는 안 된다. 더 정밀하게 들여다봐야 한다. 첫째, 패키지 이름과 공식 문서 URL이 같은지 확인한다. 공격자는 유명 라이브러리 이름을 교묘하게 바꾸고 공식 문서처럼 꾸민 가짜 웹사이트를 만들어 의심 없이 설치하게 만든다. 주소창 도메인 철자가 맞는지, HTTPS 인증서가 제대로 나왔는지 확인하는 과정이 필수다.
둘째, 패키지 업데이트 내역과 커밋 로그의 일관성을 살핀다. 정상적인 유명 오픈소스는 수많은 기여자가 꾸준히 커밋을 남기고 이슈 트래커로 활발히 소통한다. 반면 타이포스쿼팅 패키지는 겉보기엔 스타가 많아도(봇으로 조작), 실제 커밋 로그를 보면 특정 시점에 코드가 한꺼번에 올라오거나 기여자 활동이 거의 없는 경우가 많다. 최근 업데이트 날짜와 버전이 비정상적으로 급격히 올랐다면 의심해야 한다.
셋째, 패키지 안에 든 의존성 라이브러리 구조를 분석해야 한다. 악성 패키지는 기능을 수행한다며 알 수 없는 제3자 라이브러리를 더 설치하거나 외부 네트워크 연결을 강제하는 모듈을 넣는 경향이 있다. package.json이나 requirements.txt를 열어봤을 때 프로젝트 목적과 상관없는 네트워크 모듈이나 난독화된 스크립트가 있다면 설치를 멈추고 보안 분석을 진행해야 한다.
| 구분 | 정상 오픈소스 저장소 | 타이포스쿼팅 가짜 저장소 |
|---|---|---|
| 패키지 명칭 | 공식 문서 및 공식 웹사이트와 정확히 일치 | 철자 하나가 다르거나 유사한 단어로 변형됨 |
| 커밋 이력 | 다수의 기여자가 장기간에 걸쳐 점진적 업데이트 | 단일 계정의 급격한 업데이트 또는 이력 조작 |
| 의존성 구조 | 기능 구현에 필요한 표준 라이브러리 위주 구성 | 불필요한 네트워크 모듈 또는 난독화 코드 포함 |
| 이슈 대응 | 사용자 질문에 대한 메인테이너의 활발한 답변 | 이슈 탭이 비활성화되어 있거나 답변이 없음 |
공급망 공격 발생 시 긴급 대응 및 복구 프로세스
의심스러운 패키지를 설치했거나 API 키 유출이 확인됐다면 패키지를 지운다고 해결되지 않는다. 공격자가 이미 시스템에 백도어를 심어뒀을 가능성이 크기 때문이다. 가장 먼저 해야 할 일은 모든 네트워크 연결을 끊고 유출된 자격 증명을 무효화하는 것이다.
- 자격 증명 즉시 폐기: 유출 가능성이 있는 API Key, Secret Token, Password를 즉시 버리고 재발급받는다. 특히 AWS, GCP, Azure 같은 클라우드 서비스의 IAM 키는 최우선으로 지워야 한다.
- 세션 강제 종료: 유출된 토큰으로 만든 활성 세션을 강제로 끊어 공격자의 접근 권한을 즉시 뺏는다.
- 시스템 전수 조사 및 격리:
ps -ef나netstat -antp명령어로 알 수 없는 외부 IP와 연결된 프로세스가 있는지 보고, 감염된 컨테이너나 VM은 즉시 격리해 포렌식을 진행한다. - 패키지 락 파일 검증:
package-lock.json이나yarn.lock파일을 검토해 의도치 않은 버전이나 낯선 레지스트리 주소에서 다운받은 모듈이 있는지 전수 조사한다. - 환경변수 초기화:
.env파일 및 쉘 설정 파일에 들어간 악성 스크립트나 조작된 경로(PATH) 설정을 지우고 초기화한다.
공급망 공격은 한 번의 실수로 인프라 권한 전체를 넘겨줄 수 있는 위험한 공격이다. 설치 전 패키지 이름을 다시 확인하는 습관과 함께 npm audit이나 Snyk 같은 취약점 스캐닝 도구를 CI/CD 파이프라인에 넣어 자동화된 검증 체계를 만드는 것이 가장 확실한 방어책이다.
결론 및 보안 강화 제언
GitHub 타이포스쿼팅과 공급망 공격은 개발자의 사소한 오타와 신뢰를 이용해 시스템 전체를 마비시킬 수 있는 치명적인 위협이다. 스타 수나 다운로드 횟수 같은 겉보기 지표에만 의존하지 말고, 공식 문서 확인, 커밋 로그 분석, 의존성 검증이라는 삼중 필터링을 거쳐 패키지를 도입해야 한다.
보안은 불편함과 타협하는 게 아니라 필수 프로세스다. 지금 바로 프로젝트 의존성 목록을 점검하고, 유출되면 피해가 큰 API 키는 환경변수 대신 Secret Management Tool(HashiCorp Vault, AWS Secrets Manager 등)로 관리하는 걸 권한다. 한 번의 확인 습관이 기업 전체 인프라를 지키는 가장 강력한 방화벽이 된다.