dependency management
이 태그가 달린 문서 7건
Ethersphere bee-js 13.3.0과 Swarm Desktop 0.56.2에 악성코드가 배포됨(2026년 11월): 영향받는 버전과 사용자가 해야 할 일
분산 스토리지 네트워크 Swarm의 개발사 Ethersphere의 npm 패키지 @ethersphere/bee-js 13.3.0에 악성 코드가 들어 있었습니다. 2026년 11월 9일 공개된 GitHub 권고(GHSA-hh7j-5m3j-23pf)는 영향받는 버전이 13.3.0뿐이며 패치된 버전은 없다고 밝힙니다. 이 패키지가 설치되었거나 실행 중인 컴퓨터는 완전히 침해된 것으로 간주하고, 그 컴퓨터에 있던 모든 비밀 정보와 키를 다른 컴퓨터에서 즉시 교체하라고 합니다. 패키지를 삭제해도 설치로 생긴 악성 소프트웨어가 모두 지워지지 않을 수 있습니다. Swarm Desktop은 Ethersphere의 릴리스 노트에 따르면 11월 9일 공개된 0.56.3이 침해된 0.56.2를 대체합니다. 한 보안 업체의 분석에 따르면 bee-js 13.3.0은 11월 9일 UTC 00:09경(일본 시간 09:09) npm에 올라왔다가 약 75분 뒤 삭제되었습니다. Swarm Desktop 0.56.2는 약 8.5시간 공개되었고 Windows x64와 Apple Silicon에는 자동 업데이트로도 전달되었습니다. bee-js 13.2.0 이하와 Swarm Desktop 0.56.1은 영향이 없다고 보고되었습니다. 같은 분석은 Bee 노드의 설정 파일(평문 비밀번호가 들어 있음)과 지갑 키가 노렸고, 공식 릴리스 자동화가 쓰는 자격 증명이 악용되었다고 밝힙니다. 우리의 결론: 영향받는 버전을 설치한 머신과 CI 환경은 다시 구축하고, 지갑을 새 키로 옮겨 자금을 이동하며, 다른 머신에서 자격 증명을 교체하세요.
LiteLLM 1.107.0에 자격 증명 탈취 악성코드 포함(2026년 10월): 영향받은 PyPI 릴리스와 Docker 이미지, 사용자가 해야 할 일
2026년 10월 21일(UTC), LiteLLM을 개발한 BerriAI는 릴리스 파이프라인이 침해되어 자격 증명을 탈취하고 원격 코드 실행 도구를 불러오는 악성코드가 담긴 v1.107.0이 배포되었다고 발표했습니다. 영향받은 대상은 PyPI의 litellm==1.107.0(11:39~13:23 UTC), Docker Hub의 v1.107.0, latest, main-latest, main-stable 태그(11:46~14:20 UTC), GHCR의 같은 태그(11:46 UTC부터 늦어도 13:51 UTC에 내려갈 때까지, 약 2시간)입니다. GitHub의 공식 v1.107.0 소스 태그에는 악성 파일이 들어 있지 않으며, 해당 아티팩트는 공격자가 통제하는 유사 저장소에서 빌드되었습니다. 이전 버전은 모두 이번 침해와 무관하며, 회사는 사용자에게 1.106.2 또는 그 이전의 명시적 버전으로 고정할 것을 요청합니다. 10월 24일(UTC) 회사는 1.103.8, 1.104.6, 1.105.4, 1.106.3을 공개했고, 이 릴리스부터 Docker 이미지와 Helm 차트는 새 cosign 키로 서명됩니다(이전 키로는 검증되지 않습니다). 10월 23일 회사는 근본 원인 분석을 공개하면서, 토큰이 내부 LiteLLM 배포 환경의 로그에서 유출되었다는 처음의 판단을 정정했습니다. 분석에 따르면 5월 27일 공개 저장소에 실수로 커밋된 설정 파일에 내부 에이전트 플랫폼의 마스터 키가 들어 있었고, 커밋은 덮어썼지만 키는 폐기되지 않았습니다. 10월 10일 공격자는 이 키로 플랫폼 API를 호출해 그곳에 설정된 GitHub 조직 소유자의 GitHub CLI 토큰을 얻었습니다. 이를 이용해 CI 시크릿을 빼내 다른 메인테이너 두 명의 토큰을 확보했고, 10월 21일 브랜치 보호를 해제하고 릴리스 워크플로를 변경한 뒤 릴리스를 승인했습니다. 이 사이트의 결론: 해당 시간대에 1.107.0을 설치했거나 실행한 환경은 다시 구축하고, LLM 제공업체 키, 프록시 마스터 키, 데이터베이스 비밀번호, 클라우드 역할 등 그 환경이 접근할 수 있던 모든 키를 교체하세요.
osv-scanner 실전 — pnpm, CVE 무시, 오프라인 모드, 자주 만나는 오류
도입 다음 날의 질문만 공식 문서에 근거해 답합니다. pnpm-lock.yaml은 지원되고, 무시 설정은 osv-scanner.toml의 IgnoredVulns에 두며 기한을 붙일 수 있고, 오프라인 모드는 역할이 다른 세 플래그입니다. 본 사이트의 견해: 스캐너는 알려진 취약점을 보고할 뿐, 직접 고정한 버전이 낡아 가는 것은 알려 주지 않습니다. 그것은 별도의 장치가 필요합니다.
Express(Node.js) 보안 — 프로덕션 하드닝 실무 레퍼런스
Express는 최소주의라 기본으로 거의 아무것도 지키지 않으므로 방어는 직접 더한다. 본 페이지는 실무 레퍼런스다: (1) 우선순위 순의 하드닝 체크리스트(P0~P2), (2) 영역별 지침 — 보안 헤더(helmet) + x-powered-by 비활성화·npm 의존성 CVE·입력 검증과 인젝션(SQL/NoSQL 연산자)·인증과 소유자 스코프 인가·속도 제한과 크기 상한·세션/쿠키/CSRF·SSRF·프로덕션 에러 처리(스택 미노출)·NODE_ENV, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차는 없다.
Next.js 보안 대책 — 프로덕션 하드닝 실무 레퍼런스
Next.js의 기본값은 비교적 안전하지만, 사고는 서버/클라이언트 경계에서 일어납니다. 이 페이지는 실무 레퍼런스입니다: (1) 우선순위별 하드닝 체크리스트(P0–P2), (2) 영역별 지침 — 경계와 환경 변수(NEXT_PUBLIC_), 의존성 CVE(본체 RCE 포함), Server Actions / Route Handlers 인가 + 입력 검증, 서버 측 fetch의 SSRF, 보안 헤더/CSP, 인증/세션/쿠키, 레이트 제한, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차 없음.
Ruby on Rails 보안 — 프로덕션 하드닝 실무 레퍼런스
Rails는 규약과 안전한 기본값(CSRF 보호·Strong Parameters·ORM)을 갖추지만, 프로덕션 사고는 운영에서 일어납니다. 본 페이지는 실무 레퍼런스입니다: (1) 우선순위 하드닝 체크리스트(P0~P2), (2) 영역별 구체 대책 — 비밀과 credentials(master key/secret_key_base)·프로덕션 설정(force_ssl·예외 비노출)·gem CVE·Strong Parameters/Mass Assignment·인가(Pundit 등·소유자 스코프)·인젝션과 위험한 메서드(where 결합/send/constantize)·세션/Cookie/CSRF·SSRF/업로드, (3) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
Spring Boot 보안 — 프로덕션 하드닝 실무 레퍼런스
Spring Boot는 안정된 프레임워크지만, 사고는 의존성·설정·인가에서 일어난다. 본 페이지는 실무 레퍼런스다: (1) 우선순위 순의 하드닝 체크리스트(P0~P2), (2) 영역별 지침 — 의존성 CVE(Log4Shell급, 가동 중인 버전으로 판단)·프로덕션 설정과 시크릿 외부화·Spring Security 인가(기본 거부/메서드 인가/소유자 검사)·Actuator/관리 노출 축소·안전하지 않은 역직렬화·인젝션·헤더/CSRF/세션·SSRF, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차는 없다.