npm install을 실행하는 건 태만이 아님
문제는 패키지 설치 과정에서 임의 코드 실행을 허용하는 생태계임
하지만 근본적인 보안 실패는, 제3자가 아무 검증 없이 내 제품에 코드를 밀어넣을 수 있는 패키지 매니저를 사용하는 것임
결국 우리는 패키지 관리자와 그 운영자들의 선의와 역량에 무한히 의존하고 있음
또 OP가 자격 증명을 평문으로 파일 시스템에 저장했다고 암시하는 것 같음
두 가지 모두 문제라고 생각함
언어 차원에서 코드가 입력을 읽고, 자원을 소비하고, 타입이 올바른 출력만 생성하도록 제한하는 구조를 만들 수 있음
완전한 공급망 문제 해결은 아니지만, 노출 범위는 훨씬 줄어듦
이런 논리는 너무 순환적임
“한 사람이 이런 도구를 쓰는 건 잘못이 아니지만, 모두가 쓰면 생태계가 문제다”라는 식임
이미 많은 개발 도구가 보안 취약하다는 건 여러 번 증명된 사실임
진짜로 신경 쓴다면, 행동으로 보여야 함
IDE 플러그인도 마찬가지임
VS Code를 쓸 때 작은 기능 하나 추가하려고도 누가 만든지도 모르는 플러그인을 설치해야 해서 불편했음
제3자 코드 실행을 막는 패키지 매니저를 어떻게 설계할 수 있을지 궁금함
결국 신뢰할 수밖에 없는 코드를 실행하게 되는 구조 아닌가 생각함
일부 도구는 http 인증을 위해 netrc 파일만 지원함
git을 http로 쓰면 이런 평문 자격 증명 노출 경로는 거의 항상 존재함
pnpm 메인테이너가 1년 전에 “post-install 스크립트를 기본 차단하자”고 제안했음
사용자 입장에서는 불편하겠지만, 장기적으로는 모두가 감사하게 될 변화라 믿었음
관련 PR: pnpm/pnpm#8897
그런데도 여전히 같은 문제가 반복되고 있음
결국 편의성이 보안을 이긴 또 한 번의 사례임
“데이터베이스는 침해되지 않았다”고 했지만, 공격자가 AWS와 시크릿에 접근했다면 이미 침해된 것이라 봄
접근 가능성이 있었다면 침해로 간주해야 함
AWS 리소스 접근 로그가 있고, 권한 회수 전 접근 흔적이 없다면 데이터는 안전하다고 볼 수 있음
악성코드가 실행된 후에는 출처 추적이 거의 불가능함
pnpm install도 정상적으로 완료되니 탐지하기 어려움
Sentinel One이나 CrowdStrike 같은 EDR이 있었다면 조사 단서가 더 많았을 것임
EDR이 있었다면 Trufflehog 공격 체인을 탐지하거나 차단했을 가능성이 높음
“총 669개의 repo를 클론했다”는 부분이 눈에 띔
직원 수가 100명도 안 되는 회사가 600개 넘는 repo를 가진 게 정상인지 궁금함
완전히 정상임. repo는 가축이지 반려동물이 아님
우리 조직은 7명인데 GitHub에 365개 repo가 있음
팀 규모보다 연차와 프로젝트 수명이 repo 수에 더 큰 영향을 줌
마이크로서비스를 좋아하는 아키텍트가 있으면 이런 결과가 나옴
pnpm은 이미 preinstall 같은 lifecycle 스크립트 자동 실행을 중단했는데, 구버전을 썼던 것 같음 관련 PR 참고
기사 마지막에 최신 메이저 버전으로 업데이트했다고 언급함
그게 pnpm을 쓰는 주된 이유라 생각했는데 혼란스러움
결국 구버전 패키지 매니저로 의존성 업데이트를 한 셈이라면, 이건 그들의 책임임
프로젝트 자체에 postinstall 스크립트가 있었을 수도 있음
pnpm은 의존성의 스크립트는 막지만, 프로젝트 레벨 스크립트는 여전히 실행함
투명한 사후 분석(post-mortem) 공유에 감사함
이런 사례가 업계 전체에 중요함
공격 트래픽이 일반 개발 트래픽과 구분 가능했는지 궁금함
우리도 dev 환경에서 egress 필터링을 강화하려 하지만 npm install이 자주 깨져서 고민임
GitHub 조직의 IP 허용 목록 기능을 쓰면 이런 공격 방어에 도움이 될 듯함
개인 노트북의 git 보안을 고민 중임
현재는 SSH 키를 로컬에 두고 push함
관리자 권한도 있어서 위험함. 더 안전하게 만들 방법이 궁금함
Hacker News 의견들
npm install을 실행하는 건 태만이 아님
문제는 패키지 설치 과정에서 임의 코드 실행을 허용하는 생태계임
하지만 근본적인 보안 실패는, 제3자가 아무 검증 없이 내 제품에 코드를 밀어넣을 수 있는 패키지 매니저를 사용하는 것임
결국 우리는 패키지 관리자와 그 운영자들의 선의와 역량에 무한히 의존하고 있음
또 OP가 자격 증명을 평문으로 파일 시스템에 저장했다고 암시하는 것 같음
언어 차원에서 코드가 입력을 읽고, 자원을 소비하고, 타입이 올바른 출력만 생성하도록 제한하는 구조를 만들 수 있음
완전한 공급망 문제 해결은 아니지만, 노출 범위는 훨씬 줄어듦
“한 사람이 이런 도구를 쓰는 건 잘못이 아니지만, 모두가 쓰면 생태계가 문제다”라는 식임
이미 많은 개발 도구가 보안 취약하다는 건 여러 번 증명된 사실임
진짜로 신경 쓴다면, 행동으로 보여야 함
VS Code를 쓸 때 작은 기능 하나 추가하려고도 누가 만든지도 모르는 플러그인을 설치해야 해서 불편했음
결국 신뢰할 수밖에 없는 코드를 실행하게 되는 구조 아닌가 생각함
git을 http로 쓰면 이런 평문 자격 증명 노출 경로는 거의 항상 존재함
pnpm 메인테이너가 1년 전에 “post-install 스크립트를 기본 차단하자”고 제안했음
사용자 입장에서는 불편하겠지만, 장기적으로는 모두가 감사하게 될 변화라 믿었음
관련 PR: pnpm/pnpm#8897
결국 편의성이 보안을 이긴 또 한 번의 사례임
“데이터베이스는 침해되지 않았다”고 했지만, 공격자가 AWS와 시크릿에 접근했다면 이미 침해된 것이라 봄
접근 가능성이 있었다면 침해로 간주해야 함
악성코드가 실행된 후에는 출처 추적이 거의 불가능함
pnpm install도 정상적으로 완료되니 탐지하기 어려움
Sentinel One이나 CrowdStrike 같은 EDR이 있었다면 조사 단서가 더 많았을 것임
“총 669개의 repo를 클론했다”는 부분이 눈에 띔
직원 수가 100명도 안 되는 회사가 600개 넘는 repo를 가진 게 정상인지 궁금함
팀 규모보다 연차와 프로젝트 수명이 repo 수에 더 큰 영향을 줌
pnpm은 이미 preinstall 같은 lifecycle 스크립트 자동 실행을 중단했는데, 구버전을 썼던 것 같음
관련 PR 참고
pnpm은 의존성의 스크립트는 막지만, 프로젝트 레벨 스크립트는 여전히 실행함
투명한 사후 분석(post-mortem) 공유에 감사함
이런 사례가 업계 전체에 중요함
공격 트래픽이 일반 개발 트래픽과 구분 가능했는지 궁금함
우리도 dev 환경에서 egress 필터링을 강화하려 하지만 npm install이 자주 깨져서 고민임
개인 노트북의 git 보안을 고민 중임
현재는 SSH 키를 로컬에 두고 push함
관리자 권한도 있어서 위험함. 더 안전하게 만들 방법이 궁금함
이렇게 하면 서명 키와 접근 키를 분리할 수 있고, 관리자 계정은 별도로 관리 가능함
관련 문서: 1Password SSH Agent, Git Commit Signing, GitHub OAuth, GitHub CLI Login
키가 외부로 유출될 수 없다는 장점이 있지만, 악성코드가 내 머신에서 동작하면 여전히 위험함
Linux 예시, macOS 예시
TPM이나 Yubikey로 조금 어렵게 만들 수는 있지만, 완전한 방어는 불가능함
관리자 작업은 별도 전용 머신에서 하는 게 안전함
push나 commit 시 PIN 입력으로 잠금 해제함
Torvalds 이름의 커밋은 감염 후 흔히 보이는 표식(signature) 이었음
Microsoft의 공식 분석 글에서도 언급됨
이 웜은 매우 시끄러웠고, 일부 공격자는 노출된 자격 증명으로 비공개 repo를 공개하거나 readme를 수정해 홍보용으로 악용했음
공격자가 파괴 행위 없이 조용히 정보만 유출했다면, 이런 탐지가 가능했을지 의문임