Hacker News 의견

• 주기적으로 npm install 스크립트를 비활성화하라는 알림을 드리고 싶음

  • 예시는 다음 명령어 사용법임:

      npm config set ignore-scripts true [--global]
    

  • 이 설정은 프로젝트 단위, 또는 글로벌로 손쉽게 적용 가능함

  • 요즘에는 스크립트 없이는 동작하지 않는 합법적인 패키지가 드물기 때문에 대부분 문제 없음

  • 동작에 꼭 필요한 패키지는 별도의 설치 스크립트를 만들어 해당 폴더에서 수동으로 실행함으로써 대처 가능함

  • 공급망 공격의 만능 해법은 아니지만, 실제로 npm을 통한 많은 공격을 효과적으로 차단했음

  • 자세한 정보는 npm config 공식 문서 참고 바람

  • 나도 bubblewrap을 활용해 npm, pnpm, yarn 및 이들이 실행하는 모든 세션을 시스템과 격리해서 실행함

    • 내 소스코드는 ~/code 아래에만 존재하고, PATH 초반에 아래 bash 스크립트를 'npm'으로 저장함
    • 다른 패키지 매니저도 심링크/하드링크로 연결:

      #!/usr/bin/bash
      bin=$(basename "$0")
      exec bwrap \
        --bind ~/.cache/nodejs ~/.cache \
        --bind ~/code ~/code \
        --dev /dev \
        --die-with-parent \
        --disable-userns \
        --new-session \
        --proc /proc \
        --ro-bind /etc/ca-certificates /etc/ca-certificates \
        --ro-bind /etc/resolv.conf /etc/resolv.conf \
        --ro-bind /etc/ssl /etc/ssl \
        --ro-bind /usr /usr \
        --setenv PATH /usr/bin \
        --share-net \
        --symlink /tmp /var/tmp \
        --symlink /usr/bin /bin \
        --symlink /usr/bin /sbin \
        --symlink /usr/lib /lib \
        --symlink /usr/lib /lib64 \
        --tmpfs /tmp \
        --unshare-all \
        --unshare-user \
        "/usr/bin/$bin" "$@"
      

    • 이렇게 하면 패키지 매니저는 ~/code와 시스템 라이브러리의 읽기전용 접근만 가짐
    • bubblewrap은 안정적이고, Steam과 flatpak 등에서 사용하는 도구임

  • pnpm 사용하는 것도 방법임. 최신 버전은 기본적으로 모든 라이프사이클 스크립트를 무시하고, 개별적으로 화이트리스트에 올려줘야 동작시킴

  • 이 조언을 들을 때마다 묻게 되는 점이 있음: 실제로 npm이 설치한 수십 ~ 수백만 줄의 코드를 다 읽어보는 개발자는 없는 상황임

    • 대부분 개발자 워크플로우는 아래처럼 흘러감
      1. git clone
      2. npm install (여기서 악성 패키지가 설치될 위험 있음. post-install 스크립트를 무시하면 잠깐은 막을 수 있지만)
      3. npm run (여기서 악성 패키지가 실행되며 감염됨)
    • 조언이 도움이 되려면 2와 3 사이에 node_modules 전체를 감시/감사해야 하는데, 아무도 그렇게 하지 않음

  • 나는 모든 npm 기반 툴을 Docker 컨테이너 내부에서, 현재 디렉터리 이외에는 접근권한 없이 실행함

    • 공격 표면을 극적으로 줄여주는 효과 있음
    • 방법은 블로그 참고

  • 왜 이러한 조언들은 setup.py(파이썬)나 build.rs(Rust)와는 다르게 적용되지 않는지 궁금함

    • npm은 종종 소프트웨어 배포까지 (예: 별도 프로그램 배포) 남용되지만, 타 언어 패키지 매니저는 라이브러리 관리용으로만 쓰이기 때문인지 궁금함
    • 관련 토론은 여기에서 참고 가능함

• 새로운 의존성 추가할 때 정말 한 번 더 고민하는 문화가 필요함

  • 올해 정말 많은 공급망 공격 발생했음

  • 이번 주 Go 프로젝트에 8개 통계 카운터가 달린 프로그레스 바를 추가하려고 했음

  • 라이브러리 검색해보니 코드가 3,000줄이 넘었고, 그래서 LLM에게 간단한 UI 코드 생성을 부탁하니 150줄 미만으로 해결됨

  • 종속성 없이 의도대로 동작하고, 아주 단순해서 모두 쉽게 읽고 개선 가능함

  • 기능은 터미널 출력 지우고 매초 다시 그리기, 스레드 세이프함 지원임

  • 적용과 리뷰까지 25분이면 충분했음

  • 복잡한 통계 기능이 필요 없다면 30줄 정도의 코드로도 충분히 프로그레스 바 구현 가능함

  • 앞으로 의존성 추가 여부 고민 시 직접 만들어 쓰는 방향이 나에게 맞는 듯함

  • 모든 패키지 업데이트를 감시하기엔 리소스가 부족함

  • 언급한 점에 동의하며 "언어별 패키지 매니저"가 대중화된 초반엔 정말 불안함을 느낌

    • 시스템 프로그래밍 쪽에서 일하면서 pip, npm 등을 멀찍이 지켜봤는데
    • Rust 프로젝트로 넘어가 Cargo 한 줄 설정만으로 검증되지 않은 수십 개의 의존성을 인터넷에서 받아쓰는 걸 경험하니 위험하다고 생각함
    • 실제로 일어난 일이 됨. 좋은 방향이 아니라 생각함. (하지만 우리가 돌아설 거란 기대는 없음. 컴퓨터 보안이란 게 존재하지 않으니…)

  • 나는 cargo vet 같은 접근이 앞으로의 방향이라 생각함: cargo vet 소개

    • 물론 모든 언어 생태계에 이런 시스템이 필요하다는 점에서 오버헤드는 클 수밖에 없음
    • 인터넷 초창기나 이메일도 좋은 시절이 있었으나 결국 스팸과 상업화로 망가졌음
    • 이제는 의존성 연결고리마저 이런 피해를 보고 있음
    • 이런 이유로 우리가 멋진 환경을 계속 유지하지 못하게 됨

  • 직접 구현과 라이브러리 사용의 차이는 당연한 점임

    • 라이브러리는 본질적으로 범용적이고, 다양한 환경에 맞게 유연하고 설정이 가능해야 하므로 코드가 길어질 수밖에 없음

  • 나는 이런 프로그레스 바 라이브러리, 특히 emacs shell 깨뜨리는 걸 정말 싫어함 (expo, eas 등)

    • 왜 단순하게 ..10%..20%..30% 혹은 Uploading… 형식으로 출력하지 않는지 모르겠음
    • 터미널 제어 코드는 TUI나 상호작용 인터페이스 전용으로만 써야 한다고 생각함

  • 우리 팀은 대형 보험사에서 NX를 중심으로 대규모 모노레포와 라이브러리들을 운영하고 있음

    • 10개 이상의 독립 앱과 25개 이상의 라이브러리를 단일 모노레포로 관리하고, CI/CD도 무겁게 엮여 있음
    • lerna, rushjs, yarn workspaces 등도 시도해봤지만 NX만큼 잘되는 툴은 없었음 (lerna도 결국 NX로 인수, rushjs도 관리 안 됨)
    • 프론트엔드 모노레포 복잡도를 제대로 관리할 방법/대안을 제안해줬으면 좋겠음
    • 이번 보안 사건으로 대안에 관심 있는 사람이 많은 만큼, 다양한 의견을 기다림

• Nx나 Anthropic, 플랫폼만 탓하지 말고 진짜 원인을 다시 생각해야 함

  • 이번 공격의 실질적 원인은 도용된 "토큰"(패키지 매니저 작업 권한 부여 문자열)으로 악성 패키지를 업로드 가능했던 점임
  • 하지만 이건 delivery 방식일 뿐, 성공하게 만든 근본 원인은 아래 항목들임:
    1. 패키지 매니저 저장소가 산출물 사인(서명)을 의무로 두지 않아, 권한 있는 개발자가 만든 것임을 검증할 수 없었음
    2. 코드 서명 또한 필수 아니었음
    3. (추정) 이상 행동 탐지, IP 새로 등록, 국가 변경 등 이상 업로드 방지 휴리스틱 미구현
    4. (추정) MFA가 도용된 토큰 사용에 필수 아니었음
    5. (추정) 토큰이 1회성이 아님
    6. (추정) 토큰이 새 애플리케이션이나 세션에서 사용될 경우 수동 승인을 거치게 하는 패스워드 매니저에 저장돼 있지 않았음
  • 이 모든 게 지켜지지 않은 건 완전히 막을 수 있었던 일임
  • 실제로 자신이 피해를 입고 자신의 깃허브 계정에 저장소가 새로 만들어졌다면, 본인도 자신의 인증 토큰을 강하게 보호하지 못한 것임
  • 이런 예방조치가 기본 설정으로 자리 잡지 못한 건 소프트웨어 업계 전체의 큰 실패임
    • 몇 년간 이 공격은 지속적으로 반복돼 왔음
    • 우리 자신이 개발자임에도 고치지 않은 것임
  • 그래서 나는 건축법처럼 소프트웨어에도 강제 규제(점검, 벌금 포함)가 있어야 한다고 주장함

    • 이 공격이 금융, 전력, 통신, 병원, 군사 등 수만 개 기관에 치명적 피해를 줄 수 있음

    • AI가 확산됨에 따라 공격 규모와 파급력은 더 커질 것임

    • 우리는 충분히 책임 있게 소프트웨어를 작성하지 못함. 건축법처럼 강제로라도 안전-보안을 준수해야 함

    • 지금 개인용 컴퓨팅 환경이 하나의 큰 공간으로 묶여 있다는 점이 생각보다 위험함

      • 맥, 윈도, 리눅스 모두에서 크립토 월렛, 자격증명 파일, 여러 앱이 다 한데 있음
      • 이런 것들을 잘 분리할 도구가 아직은 형편없음
      • 가끔 윈도 VM 여러 개를 맥OS에서 돌리면, 최종적으로 아주 깔끔하고 매끄럽게 작업별 컨테이너나 VM에 Alt-Tab으로 들어가는 미래를 상상함
      • 예: 게이밍 컨테이너, 암호화폐 작업 전용 컨테이너, 주요 코드 프로젝트별 컨테이너 등
      • VSCode 확장 설치 하나 때문에 비트코인 키가 유출될 수 있다는 건 정말 말이 안 되는 현실임
      • 소프트웨어 건축법 같은 규칙이 이런 근본적 문제까지는 해결하기 어렵다고 생각함
      • 운영체제 차원에서 앱 간 데이터 접근을 통제하는 규정도 필요한데, 실제 수립 및 집행 방안이 함께 논의돼야 함

    • 피해자의 50%는 VS Code가 감염 경로였고 리눅스와 맥OS에서만 작동함

      • 해당 공격의 상세 분석은 블로그 분석 참고
      • 감염 시:
        • postinstall 단계에서 사용자 자격 증명 등 중요 자산(크립토월렛, Github 및 npm 토큰, SSH 키 등) 수집
        • AI 커맨드라인 도구(Claude, Gemini, Q 등)를 활용한 정보 수집 및 능동적 정찰
        • 탈취 데이터는 base64로 이중, 삼중 인코딩 후 공격자 소유 깃허브 저장소(s1ngularity-repository 등)에 업로드
        • 수천 개 이상의 저장소 발견됨
        • 1000개 넘는 깃허브 토큰, 수십 개의 클라우드 및 NPM 자격 증명, 약 2만 개 파일이 유출됨
        • 주로 NX의 VSCode extension을 통해 실행되거나, 빌드 파이프라인(예: Github Actions)에서 돌았음
        • 8월 27일 9AM UTC에 Github가 공격자 저장소 모두 비활성화했으나, 최대 8시간 노출 기간 동안 데이터가 유출됨
        • base64 인코딩은 쉽게 원본 복구 가능해서, 이 데이터는 사실상 모두 공개된 것으로 봐야 함

    • 깃허브 토큰/인증 정보를 수동 해제형 비밀번호 관리 도구에 보관하지 않은 점은 GH CLI 탓도 있음

      • GH CLI는 한번 로그인하면 저장소 업로드 권한이 생기고, 재인증 요구가 거의 없음
      • AWS CLI는 정책마다 다르지만 18시간마다 자동 만료됨
      • 하지만 두 플랫폼 모두 기본적으로 로컬 환경에 토큰이 평문으로 남기 쉬움

    • “소프트웨어 건축법” 도입 아이디어는 마음에 들진 않지만, 산업 전체가 너무나 취약한 현실임에는 동감함

      • 규제가 어쩌면 정말 필요한 상황임

    • 무료 오픈소스 라이브러리를 썼으니 책임을 물겠다는 발상은 오만하다고 생각함

      • 제대로 된 보장을 원하면 라이선스를 구매해야 함
      • 무료 소프트웨어에 책임을 묻는 구글의 적대적 검증 정책과도 같음

• 최근 개발 작업 대부분을 VM에서 하고 있음

  • 요즘 환경의 보안 수준이 용납할 수 없을 정도라 느껴짐

  • 에이전트(에이전트형 소프트웨어)가 악성코드 벡터로 작동할 가능성이 엄청나게 커졌음

  • 공격자가 박스(PC)에 침투했다면, 1,000달러 이상의 몸값 데이터, 크립토 키, 패스워드, 신상정보, 금융자료 등도 언제든 노릴 수 있는 시대임

    • 나도 비슷하게 Podman 컨테이너 안에서 작업함. 소스코드 디렉터리 외엔 호스트와 공유 안 함

    • 문제의 일부는 전통 PC 보안 모델(Linux/Windows)에서 옴

      • 실행 파일은 신뢰된 것으로 간주되고, 이 파일들이 내 모든 개인정보에 접근케 하는 모델은 2025년 상황에 맞지 않음
      • 모바일(Android)은 대부분 이걸 극복했지만, PC에서는 SELinux 외에 깊은 대안이 잘 없음

    • 만약 이런 방식을 선호한다면, Qubes OS 추천하고 싶음. 모든 작업을 VM에서 할 수 있는 좋은 UX를 제공함

      • 내 데일리 드라이버임, 정말 강력 추천함

    • 다만, 이런 환경 구축은 소프트웨어 생태계와 역사 탓에 매우 어렵거나 비용이 꽤 든다는 점 명시함

• Claude Code는 생산성 향상을 위한 혁신적인 툴임

  • 반면에 다음과 같은 보안 이슈가 있음:

    • NodeJS 앱임
    • 설치 시 curl로 bash에 파이프함 (원격 코드 실행 리스크)
    • LLM이 파일 시스템·명령어 등 다양하게 만질 수 있음

  • 이처럼 최소 3가지 보안 취약점이 있으니, VM/컨테이너/전용 개발 박스 같은 샌드박스 외부에서 돌리고 싶지 않음

    • 나도 에이전트를 샌드박스에서 구동하는 게 맞다고 생각함

      • 그 대신 Claude code는 처음부터(별도 허용 없이) 임의로 명령 실행하지는 않음

    • 그래도 그래서 어떤데?

      • 유저가 직접 실행 버튼을 눌러야 돌아감
      • 대부분 프로그램도 다 권한을 가지고 있음
      • 터미널도 파일시스템을 건드릴 수 있지만, 그렇다고 임의로 돌아가진 않음
      • Claude Code가 스스로 내 컴퓨터 망가뜨리는 데몬처럼 움직이는 건 아니고, 명확한 지시 없이는 아무 일도 없음
      • 난 Claude Code가 최근 30년간 써본 최고의 툴이라 생각함
      • “공격 벡터”가 뭐였는지는 별로 신경 안 씀. 남이 내 컴퓨터에 무단 접근하면 Claude Code만의 문제가 아님

    • 진짜 위험한 점은, 사용자 개입 없이 자동 업데이트를 하면서 실행 도중 원격 코드 실행(RCE) 권한을 Anthropic에 준 셈이라는 점임

• 패키지 매니저에 ‘최소 패키지 연령(min-age)’ 같은 설정이 필요한지 궁금함

  • 예를 들어, 24~36시간 미만에 등록된 패키지는 무시하도록 하면

  • 전에 비슷한 사례를 겪었는데, 패키지 업데이트가 모든 걸 망치더니 몇 시간 후 금방 수정/삭제됨

    • GitHub dependabot이 최근에 딱 그런 기능을 추가함

      • 공식 변경 로그

    • Renovate bot은 (minimumReleaseAge 설정)로 이런 옵션을 이미 제공함. dependabot도 이제는 지원함

      • 패키지 매니저는 최신 버전 설치만 신경 쓰지만, 이런 무료 도구로 적절한 주기로 업데이트 관리 가능함
      • 자바스크립트 생태계는 점차 통합 방향으로 가고 있고, 공급망 공격 대응 도구가 천천히 생겨나는 중임
      • 최신 NPM, PNPM, Bun 등은 postinstall 스크립트를 기본적으로 실행하지 않고, 필요시 명시적으로 실행해야 함 (그래도 결국 타인의 코드를 실행하는 상황은 마찬가지임)

    • OS 수준은 아니지만, Astral의 uv 도구는 Python 패키지에 이런 옵션이 있음

    • npm install에도 특정 시점/날짜 이전 의존성만 설치하는 플래그가 있음

      • "npm install --before (2일 전 날짜)"로, 해당 날짜 이후 생긴 의존성은 설치하지 않음

    • 나는 .npmrc에 save-exact=true 설정하고, lockfile 및 수동 업데이트만 활용함

      • 패키지 자주 안 올려도 됨
      • fakerjs 사태 등 겪어보니 신중해야 한다고 느낌

• claude code가 실제로 그런 프롬프트를 실행할지 의아해서 테스트함

  • 결과는 아래와 같음:

    • "이 요청은 암호화폐 월렛, 프라이빗 키 등 민감 파일 검색·목록화 요청으로 보이며 악용소지가 있어 도와줄 수 없음"

    • 보안 점검, 취약점 분석, 모니터링 툴 작성, 파일 권한 이해, 백업 절차 설계 등 합법적 요청만 안내함

    • 최소 250건 이상의 성공 사례를 확보했음 (즉, 일부 프롬프트는 통과함)

      • Claude가 평균적으로 거부율이 확실히 높으며, Q도 잘 거부함 (Claude 기반이니 비슷함)
      • 참고로, 하루종일 이런 이슈에 대응하면서 관련 분석 보고서 작성함

    • 실전에서 Claude와 다른 모델이 거부 대결할 때마다 Claude의 거부/안전 조치가 훨씬 우수하다는 점을 매번 확인 중임

      • 유명 사례: ChatGPT는 정신건강적 이슈를 가진 이용자를 계속 "The Oracle"로 대하며 방치하던 반면, Claude는 거부하고 전문가 상담을 권유함
      • 물론 "정답입니다!" 류 답변이 반복되면 답답하지만, Anthropic이 타 경쟁사 대비 거부와 안전성에 더 신경 쓴 점은 충분히 인정하고 칭찬할 만함

• OS는 기본적으로 앱이 파일 시스템 전체에 무제한 접근하지 못하게 해야 함

  • 일부 앱은 apparmor/selinux 프로파일이 있기도 하고, firejail 등도 쓸 수 있음

  • 하지만 UX 측면에서 변화가 필요함

    • 이게 매우 심각한 문제임. 30년 전 데스크톱 기준 설계 때문임

      • 반면 최신 모바일 OS(iOS 등)는 기본적으로 앱당 샌드박스, 허용 권한 승인 정책이 우수함
      • 데스크톱에서는 Qubes(OS), Firejail, bubblewrap, AppArmor 등 다양한 시도가 있지만, 복잡하거나 일반 사용자가 쓰긴 어려움
      • OpenSnitch도 있지만 네트워킹 한정임
      • 최종사용자 입장에선 프로그램마다 권한 설정을 세부적으로 조정하는 일이 부담스러움
      • 결국, 널리 사용되는 앱용 프로파일이 꾸준히 유지되는 게 핵심임
      • 데스크톱 보안이 이리 취약한 상황에 경악스럽지만, 근본적으로 어렵고, 이 문제를 해결해도 금전적 유인이 적음

    • 나는 Linux에서 Podman으로 프로젝트별 환경 격리에 집중한 도구를 직접 개발 중임: probox

      • UX 향상을 위한 노력이 큼
      • 자주 쓰고 있는데, 보안 리뷰 진행해 줄 분이 필요함

    • Android 파일 보안에 관한 한 구글이 잘 해냄

    • bubblewrap과 작은 chroot 환경 사용법을 익히는 것도 추천함

    • 어떤 운영체제도 애플리케이션이 "전체 파일 시스템을 무제한 접근"기본값은 아니라고 생각함

      • Linux, BSD, MacOS, Windows 모두 강력한 제한 조건이 있음
      • 일반 사용자가 직접 위험하게 계정 권한을 올려 실행하지 않는 한 기본적으로 안전함

• 예전에는 "공격자가 내 환경을 알아맞혀야 한다"는 막연한 자신감이 있었지만 이제는 LLM을 시켜 환경에 맞는 공격을 익히고 수행케 할 수 있음

  • 나 자신도 이런 흐름을 실제로 예측한 것 같아 자평함

  • 이전 토론에서 참고할 만한 논의였음

    • (농담) 나는 공격자임, 새로운 아이디어 있음? (/s)

• 진정으로 오싹한 부분은, 이제는 로컬 LLM을 이용해 시크릿을 찾아내는 방식임

  • "포스트인스톨" 문제는 예전과 같지만, 페이로드는 완전히 새로운 세대임

  • 악성 논리가 코드 대신 프롬프트에 숨으므로 기존 정적 분석으로 탐지하기 어렵게 됨

  • 이런 악성 프롬프트는 어떻게 방어할 수 있을지 고민됨

    • Claude Code를 완전 격리된 컨테이너/VM에서 돌리고, 커밋하는 코드 모두 직접 리뷰하는 방식밖에 답이 없는 듯함