Nx 및 일부 지원 플러그인의 악성 버전이 배포됨

(github.com/nrwl)

3P by GN⁺ 13시간전 | ★ favorite | 댓글 1개

Nx 패키지와 플러그인의 악성 버전이 npm에 배포되어 파일 시스템을 스캔하고, 자격 증명을 수집한 후 사용자의 Github 계정 저장소로 전송함
영향을 받았는지 확인하려면 Github 계정에 s1ngularity-repository 저장소가 생성되었는지 확인 필요
감염된 경우 토큰 및 비밀번호 교체, 악성 저장소 삭제, 쉘 설정 파일 점검이 반드시 필요함
악성 버전은 postinstall 스크립트로 시스템에 영향, 특히 VSCode Nx Console 플러그인 이용 시 무의식적으로 실행 위험 증가함
Nx 측은 재발 방지 및 추가 보안 조치를 시행했으며, 관련 버전은 npm에서 제거됨

개요 및 요약

이번 보안 권고는 Nx 패키지 및 일부 관련 플러그인에 대한 심각한 공급망 공격으로, 악성 코드가 npm을 통해 배포됨
해당 악성 버전들은 사용자의 파일 시스템을 스캔하여 인증 정보, 경로 등을 수집하고 Github 저장소(s1ngularity-repository)에 업로드함
악성 postinstall 스크립트는 또한 사용자의 쉘 설정 파일(.zshrc, .bashrc)을 수정하여 시스템 종료 명령을 추가함
공격 벡터와 공격 진행 과정, 영향받은 버전, 사용자가 취해야 할 즉각적인 조치, 재발 방지책 등이 자세히 정리됨

긴급 조치 방법

모두가 확인해야 할 사항

본인 Github 계정의 저장소 목록에서 s1ngularity-repository가 생성됐는지 확인
해당 저장소에 포함된 파일을 다운로드해 기록 보관
저장소를 Github에서 삭제
security@nrwl.io로 이메일을 보내 유출 정보 해독 방법 안내받기
모든 계정의 자격 증명과 토큰을 즉시 교체

Github 토큰 교체 방법

https://github.com/settings/connections/… 방문
연결된 앱의 접근 권한을 취소해 기존 토큰 무효화
gh CLI 사용 시 재인증하여 새 토큰 생성
미조치 시 기존 토큰이 악용될 위험

악성 Nx 버전 사용 중지 및 정리

현재 사용 중인 Nx 버전이 악성 버전인지 npm ls nx 명령어로 확인
감염 버전이면 npm uninstall nx && npm install nx@latest로 업데이트
npm cache clean --force로 캐시 정리

이미 감염된 사용자

npm 및 Github 토큰을 교체
Github, 연관 서비스의 비밀번호 및 자격 증명 전부 재설정
.zshrc, .bashrc 파일에서 낯선 명령어가 삽입됐는지 확인 후 삭제

내부 패키지 저장소 관리자의 경우

사내 저지 내 proxy에 악성 버전을 즉시 삭제해 추가 확산 차단 필요

영향받은 버전 안내

Nx 패키지

21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, 20.12.0
10:44 PM EDT 기준 npm에서 제거 완료

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

10:44 PM, 6:20 AM EDT 기준 npm에서 제거 완료

공격 벡터 상세

취약한 Workflow 원인

Github Actions 워크플로우에 임의 코드 실행이 가능한 취약점이 도입됨
PR 타이틀에 특정 bash 코드를 삽입하면 워크플로우에서 시스템 명령이 실행되는 취약점(Bash Injection)
pull_request_target 트리거를 통해 elevated 권한(GITHUB_TOKEN 등)을 가지게 되어 악용됨
삭제 전까지 main이 아닌 구 브랜치에서 취약 워크플로우가 유지되어 공격자가 악성 PR로 워크플로우 실행 및 시크릿 탈취에 성공

npm 토큰 탈취 과정

취약 워크플로우를 통해 publish.yml을 실행하도록 함
publish.yml은 npm 토큰을 Github Secrets로 보관, 이 과정에서 외부 웹훅으로 토큰 전송
최종적으로 공격자가 이 토큰을 통해 Nx 및 지원 패키지의 악성 버전을 npm에 업로드

악성 패키지의 행동

자격 증명을 포함한 정보 수집 및 Github 저장소 게시

감염된 Nx 패키지의 postinstall 스크립트 실행 시, 각종 텍스트 파일 위치 및 자격 정보 수집
s1ngularity-repository라는 이름의 Github 저장소에 base64로 인코딩해 업로드
실제 저장소가 삭제되었더라도 이전에 공개 상태였으니 정보 유출 가능성 고려 필요

쉘 프로필(.zshrc, .bashrc) 변조

postinstall이 sudo shutdown -h 0 명령어 삽입하여 터미널 실행 시 시스템 종료 유도 및 비밀번호 노출 가능

postinstall이 동작하는 다양한 시나리오

npm install/yarn/pnpm install 명시 실행 외에, 트랜지티브 의존성, 에디터 확장, 스크립트 실행 등 다양한 상황에서 동작 가능
특히, VSCode용 Nx Console 확장(18.6.30 ~ 18.65.1 버전)은 에디터 구동 시 자동으로 nx@latest를 설치해 postinstall 실행 유발 가능
근본적으로 의도하지 않아도 여러 곳에서 NPM 모듈 설치가 이뤄질 수 있음을 주의해야 함
Nx Console(18.66.0)부터는 latest nx 설치 과정이 제거됨

공격 및 대응 타임라인

8월 21일

4:31 PM: Bash 주입 취약점이 포함된 PR이 머지
10:48 PM: 취약점 지적 게시글이 X(구 트위터)에 게시

8월 22일

오후: 내부조사, 취약 워크플로우 롤백(불완전)
CodeQL 도입으로 향후 PR에서 유사 취약점 탐지 적용

8월 24일

공격자 포크에서 npm 토큰 유출 정황이 있는 커밋 발생
악성 PR이 생성 및 삭제, publish.yml이 이 PR에 의해 실행

8월 26일 ~ 27일 (악성 버전 배포, 대응)

악성 Nx 및 플러그인 다수 버전 npm에 차례로 배포
Github/NPM 커뮤니티에 이슈 제보
10:44 PM: NPM 측에서 해당 버전 전량 제거 등 조치
11:57 PM: 모든 Nx 관련 패키지 게시용 Token 무효화
8월 27일: Nx Console 패치, 2FA, Trusted Publisher 방식 전환 등 추가 조치

사전 예방조치 및 이후 대응

모든 nrwl 조직 maintainer에게 2FA 의무화
신뢰할 수 있는 게시자(Trusted Publisher) 메커니즘 적용. npm token 기반 배포 금지
향후 패키지는 무조건 2FA·신뢰 기반 검증 후 배포
추가 위험 탐지 및 PR 승인, 브랜치 보호 등 단계별로 적용

교훈 및 향후 계획

공급망 및 CI/CD 파이프라인, 워크플로우 권한 최소화의 국내외 중요성 재인식
팀 내 재조명 후, 커뮤니티에 학습 내용 공유 예정

문의

security@nrwl.io로 문의 가능

참고 및 부록

Github 주요 이슈, 타임라인, 관련 포스트
감염 패키지 내 telemetry.js 스크립트 예시 제공
이 스크립트는 파일 시스템 내 주요 텍스트 파일 경로를 인벤토리 생성 목적으로 수집함

결론 요약

Nx와 관련 플러그인의 최신 업데이트 및 패치 적용 중요
npm, Github 등 주요 인증 정보 즉시 교체 권고
공급망 보안 및 워크플로우 권한 관리의 미흡함이 대형 사고로 이어질 수 있음을 일깨운 사건임

▲

GN⁺ 13시간전 [-]

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에서 돌리고, 커밋하는 코드 모두 직접 리뷰하는 방식밖에 답이 없는 듯함

답변달기